Milestones go a long way to help clarify how a statement-of-work project will be executed and completed and define the general critical path toward that completion. They generally exist as intermediate stages that must be fulfilled sequentially leading to the completion of a final goal or end of an engagement. Hence, clear execution milestones provide a critical success framework for the scope of an SOW project, not just the value delivered.
Tracking of milestones provides strategic and project management organizational tools to ensure an SOW project engagement delivers on the value promised — and that the engagement occurs in the first place.
Typically, milestones are limited to SOW project engagements. They are not associated with ongoing SOW service engagements — and certainly not rogue engagements such as unstructured SOW time-and-material contracts. The latter are arrangements the contingent workforce program would be seeking to eliminate. SOW service engagements, meanwhile, are legitimate and ongoing in nature, delivering a value that repeats itself. Milestones could be used in the execution of a service but do not conclude in a traditional critical path end point, as is the case in an SOW project engagement.
In terms of their usefulness for project engagements, milestones are definable and provide a foundation from which to monitor progress. They can also serve as proof of the status of a project. Key characteristics of milestones include their frequency and potential for providing opportunities for course corrections and learning experiences.
Milestones can help maintain accountability and motivate staff, and, in the absence of the client’s involvement along the way, can prevent the SOW solution provider from making costly mistakes.
Contractual milestones satisfy multiple purposes in commercial relationships:
- Manage parties’ performance and involvement.
- Maintain expectations of timeliness.
- Provide the SOW solution provider with needed liquidity if tied to payment. Note: Not every deadline met or task completed would represent a proper milestone, especially if funds are tied to milestone achievement.
Establishing a payment schedule associated with milestone targets can be very tricky. When a contract spans an extended period of time, most SOW solution providers would rather not wait until the completion of the project to get paid. This means that it will be necessary to negotiate some form of payment schedule.
Advance payment or frontloading. Often, SOW solution providers will want either advance payments or to frontload the payment schedule against a predefined set of tasks or activities so they can essentially finance the work with the buyer’s money. Both of these approaches can be a risk for the CW program, as they may end up paying more than the value of the work that has been performed to date and can create problems if improperly drafted. Advance payments of that type equate to sunk funds if the need arises to terminate work and may limit project flexibility to switch SOW solution providers.
Date-based payment. SOW providers may want a payment schedule with payments due on specific dates. The problem with this date-based approach is that dates alone have no link to the amount or quality of the work performed. If you have a SOW solution provider that is far behind on the work, paying them on a specific date can create what is effectively another advance-payment scenario, as they have not earned the amount of the payment. Likewise, your organization loses leverage due to diminishing contract value.
Binary payment. Binary payment refers to only paying the full amount for a completed milestone deliverable and not, for example, paying half of the agreed-upon amount for a deliverable that is 50% complete. If possible, avoid partial payment and establish payment based on completed milestones.
Acceptance requirement. Here, you would establish specific milestones that are based upon the completion of identified deliverables and have each milestone payment reflect the value of the completion of that work and the acceptance of those deliverables. With this approach, the buyer’s contract needs to specify the deliverables that must be completed or provided to meet the milestone and the requirement that those deliverables must be accepted as a prerequisite of payment. The acceptance requirement prevents the buyer from paying for deliverables that need to be corrected later. This is the payment option we would advise programs use.
The financial stability of the SOW solution provider also needs to be considered. In the event of bankruptcy, the buyer may become the unsecured creditor.
When an SOW engagement includes hundreds if not thousands of discrete tasks and deliverables, it can be overwhelming to identify those items that would make appropriate project milestones. The number of milestones should not be too numerous as to be unmanageable but also not too simplistic as to misrepresent the complexity and performance of SOW solution partners.
A good rule of thumb is to consider the milestones against four key criteria:
How important is this task to the end deliverable? Is the completion of this task critical to the end result? For example, when executing an SOW for the building of an off-site server farm, a critical deliverable may be the completion of the physical building to house the servers.
What is the consequence for non-completion? While it can be argued that in the traditional waterfall-based project, all tasks are dependent in some form on the previously completed tasks, some are more important than others. In our previous example, it is impossible to have a server farm without a building to house said servers.
What clearly represents a successful project deliverable? Are the quality and specifications of the deliverable aligned to the success and quality of the SOW deliverable? If the building is of poor build quality, it can be assumed future deliverables will be as well if the project were to continue on its current trajectory.
Does the task have a discrete value outside the SOW? Does the completed task have an intrinsic economic dollar value or business value independent of the end deliverable? While this is not always possible for all projects, it is often a good idea to use this test as an added mechanism to identify likely milestone targets.
Creation and governance. First, avoid milestones that describe functionality in favor of detailed outcomes and expected solution features. A function or operation contributes to an outcome but is not a standalone deliverable in of itself.
The milestones’ completion should be dependent upon the satisfactory completion of subtasks. If the milestone can be completed independently of the previous step, extra care needs to be given to validate the outcome.
Finally, it should be clearly defined as to who is responsible for the milestones’ final outcome and dependencies or acceptance criteria required to complete the SOW project.