Client Contractual commitment tracking
Tracking the contractual commitments of a project should be the best-kept thing there is, since it is what decides the invoice. It is generally the worst kept of all: the contract is signed, filed in a file space, and the commitments it carries keep running without anything tracking them day by day.
What a project contract really commits.
Four families of commitments, and they almost always live in four different places.
Milestones
Dates that commit, sometimes with penalties. They are in the contract, rarely in the tracking tool.
Deliverables
What is owed, and under what conditions it is deemed accepted. The acceptance condition is the point most often left vague.
Payment terms
What triggers an invoice: a milestone reached, a deliverable accepted, a calendar due date.
Client obligations
Providing access, approving within a deadline, making a point of contact available. They commit just as much, and are tracked nowhere.
A commitment you do not track is a commitment you discover.
The contract is a legal document, so it is filed with the legal documents. Progress is operational, it lives in the tracking tool. Billing is accounting, it lives in the ERP. These three worlds only talk to each other at moments of tension.
The practical consequence repeats from project to project. A milestone is reached without anyone knowing, and nothing is invoiced. A milestone is missed without having seen it coming, and you learn about it from an email from the client. Something is delivered that was not owed, because the request made in a meeting was never compared with the signed scope.
And the costliest: the delay that falls to the client is written down nowhere. An approval that waits three weeks on their side appears in your planning as a slip, with nothing to establish where it comes from. When the discussion comes, you only have a recollection to put forward.
The internal case, where there is nothing to sign.
An IT department facing its business units does not sign a contract. It nonetheless holds exactly the same commitments.
Dates owed without a penalty
The business built its plan on an announced date. That no clause penalizes it does not make it any less owed.
Reciprocal obligations
The business must provide rules, approve mock-ups, free up people for acceptance. Its delay shifts the project as much as yours.
A permanent arbitration of priorities
Without a written commitment, each new request goes first, and the portfolio is re-arbitrated continuously without anyone measuring the cost.
A real accountability
The department answers for what it promised, exactly like an external supplier, but without a document to lean on.
This is why we talk about commitments rather than clauses: what matters is what was promised and perceived as owed, whether or not it was signed. The ten contractual modes are described on the commitment levels.
Bring the contract closer to execution, not the reverse.
The usual temptation is to archive better: a better organized file space, a naming scheme, a quarterly contract review. This improves access to the document, and changes nothing about the problem, because the problem is not finding the contract.
The problem is that the commitments it carries are not live lines of the project. A contractual milestone should show in the same place as a work package in progress, with its date, its status, and what is missing to meet it. A client obligation should show there too, with its due date and its possible delay.
That is exactly the definition of operational commitment management: holding what was promised, by whom, by which date, and on what dated proof, on both sides of the link.
In pylotik.
Four points that make a commitment stop being a document and become a tracked line.
Contractual milestones in the grid
They live with the work packages and tasks, not in a file next to them. A milestone that approaches shows, and a milestone reached triggers what it should trigger.
The client's delay, dated
An action is closed by its requester. An approval expected on the client side is a line with a due date, and exceeding it is a finding.
Amendments backed by a gap
Every request becomes a dated trace at the moment it is made. The amendment starts from a finding, not from an end-of-project discussion.
Proof that the client has read
Committee minutes are submitted to them and approved. The commitment is not only written: it is established on both sides.
What the client sees of all this is described on the project client portal, and the fixed-price case on fixed-price project tracking. The full tour is on the product page.
What we are asked about commitments.
Do you need to import the contract into the tool?
No, and that is not the point. What enters the tool are the commitments the contract carries: dated milestones, deliverables and their acceptance conditions, reciprocal obligations. The document itself stays where it is.
How do you track the amendments of a project?
By tying them to the gap that justifies them. An amendment based on a request traced at its date is discussed calmly; the same amendment built after the fact, from a feeling of overrun, becomes a negotiation.
Who is responsible for a delay, the client or the supplier?
It is established rather than argued, provided the obligations of both parties are tracked with the same rigor. That is the reason for the symmetry: your delay is traceable, and so is the client's.
Does it work without a contract, internally?
Yes, and it is a common use. An IT department facing its business units holds dates that are owed, with no clause or penalty. The engine makes no difference between a signed commitment and an announced one.
What is the value of a trace produced by the tool?
We speak of dated proof and of a trace that both sides can rely on, not of a legal qualification: the applicable framework is that of your contract. What we observe is simpler. A document submitted, read and approved on a date establishes what both parties knew at that moment. See the terms and conditions.
What if the contract changes during the project?
Commitments are updated like the rest of the project, and the history keeps the earlier state. That is what makes it possible to say not only what is owed today, but what was owed at the date of a past committee.
Going further.
- Operational commitment management: the definition of the category, of which this page is the entry point.
- The commitment levels: the ten contractual modes, from consulting to managed services.
- The project client portal: what the client sees and approves.
- The product tour: milestones, committees, action logs.