Clearly documented and accepted expectations begin with the statement of work (SOW). It lists the goals, constraints, and success criteria for the project—the rules of the game. The statement of work, once written, is then subject to negotiation and modification by the various stakeholders. Once they formally agree to its content, it becomes the rules for the project.
The Statement of Work May Be called by Different Names
This is one project management technique that, though widely used, is called by many names. At least half the firms using the term statement of work use it as it is defined in this book. Watch for these different terminologies:
- Contracts between separate legal entities that include one or more statements of work will use the SOWS to define product requirements or sub-projects within the contract.
- Some firms use the term charter instead of statement of work. This can be confusing because, as we have seen, this term has another common use in the project management vocabulary.
The term that an organization may use to describe the statement of work is ultimately unimportant. It is the content that matters, and this content must establish clear expectations among all stakeholders.
Statement of Work: Audience
The statement of work is similar to a contract, in that each is a tool that clarifies responsibilities and actions in a relationship. The difference is in the audience each one is aimed at. While a contract is a formal agreement between two legal entities, an SOW is directed solely at stakeholders from the same legal entity. To clarify:
- When the customer and the project team belong to the same business, the SOW is the only project agreement required.
- When the project team and the customer are different legal entities, there will be a formal contract between the two. If this contract is very large and is broken into several sub-projects, the project manager may use an SOW for breaking the project into even smaller pieces and assigning them within the firm.
The Statement of Work Is Not a Contract
Although it is used to manage expectations and establish agreements, much like a contract, the statement of work as it is described here is not meant as a substitute for a contract.
Statement of Work: Minimum Content
Many different things may be included in a statement of work, but there are certain contents that must be included.
Why are we doing this project? is the question that the purpose statement attempts to answer. Why? is always a useful question, particularly when significant amounts of time and money are involved. Knowing the answers will allow the project team to make more informed decisions throughout the project—and will clarify the purpose for the customer.
There may be many “whys” involved here, but the purpose statement doesn’t attempt to answer them all. Neither the purpose statement nor the statement of work builds a complete business case for a project.
That should be contained in a different document, typically called either a business case or a cost-benefit analysis. If there is a business case, reference it or even copy its summary into the SOW
Purpose Statements Need to Be Clear
Avoid purpose statements like: “The purpose is to build the product as described in the specification document XYZ.” Or: “The purpose is to deliver the product that the client has requested.” Neither of these statements explains why the project is being done, so they are useless as guides for decision making.
Here is an example of a good purpose statement from an information systems project:
The purpose of this project is to gather revenue data about our subsidiary. During the spin-off of the subsidiary, the finance group needs this information about the subsidiary’s business in order to make projections about its future revenue. This data will come from the four months beginning June 1 and ending September 30. The finance group will be finished analyzing the data October 31, and won’t need it afterward.
Notice that this purpose statement doesn’t describe in detail what data is needed. That belongs in another document called the analysis document. Because the purpose statement was so clear, the team was able to make other decisions, such as producing minimal system documentation. The project team knew that the life of the product was so limited that it wouldn’t require lengthy documentation meant for future maintenance programmers.
The scope statement puts some boundaries on the project. Scope creep is one of the most common project afflictions. It means adding work, little by little, until all original cost and schedule estimates are completely unachievable. The scope statement should describe the major activities of the project in such a way that it will be absolutely clear if extra work is added later on.
Clarifying scope is more than just a fancy way of saying, “It isn’t my job.” All the cost, schedule, and resource projections are based on assumptions about scope. In fact, defining the limits of a project is so important that you will find boundaries being set in several different places besides the scope statement.
The deliverables section of the statement of work and the work breakdown structure also set boundaries that can be used later to determine if more work is being added to the project. Even a product description such as a blueprint can be a source for defining scope and setting limits on scope creep.
Use the scope statement to define a project’s place in a larger scenario. For instance, a project to design a new part for an aircraft will be a subset of the life cycle of the total product (i.e., the entire aircraft). The scope statement is the correct place to emphasize the relationship of this project to other projects, and to the total product development effort.
Specify What Is beyond the Project’s Scope
Be sure to specify what the Project will not deliver, particularly when it is something that might be assumed into the project. Some activities may be out of the scope of the project, but nonetheless important to successful completion.
For example, in the example below, “recruit trainers with subject-matter expertise” is obviously a necessary part of training development and delivery, but it is specifically excluded from the project by placing it in the list of “activities beyond the scope of this project.”
SAMPLE SCOPE STATEMENT
Project Management Training Roll-out
This project is responsible for all training development and delivery. Specifically, this project will:
- Provide o detailed statement of training objectives for approval by the
- Project Office, VP of Operations, and Director of Human Resources.
- Purchase the necessary equipment and outfit training rooms at each division office.
- Acquire the rights to use and modify training materials previously developed by training suppliers.
- Modify or oversee modification of the training materials to be consistent with company standards for project management.
- Produce or contract out the production of training materials.
- Train and certify instructors.
- Promote the training to the management team at all divisions.
- Oversee the scheduling of classes, instructors, and shipments of course materials.
- Oversee and authorize travel requirements.
- The following activities ore critical to the success of the project, but beyond the scope of the project:
- Standardize the company’s project management practices across divisions.
- Recruit trainers with subject-matter expertise.
- Identify the people who will attend the training.
- Schedule the classes at the individual sites at times that accommodate the people who will be attending.
- Administer training logistics for each site.
This scope statement is only one section within the project’s statement of work.
Product Scope versus Project Scope
Product scope can remain constant, while project scope expands. If an electrical contractor estimates the work on a job with the assumption that he or she will be installing a special type of wiring, the contractor would do well to clarify who is responsible for ordering and delivering the materials. Taking on that responsibility doesn’t change the product scope, but it adds work for the contractor, so the project scope is expanded.
Statement of Work: Deliverables
What is the project supposed to produce? A new service? A new design? Will it fix a product defect? Tell a team what it’s supposed to produce. This helps to define the boundaries of the project and focuses the team’s efforts on producing an outcome. Deliverable is a frequently used term in project management because it focuses on output. When naming deliverables, refer to any product descriptions that apply—a blueprint, for instance. Once again, don’t try to put the product description in the statement of work; just reference it.
Realize that there can be both intermediate and end deliverables. Most home owners don’t have a blueprint for their house, but they get along fine without it. At the same time, no home buyers would want their contractor to build without a blueprint. The distinction lies in whether the deliverable is the final product that fulfills the purpose of the project—in this case, the house—or whether it is used to manage the project or development process, like a blueprint.
Here are some other examples:
- A document specifying the requirements of a new piece of software is an intermediate deliverable, while the finished software product is an end deliverable.
- A description of a target market is an intermediate deliverable, while an advertising campaign using magazine ads and television commercials is an end deliverable.
- A study of a new emergency room admissions policy is an intermediate deliverable. The actual new emergency room admissions process is an end deliverable.
It’s important to note that project management itself has deliverables. The statement of work can call for deliverables such as status reports and change logs, specifying frequency and audience.
Always Start with a Detailed Product Description
If there is no detailed product description, then creating one should be the only deliverable for a project. Trying to nail down all the important parameters, such as cost, schedule, resource projections, and material requirements, is futile if the product specification isn’t complete, because the project team doesn’t really know what they are building.
Software product and information system projects are famous for committing this crime against common sense. It is premature to give an estimate for building a house before the design is complete, and it doesn’t work any better in other disciplines.
Statement of Work: Cost and Schedule Estimates
Every project has a budget and a deadline. But the rules should state more than just a dollar amount and a date. They should also answer questions like: How fixed is the budget? How was the deadline arrived at? How far over budget or how late can we be and still be successful? Do we really know enough to produce reliable estimates? And because cost and schedule goals have to be practical, it makes sense to ask other questions, such as: Why is the budget set at $2.5 million? or Why does the project need to be finished December 31? Since one of the goals of making the rules is to set realistic expectations for project stakeholders, these figures must be realistic and accurate.
Write It All Down!
Someone once observed that, when given a range of possible dates and costs, the customer remembers only the lowest cost and the earliest date. (How nice that the customer is such an optimist and has such great confidence in the project manager and his or her team!)
That is exactly why it is so important to get all assumptions and agreements written down and formally accepted. The written statement of work is a much better tool for managing stakeholders than is memory.
Statement of Work: Objectives
What are the criteria for success? If we produce the deliverables on time and on budget, what else does it take to be successful? Often, some important additional objectives are included in a statement of work.
For example, on a project to replace a section of an oil pipeline, a stated objective was “No measurable oil spills,” because the pipeline was in an environmentally sensitive area. And, when a department store chain installed a major upgrade to its nationwide inventory system, the stated objective was “Installation will not interrupt any customer interactions at the retail stores. “
Objectives should be specific and measurable, so that they can provide the basis for agreement on the project.
If the oil pipeline project had simply said, “The project will be executed in an environmentally sensitive manner” a project team would have no measurable guidelines. Instead it stated clearly, “No measurable oil spills,” thus providing guidance for important decisions during the project.
Objectives can also measure outcomes. Measuring the success of an advertising campaign is not based solely on cost and schedule performance in developing it, but on the impact it makes on the target market. So a stated objective might read:
Retail sales of our product will increase by 5 per-cent among 25- to 40-year-oldfemales living in the San Francisco Bay area, within three months of the beginning of the campaign, and by 10 per-cent after one year.
This objective won’t be measured by the ad agency when the magazine ads and television spots are completed, but the customer will certainly be aware of it for the year after the campaign is initiated.
Statement of Work: Stakeholders
In any statement of work, the project manager should identify anyone who will influence the project—that is, all the stakeholders. There are five key stakeholder roles that exist in any project: project manager, project team, sponsor, management, and customer. Each one is necessary for success.
Statement of Work: Chain of Command
Who reports to whom on this project? A statement of work must make this clear. A common way to illustrate the chain of command is with an organization chart. The need for a defined chain of command becomes increasingly important as the project crosses organizational boundaries.
Since customers also make decisions, it is often useful to include their reporting structure in the SOW as well.
Go beyond the Minimum
After including all the necessary content listed here, be sure to add any other assumptions or agreements that are unique to this project. But be careful. Putting “everything you can think of’ into the SOW will make it unmanageable. Remember that its purpose is as a tool to manage stakeholders.
Write the Statement of Work First
You, as project manager, need to write out the statement of work and then present it to the stakeholders. Even though you may not know all the answers, it is easier for a group to work with an existing document than to formulate it by committee. The stakeholders will have plenty of chance to give their input and make changes once the SOW is presented to them. (Experience has shown that after all the storm and fury of group discussion is over, you may find that as much as 80 percent of your document is still as you wrote it.)
Dealing with Change
The statement of work is a tool for managing expectations and dealing with change. Should there be disagreements once the project has started, these can often be solved by simply reviewing the original SOW.
But it is also true that the original agreements and assumptions may change during the course of a project. In this case, all stakeholders must understand and agree to these changes and the project manager must write them into the SOW.
The SOW that remains at the end of the project may be very different from the original document. The amount of this difference is not important; what is important is that everyone has been kept up to date and has agreed to the changes.