Introduction

Are you a project manager in a large enterprise about to engage vendors for some work? 

Preparing and delivering a Statement of Work (SOW) for an enterprise customer can seem like a monumental task. Keeping in mind these four key points during the project discovery phase will assist Project Leads and Managers in defining each of the components that make up the SOW.

Because a SOW is a snapshot in time and a document that outlines a set of activities, deliverables and timeline for the software development provider to fulfil stated requirements, it should be at a level of detail that supports successful project delivery.

Focussing as much time as possible on the following four key points when preparing the SOW will achieve this outcome, as well as demonstrate competence to the customer.

1. Define scope with as much detail as is practical

When listing the estimated deliverables in the SOW, it is important to consider how much detail is required. The amount of detail will depend on several factors:

Discovery Time/Cost

The amount of time and resources available during the project discovery phase will play a large role in how detailed the scope will eventually be. Investing time and resources in identifying and elaborating delivery items in more detail will provide a higher level of confidence when estimating effort against them.

Project Methodology

If Agile is used as the project delivery framework, the required level of confidence will initially be lower, but increase as the delivery team learns how to work together and deliver working software with every sprint. A Waterfall approach will demand a much higher confidence level before business will be comfortable beginning delivery.

Key Stakeholder Availability

Typically, Subject Matter Experts and Vendors that will be part of the project will be required to elaborate on initial understanding, and provide a clearer picture of what is required. This may not always be possible during discovery for any number of reasons. If this is the case, then the estimates will have to compensate for a lower confidence factor.

Vendor/System Specification and Design Completeness

In most cases it will be required to base at least some of the estimates against some kind of system, interface specification or high-level design. These may not always be complete or provide enough detail for to obtain the full picture. These knowledge gaps may be able to be covered off by technical subject matter experts or the like. If this is not the case adding to the list of assumptions and lowering the confidence rating around associated deliverable items will be required.

Ultimately, these factors will constrain the accuracy of the SOW and it is important to call this out in the document by noting an overall confidence rating as a percentage.

This rating will give context to those responsible for acceptance and signoff around how much variance they can expect. If the level of confidence is not accepted by stakeholders, it should be called out as an unacceptable gap in knowledge before delivery.

2. Cover estimates with a solid set of assumptions

It is reasonable to accept that the team will always know less about a project during discovery than in any other phase. With this in mind, a tool to cover any unknowns and unconfirmed constraints will be required. This tool will be the humble assumption.

A well-defined set of assumptions will not only help to explain the reasoning for why identified deliverable items were estimated the way they were, they can also be used to cover knowledge gaps that can’t be closed during discovery.

A large amount of importance should be placed on defining assumptions with as much detail as possible. Here, it is a good idea to have high level assumptions as well as inline deliverable level assumptions so the assumptions can be as broad or specific as required.

By getting together with other stakeholders and sharing the list of assumptions, and then comparing them against the assumptions of others in the expected delivery team will be of great benefit. Validating and exploring identified assumptions with others will often lead to much better coverage than a single person could produce alone.

If a reasonable amount of effort is placed on the assumptions list and the above tactics are employed then the project will be in a great position when the clarifications start flying and delivery takes off.

3. Delivery phase definitions should reflect the actual process

When defining the delivery phases of the project, be aware of the process the project will be using during delivery. The closer the phase can be articulated to the actual process, the smoother phase transition will go. This is because it’s all right there in the SOW that was agreed by the business stakeholders. Deviating from this will cause confusion and may block the project team from moving to the next phase while the Project Manager tries to clarify with the business stakeholders.

Some key items to include when defining a phase are:

• Intent: This should describe in a concise manner what the intention of the phase is.
• Inputs: The dependencies this phase requires to start, always include the output of the phase before where it is not the first phase.
• Outputs: Any expected key outcomes and deliverables should be listed so everyone understands and agrees on what is expected, this will form the acceptance criteria to be signed off. A well-defined set of acceptance criteria is arguably the most important focus of the phase description.
• Signing Off: This should list the stakeholders that are required to sign the phase off. All too often this is left out and the inevitable question of “who said you can progress?” arises.

Using an Agile project delivery framework, it should be possible to take what is defined in the “Definition of Done” and use it to describe the phases of delivery or vice versa as this will be a true reflection of each phase to get to done.

4. Peer Review the SOW

Having peer reviews of the SOW will provide participants with an insight that may have been missed when only considering an individual’s perspective and will lead to fewer gaps in the resulting SOW.

It is often daunting to show work to others for the first time in fear of judgement however, the more this process is done the easier it becomes for all participants and the overall result will have a much higher quality factor.

The simple process of sharing the SOW with relevant team members will - more often than not - identify some ideas or uncover a key question that had not been thought of resulting in the

identification of missed deliverables or key assumptions. The same goes for scoping deliverable items, the simple act of sharing the list with a colleague will often identify a handful of items that had not been thought of.

There are many ways to conduct peer reviews and there are countless articles describing key factors and mechanics of a good peer review system, the most important thing in the process is sharing the SOW with others. The article “The secret to successful projects: Peer reviews” by Bob Ronan is one such example because it is well written and shows the importance of the peer review process.

Conclusion

Using the above 4 key points to focus the time available while producing the SOW will place the output in the best position possible to achieve a successful project delivery.

If you have any feedback or thoughts on this article please feel free to shared them on the comment section below.