What is SOW and What is its Role
This is almost obvious. SOW (Statement of Work) in principle it is part of an agreement that specifies details about engagement between supplier and customer.
In common perception (almost correct one) this is an appendix describing the scope of the project. It is somehow close but far from correct.
The first point I want o make SOW is a legal document. Not only it is signed by parties, but it is an integral part of a bigger agreement (contract) but also it is legal by the language used in it.
SOW is not a technical document, like specification or architecture design spec or other documents.
Because of this, it is NOT a scope document, per se. Ok, one can and should be able to get understanding what parties what to archive by agreeing this engagement. But not in details. This scope description should be only good enough to enter cooperation.
So, if scope is not in SOW where it is?
IF there is a scope it mainly described either in RFP document or scoping document as part of POC/ pilot or similar doc.
During engagement execution scope will much more addressed specification documents, or backlog, and similar deliverables.
So, what is a role for SOW?
The primary role of SOW is to describe rules of engagement. Instead of detailed scope, it should address what is a process to define details of scope and process to deliver it.
This is why it is a very essential tool for managing engagement by the project manager. Experienced project managers know If SOW is not well designed, it means a lot of issues on the project.
Let’s find out what are essential parts of SOW and why they are important for the project manager in the next sections.
Goal of the Engagement, Time, Price, Billing
The very first part of good SOW is the Goal of Engagement. It is nothing more than a few lines about why this engagement is to be signed. What is the goal of customer organization by implementing scope? Is this a part of a bigger program? The real intention is to give a short context. If there is anybody new on the project, he/she should be able to get high-level context why what is this engagement about. The Goal of Engagement should not be longer than a half-page. Shorter better.
The next part of SOW is engagement Time. It may mean specific dates range of engagement or just estimates (not fully committed) - but kind of timeframe is important to get an understanding of how long a corporation is planned. Some dates when stated strict can used later to be baseline for performance penalties. This part has to be well designed to satisfy both sides.
Following is Price information. It could be one number or more complex construction or rate card. Anything which defines remuneration for executing the engagements. It has to be precise and not leaving any ambiguities on what monetary value of engagement is.
Next section is Billing. This plays in synch with Price section. It describes how the supplier will be paid for the work. It could be as simple as one payment after accepting all work or payment schedule based on milestones or just timesheets. Again, it should not leave any room for different interpretations.
Service, also Assumptions, Deliverables, Change Control
If we provide a skills bandwidth (consultants on rate card) with no scope definitions, this section can be minimized or skipped almost entirely. But let's assume we have the most complex situation which is fixed price and fixed scope engagements. (anything less complex can be scaled down accordingly).
Statement of Work in principle will refer to services more than goods. Goods can be part of SOW, but rarely is an only deliverable.
Based on this Service section would be most essential to start. It should briefly describe service by service. For example, Project Kickoff, Requirements Analysis, Testing, etc.
Services can be related one to another or not. But it brings s a foundation for the next activities. It gives a naming which will be used in other sections.
Another section is Deliverables. It is listing all outputs for the service. In principles, we list those deliverables which are some how-to interchange with a customer. Specific service can (and definitely will) produce many outputs, but not necessarily all are interested to customer.
Each deliverable should be linked to service and should have acceptance criteria if they are subject of acceptance by a customer.
" Statement of Work (SOW) is not a scope document. It is a legal document. The primary role of SOW is to describe rules of engagement. Instead of detailed scope, it should address what is a process to define details of scope and process to deliver it"
Next part is Assumptions. Again, assumptions should be linked to service. I have seen often separate section assumptions. IT is not very useful in my opinion. Assumptions should be presented in the context of service and deliverables. IT is much more helpful to execute change management later. An important part of assumptions is the entry criteria for service. If there is a dependency for starting service. It has to be there, in assumptions. Doing this will bless the project manger's hard work later.
Next but not the last important section is Change Management Procedure.
Ok, it may be included in the main agreement, but I am an advocate for having it in SOW. This shows the 'operational' character of change management, as part of 'engagement execution'.
Some Final Esthetics
There are two major comments related to esthetics and usability of SOW
The first point is sections that describe technical details of the expected scope or any other details.
This is something that goes against the SOW role. I have seen many SOWS having good price and billing sections, but then tens of pages with a requirements list. This makes SOW very hard to read.
In 95% that detailed information is supposed to be part of the project deliverable document, but if we have to have details inside the SOW lest keep it as an appendix, just for consistency and reading flow of main SOW.
The other part is graphics in SOW. It is esthetic, but SOW is a legal document. Have you ever seen a document issued by court or notary with graphics inside (exclude appendixes) ? Tables are allowed.
Graphics also represent another risk. Graphics may be considered scope commitment, more than needed.
I have seen SOWs with graphics about the architecture of the solution. Hey, this is probably the future deliverable of the engagement phase!
If Architecture of solution is in SOW - this means it has to be delivered as stated on the picture. No refinement. This is what the court will say if things get to this level.
Final Conclusion
SOW are rules of engagement. It should describe partie’s obligations.
Yes, scope is an obligation, but this is not the entire story. Obligation is also price and how it will be paid. Obligations are what the customer has to prepare before the phase can start. Obligations is accepting the deliverable. Obligation is a process of how to deliver.
We should see SOW as, if we have a change of project manager during an engagement, Statement of Work should be clear and easy for a new person to read and understand obligations by both parties.
Also, an important role is to be a baseline for managing change. And I do not mean scope change only, which is easy to track based on other documents, but other changes like those based on assumptions and any change resulting from this.
Managing engagement via SOW is a safe ticket for suppliers and customers at the same time.
So, keep SOW clear and simple, not too long. It is your primary tool to manage the project.
