SOW, Statement of Work or Scope of work (SOW) is a formal document that captures and defines the work activities, deliverables and timeline a vendor will execute against in performance of specified work for a client. Detailed requirements and pricing are usually included in the Statement Of Work, along with standard regulatory and governance terms and conditions.
SOWs are often times very complex for the average IT Manager/Project Manager to manage, write, adhere to, or even understand. SOWs generally form the basis of a contract between the vendor and the IT organization.
Areas that are typically addressed by a SOW are as follows:
Purpose: Why are we doing this project? This is the question that the purpose statement attempts to answer.
Scope of Work: This describes roughly the work to be done in detail and specifies the hardware and software involved and the exact nature of the work to be done.
Location of Work: This describes where the work is to be performed. This also specifies the location of hardware and software and where people will meet to perform the work.
Period of Performance: This specifies the allowable time for projects, such as start and finish time, number of hours that can be billed per week or month, where work is to be performed and anything else that relates to scheduling.
Deliverables Schedule: This part lists the specific deliverables, describing what is due and when.
Applicable Standards: This describes any industry specific standards that need to be adhered to in fulfilling the contract.
Acceptance Criteria: This specifies how the buyer or receiver of goods will determine if the product or service is acceptable, what objective criteria will be used to state the work is acceptable.
Special Requirements: This specifies any special hardware or software, specialized workforce requirements, such as degrees or certifications for personnel, travel requirements, and anything else not covered in the contract specifics.
Type of Contract/Payment Schedule: The project acceptance will depend on if the budget available will be enough to cover the work required. Therefore payments breakdown whether up front or phased will be negotiated very early at this stage.
Miscellaneous: There are many items that do not form part of the main negotiations but are nonetheless very important to the project. They seem minor but being overlooked or forgotten could pose problems for the project.
My intent with this blog post is to go over some common pitfalls in SOW Management I have seen and how to deal with them.
Scope Creep/Extra Work
Once the SOW has been awarded and signed the vendor comes in for a kickoff. They are working on the project and everything is going smooth. Alas, a missed requirement! How common is that?! The vendor says not a problem we can do that…. at a cost! So now your delicate tightly managed budget will go over. Someone has to be the scapegoat. Who do we blame? How does this get fixed? The vendor will save us but at what cost?
The above scenario plays out more often than you would believe or would be led to believe. Some vendors who prey on organizations that don’t really know what they are doing (government agencies for one), bake this into their projections. Knowing that they will make serious bank later on because the SOW is incomplete, or they have the experience of previous projects and know of the projects pitfalls.
Sow how do you manage this? Early on in the writing proces make sure that you tap into resources such as research, colleagues, internal and if possible external lessons learned. Try to get as much data while writing the SOW to anticipate what will happen later in the project to include that in the SOW so it doesn’t fall into any grey areas. Make sure the person managing the SOW/Vendor knows the SOW/Contract in and out. Put in some contingency in your budgetting. Make sure you read the vendors Extra Work section and understand it.
When you end up in an extra work/scope creep scenario ensure you can negotiate with the vendor. Dont just accept the fact/cost and move on. This is what the vendor wants. The project is in mid-flight, they know you are in a bind, but dont let them see you sweat. Use whatever leverage you can to make the impact less.
Lastly, document this and document it in your lessons learned at project close out.(lessons learned will be a topic for another blog post!) This will help in the inputs of new projects to both understand how the scope creep crept in but also the experience with the vendor in these scenarios.
Remember an SOW is generally a binding agreement/contract. Some things may be missed, some people will interpret things in different ways. When it comes to Grey Area there is one main thing to keep in mind when writing the SOW, be as clear and accurate as possible. When you do come to a grey area with the vendor, negotiate and document. Again in the lessons learned.
For example, I write a simple SOW to move this carton of eggs from my Basement to my Kitchen. Vendor A says they will do it for $50. Vendor A moves the carton of eggs from the Basement to my Kitchen and invoices me $50. When I get to the kitchen to inspect the work I open the carton and some of the eggs are broken. I refuse to pay the vendor the $50 because my eggs are broken. Vendor A says you wanted us to move the carton of eggs from the Basement to your kitchen and we did that, we would like payment immediately. Who is right? Who is wrong? Why are we even debating this?
To avoid grey area like this be more specific, add specifics to the acceptance criteria. In the SOW write in the acceptance criteria that all eggs must make it to the destination unharmed. Of course now the vendor may charge more since more than likely they would have to inspect the eggs in the basement, be more careful in transport, and reinspect at the kitchen.
This will be a living blog post with updates as I think of them, experience them or garner feedback/comments.
For more information on writing an SOW check out this great post from PMHUT which was inspiration and a source of content for this post.