The Statement of Work

Published by Brad Egeland | March 30, 2009

The basis of everything…the alpha of the project.  The Statement of Work (SOW).  You review it, you study it, as the PM you dedicate yourself to it entirely for a week or so before the Kickoff Meeting and you use it as the basis for your presentation.  And then sometimes you put it away for good. 

That’s unfortunate because a good SOW of work should always be reviewed periodically throughout the engagement to ensure you’re still on track.  Since the delivery team usually isn’t part of the sales process when the SOW is finalized, then they can just trust that the customer remembers everything about the SOW while the project is in progress.  Certainly they would raise a flag if something were being performed that was not in line with the requirements of the SOW, right? 

Wrong.  As the Project Manager, you must go back to the SOW periodically to make sure that you’re not missing something critical.  On a 6-12 month project, you should be reviewing it monthly.

The Contents of the SOW

A good SOW should have the following sections of information laid out in some order:

• Overview
• Project Scope
• Objectives
• Deliverables
• Interfaces/Integrations
• Hardware/Software Requirements for the System (for IT projects)
• Scope/Change Management Processes
• Resource Requirements
• Communication Processes
• Delivery Team Responsibilities
• Customer Team Responsibilities
• High Level Project Timeline
• Contact Information

The Main Point of Reference

The Project Scope, Objectives, Deliverables, Interfaces/Integrations, and Team Responsibilities are sections that should be revisited on a regular basis.  It’s a certainty that when scope issues arise the SOW should be reviewed again, but periodic checks of the SOW may help keep scope in better check throughout the engagement. 

Certain issues like who is responsible for cleansing current customer data prior to load is usually laid out in the SOW and those are critical efforts that occur later in the project prior to testing and implementation.  Understanding those requirements and ensuring that the associated tasks are properly built into the schedule and assigned to the right team helps in two ways…

• Ensures that the proper skilled resources are available when they are needed
• Ensures that the proper window of effort is blocked off in the project schedule for those critical one-time tasks

I always make it a point to review the SOW in detail during the Kickoff Meeting and make it a major part of my presentation to the customer during that phase.  It’s kind of a “speak now or forever hold your peace” moment in the project…but not really.  Everything can be discussed…and most things are somewhat negotiable – especially if more money can be involved.  But a thorough review of the SOW to kick things off followed by period checks during status meetings and as issues arise throughout the engagement will help stave off potential project delays and budget hits if dealt with directly and swiftly and in accordance with the SOW.

Summary

The SOW is basically the project ‘bible’ and should be treated as such.  The original pricing is based on it.  It was thoroughly reviewed during the Kickoff Phase.  The Exploration Phase started with the SOW as a baseline.  Always remember that the SOW is where the project started and it also is where it should end up (with change orders acting basically as addendum’s to the SOW).  Keep the SOW in proper perspective and in front of both project teams when questions arise and things – including change orders and scope issues – should run more smoothly.

Related posts:

1. The Responsibility of Defining Requirements
2. Managing Change on an IT Project: Part 1 - Identifying Change
3. Never Say No to the Customer
4. The Art of Negotiation - Part 1
5. Resource Forecasting

Comments