Guidelines for Statements of Work by nenehilario

VIEWS: 30 PAGES: 22

									    Guidelines for Statements of Work

               Version 1.0




1
Table of Contents
1.     PURPOSE OF THESE GUIDELINES                              4

2.     HOW TO USE THE TEMPLATE AND THESE GUIDELINES             4

3.     PURPOSE OF A STATEMENT OF WORK                           4

4.     GENERAL GUIDELINES FOR CONSTRUCTING THE SOW              5

4.1     Recommended Process                                      5

4.2     Involvement of the Client and DENR PMO                   8

4.3     Construction Guidelines and Hints                       10


5.     CURRENT SITUATION                                        11

6.     OBJECTIVES                                               11

7.     SCOPE                                                    13

8.     APPROACH                                                 13

9.     PROJECT MANAGEMENT                                       15

9.1     Management Approach                                     15

9.2     Project Organization                                    17

9.3     Roles and Responsibilities                              18


10.     ASSUMPTIONS                                             19

11.     APPENDICES                                              20

12.     COMMON QUESTIONS                                        20

12.1    When is a Statement of Work created?                    20

12.2    Is a Statement of Work required for every engagement?   20

12.3    Linkage to Project Plan?                                20

12.4    Linkage to Change Management Documents?                 21




                                                                2
12.5    Linkage to Prior Phase Work Products or Deliverables?                                        21

12.6    Who should prepare/contribute to the Statement of Work?                                      21

12.7    Once created, who should be familiar with the contents of the Statement of Work?             21

12.8    Can one project have multiple Statements of Work?                                            21

12.9    Can one Statements of Work cover multiple projects?                                          22

12.10   Once agreed to and signed, does the SOW ever get updated during the course of the project?   22




                                                                                                     3
1. Purpose of These Guidelines
This document is intended for Project Managers and is primarily addressed to them.

These guidelines are intended to:
          Provide an orientation to the Statement of Work
          Explain how to use the SOW template
          Provide guidance on constructing a Statement of Work
          Elaborate on key points within each section of the Statement of Work
          Address some frequently asked questions.

The guidelines are intended to help the thought process of developing a Statement of Work.
There is no “cookie cutter” solution for writing a Statement of Work, since each “deal” or
Client project is a unique combination of the Client‟s objectives, project scope, and project
approach. However, every Statement of Work contains common components and serves a
common purpose, and that is the focus of this document.

2. How to Use the Template and These Guidelines
The SOW template gives you the basic structure or outline for the standard Statement of Work.
It deliberately does not contain any instructions built into the body of the template. This avoids
the possibility that some of that wording may be left in the actual SOW and inadvertently
presented to the Client. All the instructions are in these guidelines. By starting with this
template, you can quickly get beyond the structural aspects of the document and focus on the
content of the specific sections.
The template does contain some recommended verbiage in:
          The introduction to the Scope Section
          The Management Approach Section
         The Roles and Responsibilities Section
Don‟t treat any of this wording as boilerplate that doesn‟t have to be read, modified, or
discussed with the Client. It represents a good place to start, but every project is different. Read
the instructions in subsequent sections of these guidelines for specific advice on these and all
other sections of the SOW.
The guidelines provide commonsense ideas, rules, and directions to help you construct a
reasonable SOW. They try to anticipate some of the variable aspects of different types of
projects. However, they are not a cookbook.
Within the guidelines, we have included some specific wording that can be used in certain
sections of the SOW.
3. Purpose of a Statement of Work
The Statement of Work is intended to serve two key purposes:




                                                                                                   4
          It is a formal contract between the DENR PMO and the Client

          It is the vehicle used to gain a common understanding with the Client

These two purposes are tightly coupled. The contract is important for ultimate protection of the
project, while the common understanding gives us a reasonable chance to manage the project
with the Client. In order to serve these purposes well, the SOW must be developed with active
Client participation and with intense attention to detail. The SOW, and the process to develop it,
must focus on being as specific as possible. The wording must leave as little room for
interpretation as possible.
A Statement of Work is used to document the key components of the engagement, with a
Client, including baseline scope, approach, and responsibilities. Like many documents, the
immediate value is in the thought process used in its preparation, and in the discussions with
the Client. The dialogue related to the preparation of the document is used to set expectations
for both the project and the Client, and the document itself serves as a record of those
expectations throughout the life of the project. The document is used as a basis for managing
the project on an ongoing basis, and for orientating new project team members. We have
consistently found that the absence of a written “deal” can lead to problems and
misunderstandings.

4. General Guidelines for Constructing the SOW
4.1 Recommended Process
Before You Start
Before you begin to develop the SOW, recognize that you must plan to develop a detailed MS-
Project Plan to support it at the same time. This is a basic rule for all project engagements and it
is unacceptable to have a SOW without a detailed plan. The SOW cannot possibly stand alone
because:
          You have to develop a task level plan identifying tasks, effort, and people assigned
           in order to know:
                  How many of what types of resources you need
                  How long the project will take in elapsed time. Elapsed Time is the total
                   number of calendar days (excluding non-work days such as weekends or
                   holidays) that is needed to complete an activity, irrespective of the Start and
                   End times . It gives a "real world view" of how long an activity is scheduled
                   to take for completion.
                  The cost based on effort by type of skill
          The detailed plan will drive out some key assumptions
          The detailed plan will force you to recognize key sizing assumptions that allow you
           to put legitimate quantifiers into the SOW in scope, approach, or assumptions
         The detailed plan will give you realistic dates for Client or third party tasks and for
          key milestones
Before you start writing, make sure that you have a sound understanding of the particular
engagement. There are several ways to get some of the basic information needed:


                                                                                                    5
          Talk to the Client Management Team
          Review existing documentation of current system
          Read the proposal, if there was one (see the section on Construction Guidelines and
           Hints for a mapping)
First Key Decision
With that as background, the first decision you have to make, when starting to develop the
SOW, is to define the boundaries of the project that you are describing. Almost every project, in
its broadest context, requires a fair amount of Client work and often third party work or
products as well. You need to decide if the Client or third party work activities need to be
included in the SOW and the supporting project plan. A number of factors will impact this
decision:
          Your ability to accurately define and size their work activities
          The degree of dependence on these activities for success on the project
          The Client‟s approach to dealing with the project team
          The likelihood of being able to tract their progress and report on it
         The degree of responsibility you want to take for managing their work activities
These are not simple questions to answer. They require a good understanding of the project and
the Client environment. This information should be known, and have been garnered from
discussions with the Client, before starting the SOW. This is a key step in managing the Client‟s
expectations and you don‟t want to be well on the way to completing the SOW before
discovering that the Client has a different concept of it.
The tough ones are the situations that fall somewhere in the middle. There is no single easy
answer. You have to know enough about the project and the Client environment to make the
right choice. If it isn‟t obvious or based on enough real knowledge, you have to discuss it with
the Client. Recognize that this decision impacts not only the concept of the boundaries of the
project. It also changes costs, time-frame, management approach, objectives, assumptions,
roles, scope, and approach.
Next Key Decision
How many phases of a multi-phase project will be described in the SOW? Hopefully this
decision is easier and the answer more obvious than the first one. However, it is just as
important. Since one of the primary goals for the SOW is to be as specific as possible, we
should try to write the SOW for one phase at a time. Unfortunately, there are many situations
where we are pressured to write a multi-phase SOW. Push back on this. Many times the
pressure is self-inflicted and the Client isn‟t the one who wants it. Sometimes, even when the
Client wants multi-phase they could be persuaded to limit the SOW with a good rationale.
If you cannot limit the approach to a single phase, then you have to make educated guesses on
the aspects of scope and approach that should normally have fairly precise counts. This
approach is risky insofar as these guesses will usually be off by a wide margin. This can be
mitigated somewhat by:
                  Making sure the Client understands the degree of uncertainty
                  Being very conservative in your estimates of effort (high) and your counts
                   (low) for the downstream work



                                                                                                 6
                  Putting appropriate wording in the SOW that makes it clear that these
                   numbers are subject to significant fluctuation
                  Trying to avoid putting any dollars, effort numbers, or dates in the SOW for
                   the downstream phases
                 Putting wording in the Approach Section that make it clear that there will be
                  a re-estimating and re-costing event at the end of each phase prior to
                  proceeding to the next phase.
Recognize that you will have to build a detailed project plan for every phase that is included in
the SOW. This should be incentive enough to make it worthwhile to push very hard to only
cover one phase.
Starting to Write
It should usually be fairly easy to write the first 2 sections; Current Situation and Objectives.
These are both fairly short sections, each about a page or less. Starting here also allows you to
feel as if you got some of the sections taken care of before you launch into the more substantial
parts. It also helps you discover if you understand some of the basic information about where
this project is coming from and why. If you discover that these 2 sections are a struggle, then
you probably need to do more research on what the project is really about.
Obviously, the two most substantial sections are Scope and Approach. There are a variety of
opinions on the best way to get started with these sections. Some people advocate starting with
the Approach and then moving back to Scope. Most feel that describing the Scope first is a
more logical flow since the Scope drives the Approach. Realistically, either technique works.
Pick the one that suits you and the situation best.
Multiple Threads and Iterations
No matter which section, Scope or Approach, you start with first, you will end up developing
several sections and the project plan in conjunction with each other. You will also need to make
multiple passes through them in order to keep them connected. The best way to envision the
process is to think of 5 pieces of paper side by side: Scope, Approach, the Project Plan,
Assumptions, and SOW Open Issues. If you developed the Scope Section first, then you have
probably already started to list some of the Assumptions and definitely begun to list SOW open
issues. You will continue to maintain and expand these lists as you move into developing the
Approach Section. Try to continuously get resolution of the open issues while you continue to
develop the SOW. Don‟t wait until you have written as much as possible thinking that you can
then resolve all the issues at once.
The Approach Section and the Project Plan go hand-in-hand. Some people prefer to develop the
plan first and then move the activities from the plan into the Approach Section. If you take this
approach, there will be some activities that need to be in the plan but aren‟t helpful in the SOW.
In general, you should be able to use the appropriate DENR Project Plan Template to provide a
large part of the information in the Approach Section. Again, as you are developing the plan
and the Approach Section, you will be adding items to the Assumptions list and the SOW open
issues list. In addition, you will probably discover some things, usually quantifications that
drive your estimates, which need to be added to the Scope Section. An example would be the
number of interfaces that you plan to build.
After you finish your first cut at the Scope, Approach and Project Plan, move on to the Project
Organization and Roles & Responsibilities Sections. Based on the Project Plan, you have a first



                                                                                                  7
cut at the staffing needed to get the work done. Expand this by reviewing the key management
roles, users needed, and sponsor/steering committee makeup. Again, some changes may occur
in the Scope and Approach Sections and the Project Plan as a result of completing these
sections.
Now look at the Management Approach Section in the template and decide what changes need
to be made for your particular situation. Pay particular attention to fixed-price versus T&M, co-
management of the project and risks for vendor outsourced projects.
Next, review the Assumptions to see if you have eliminated some, need to add more, or need to
move some to another section. Very often Assumptions related to the Client work better in the
Approach Section as activities or in the description of a Client‟s role/responsibility in the
Project Management Section. Also, take any Assumptions that qualify as Risks and move them
there.
Finalization
After you have completed your first cut of the entire SOW, review your SOW open issues list
and make sure all items have been finalized. Review the Approach and Project Plan one more
time to make sure that they line up. You should then make a pass through the document to
eliminate redundancy and any wording that doesn‟t help clarify the deal. Then review it to
make sure that it reads easily, won‟t insult the Client, and that all names are correct. Then have
a DENR PMO representative read it to see if they can easily understand it.


4.2 Involvement of the Client and DENR PMO
The previous section was written as if you developed the SOW pretty much by yourself before
you showed it to the Client or DENR PMO. In fact, this does happen sometimes and it is
frequently a disaster. Obviously, both the Client and DENR PMO, in turn, need to see the SOW
and agree that it properly represents the deal.
Clearly, the sooner each of these groups can be involved in the development of the SOW the
easier it will be to get them to feel comfortable with it. However, this is not a simple matter
since often these groups will be trying to push the SOW in different directions. There is no one
approach to involving these groups that works for every situation.
If you have developed SOWs before and understand what’s needed in an SOW to be
comfortable, then:
          Quickly develop your first cut of the SOW
          Give DENR PMO or QA the first cut to review
          While they are reviewing it, meet with the Client to review individual sections
                  Make them aware that internal project reviews will be necessary
                  Don‟t show them anything with dollars, dates, or effort numbers
                  Validate the basics of the Approach
                  Have them answer your questions on Scope
                  Review the Management Approach Section
                  Get them to help you prepare the Project Organization and Roles and
                   Responsibilities Sections



                                                                                                 8
                  Introduce the Assumptions that you have so far
          Get first cut feedback from DENR PMO or QA
          Resolve conflicts between these two sources of feedback and update the SOW
          Present a complete draft to DENRPMO and conduct a formal review with them
          Make updates based on DENR PMO review session and meet with the Client to
           review the complete draft
          Iterate changes back through DENR PMO/QA and the Client
If you have not developed SOWs before, or you are unsure as to what’s needed in an SOW
to be comfortable, then:
          Meet with DENR PMO first to get help on the basic construction of this SOW
          Develop your first cut of the SOW
          Meet with DENR PMO again to review the first cut
          Make the necessary changes
          Meet with the Client to review individual sections
                  Make them aware that internal project reviews will be necessary
                  Don‟t show them anything with dollars, dates, or effort numbers
                  Validate the basics of the Approach
                  Have them answer your questions on Scope
                  Review the Management Approach Section
                  Get them to help you prepare the Project Organization and Roles and
                   Responsibilities Sections
                  Introduce the Assumptions that you have so far
          Review feedback from the Client with DENR PMO
          Resolve any conflicts, determine a strategy for going back to the Client, and update
           the SOW
          Meet with the Client to review the complete draft
        Iterate changes back through DENR PMO and the Client
These are just two variations that provide simple outlines of steps to follow. These are not the
only ways that you can get to an agreement on the SOW. However, there are several key points
inherent in both suggested approaches:
          Don‟t develop the SOW in a vacuum
          Don‟t present a complete SOW to the Client before it is reviewed and approved by
           DENR PMO
          Get DENR PMO involved early
          Make the Client feel that they are involved in the construction of the SOW
          Plan on multiple iterations




                                                                                               9
          Don‟t get yourself stuck in the situation where the Client thinks that some part of the
           SOW is finalized and DENR PMO is still reviewing or modifying it


4.3 Construction Guidelines and Hints
   The SOW is the baseline document for controlling change as the project progresses. It is
    also the document that explains the “deal” to the Client. Everything you put into the SOW
    should be included for one or both of these reasons. If it doesn‟t serve either of these
    purposes, then it probably doesn‟t need to be in the document.
   A SOW should not be written in “legalese” or in technical or industry jargon. It should be
    written in the Client‟s language, or language that is commonly understood - the whole point
    in developing a SOW is to put down on paper your understanding with the Client of the
    work to be performed.
   Quantify - Especially in the Scope and Approach Sections, you need to insert numbers if
    you aren‟t listing every item in a group. Examples: 4 interfaces, 32 on-line programs, 3 day
    workshop, 5 users, 100 test scenarios.
   Be specific. Most Clients will interpret any vagueness to their advantage.
   Try to have the SOW cover just one phase of a multi-phase project. More than likely, if you
    try to describe multiple phases, the SOW will be too large to easily comprehend and too
    speculative in later phases.
   The SOW shouldn‟t introduce concepts or rules of engagement to the Client that haven‟t
    been discussed previously with them.
   Don‟t be redundant. You are wasting your time and the Client‟s time by stating something
    more than once. More importantly, in an attempt to be creative, you probably worded it
    somewhat differently in each place. This flies in the face of being specific since you have
    now given people a chance to interpret the real intent in multiple ways. Any Client worth
    their salt will interpret any ambiguity to their advantage.
   Try to make the entire document concise. Remember, you want the Client to read it and
    understand it. Most SOWs should be able to be kept under 30 pages without attachments.
   Try to make the document look specific to this project. Don‟t use the term “Client”. Use the
    Client‟s actual Division or Departmental name within DENR. Use the name of Client‟s
    personnel and general terminology wherever possible.
   Don‟t insert boilerplate.
   Read every section yourself as if you were going to put your personal funds at risk with this
    project. You are committing yourself to a contract, treat it seriously.
   Don‟t quote the DENR methodology all over the document; sometimes the buzzwords
    don‟t explain things very well to a Client who is unfamiliar with them. The Client wants
    and needs a clear understanding of what you are doing on the project, so try to be as
    specific as possible.
   Don‟t get carried away with appendices. Only add items that help explain the deal without
    implying other commitments, being redundant, or creating conflicting wording.




                                                                                                  10
   It is important that you do not explicitly or implicitly commit to delivering business results
    associated with the engagement. You are delivering a System that will achieve the expected
    business results.

5. Current Situation
Purpose
This section briefly describes the Client's business and some of the key events, activities, or
decisions that led up to this project. This section serves as an introduction to the SOW. We are
probably not telling the Client anything they do not already know. This section is typically
more for the benefit of those not familiar with the project. To net it out, this section describes a
little bit of history on how it got to today.
Recommendations
   This is a good place to insert items that preceded your involvement or that of DENR PMO
    to make it clear that you do not have responsibility for those items. It can also help to
    baseline this project by making it clear that this project is relying on the accuracy of prior
    work or documents. Some examples:
          Key decisions that impact the success of this project (for example: in-house
           development versus COTS/GOTS implementation)
          Prior project phases (for example: a business redesign completed by a vendor)
          Documents that this project is based on (for example: a BAA or a cost/benefit
           analysis)
   Define the compelling event here
Cautions
   Make broad statements about business benefits associated with the project but stay within
    the bounds of the Business Case.
   Be brief.
   Don‟t start citing project goals or objectives, wait for the next section.
Length
No more than 1 page.

6. Objectives
Purpose
This section briefly defines the business objectives that are driving the project, and the
expected outcomes at project completion. However, it is important to distinguish between the
two sets of objectives: Client business objectives and the project/phase objectives related to the
specific SOW.
Client business objectives - are major business objectives that the Client has identified as
goals for DENR overall or for one of its divisions. They are typically related to improvements
in worker effectiveness, reductions in cost, improvements in operating efficiency, or
improvements in workflow. Use language to indicate that these are the Client‟s business



                                                                                                  11
objectives. They must be mentioned separate from the specific project/phase objectives. The
project/phase may be contributing to the achievement of these benefits, but the project is not
uniquely responsible for their attainment.
Project/phase objectives - are those goals that have been set specifically for the project or
phase, and are achievable independently of other factors within DENR or its divisions. If this
SOW is covering one phase of a multiphase project, then both the project and phase objectives
should be described. Usually, these objectives can be defined in a few sentences. They typically
describe the final output from the project/phase and what will occur as a result of completing
the project/phase.
Constraint Prioritization - This section should also include, under the project/phase
objectives, an identification of the prioritization of the triple constraints. This is a key element
in defining the management approach to dealing with changes in the project schedule.
Therefore, the prioritization (high, medium, low) of the 3 constraints (scope, elapsed time, and
budget) should be documented here. After identifying them, you should point to the
management approach section that will describe how you will use that prioritization to manage
the project.
Recommendations
   Specific project/phase objectives that are reasonable:
          Replace a system with a new software package
          Build and maintain a technical infrastructure
          any other
   Make the project/phase objectives measurable so that it is clear that we have achieved them
    at the end of the project/phase.
Cautions
   Be very careful, do not commit to things you cannot deliver. The Client may hope to
    achieve a specific set of business benefits as a result of the project, but you, the project
    manager and DENR PMO are rarely in a position to commit to these benefits.
   Examples of Client business objectives that shouldn‟t be included in the project/phase
    objectives are:
          Improve overall productivity
          Increase fees and revenues
          Cut overall operating costs
          Improve employee satisfaction and reduce inefficiency
   Don‟t jump the gun and start listing individual project deliverables or activities here; leave
    them for the next section.
   Make sure that the triple constraints are mentioned here and that one must be prioritized as
    high, one as medium, and one as low.
Length
No more than 1 page.




                                                                                                   12
7. Scope
Purpose
This section identifies which aspects of the services, such as customers, products, processes,
organizations, locations, or applications, are to be included in the project and which aspects are
to be excluded. It determines what other external influences and impacts, such as interfaces,
customer needs, and regulatory requirements, are to be addressed. We usually refer to scope as
the “Breadth” of the project since it defines “What” we will try to address in the project.
This section is extremely important. It is one of the key areas to establish a baseline for the
project that the Client should be able to easily understand since it addresses aspects of the
services they provide..
Recommendations
   Be specific or quantify. That is, try to estimate the number of elements. For example:
          List the specific business processes, or
          Develop a reasonable estimate of the number of business processes
   In the Out-of-Scope Sections, be sure to specify items that might normally be considered
    in-scope.
   List process groups, process threads, or processes
   List systems, sub-systems, interfaces, screens, reports, modules, programs
   For Data Scope list databases, files, entities, elements
   For Technology Scope list platforms, operating systems, database technology, networks,
    and processors. You need to list the specific versions of all dependent software since
    changes in those software versions during the project can require rework and delays in
    availability can cause other tasks to slip behind schedule
Cautions
   Don‟t start describing work activities in this section. It is very tempting because as you talk
    about scope you want to say what you are doing about it. Don‟t do it. You will end up
    repeating yourself in the Approach Section and confusing the Client.
   Don‟t try to write sentences in this section and you will get it done a lot faster. Besides, if
    you want to use a verb, it probably belongs in the Approach Section.
   As a reminder, we define scope in measurable units rather than activities. For example,
    since data conversion is not a „countable‟ item, it should be addressed under the Approach
    Section as opposed to the Data Scope Section. The same holds true for something like
    “development of system architecture” - that again would be mentioned in the Approach
    Section as opposed to the Technology Scope Section.
Length
This is very difficult to judge. The length depends greatly on the breadth of the scope, the level
of detail that is known, and the type of project. Typically 3 - 6 pages for most projects.

8. Approach
Purpose


                                                                                                      13
This section describes “How” we will perform the work required to complete the project. It
defines the work by:
          Laying out a broad picture of releases and phases
          Identifying the specific activities that people on the team will perform
           Describing the tangible work products and deliverables that result from these
            activities
We usually refer to this section as the “Depth” of the project. The Approach Section is
probably the most important section of the SOW since it drives the project‟s time-frame,
staffing requirements and cost. This is the first section that describes information that isn‟t
based solely on what the Client has told you.
Recommendations
   Approach Overview should be used to present a summary view of the project/phase/release.
    It is a way of setting the stage for the activity descriptions that will follow. Usually, the best
    technique for conveying this information is in the form of a high-level Gantt chart. Maybe,
    but process flow works well also. This chart should portray what phases precede, follow, or
    parallel the current phase. It might show the release sequence. It might have a breakdown of
    sub-phases. Usually, some narrative should accompany the chart that can summarize the
    purpose of the various breakouts in the chart. Using dates in the chart may be appropriate
    but see the cautions below.
   Project Activities describes the work to be performed under this SOW. This includes:
          A title for the activity
          A brief description or purpose of the activity
          An identification of the work product created by the activity
          A notation of what group or party is responsible for the activity
   Deliverables is a list of the tangible items that will be presented for acceptance. This should
    include:
          A title for the deliverable
          A brief description of the deliverable
          A notation of what group or party is responsible for the deliverable
   The Approach Section should map to the project plan. That is, the activities, the
    deliverables, the time scale with phases and milestones must be the same. Some activities
    from the project plan don‟t belong here. Some start-up, close-down, management, and
    coordination activities need not be mentioned.
   The work activities described should be at the activity level. Task level is too detailed and
    rarely provides better insight to the Client. But the MS-Project Plan should, in any case, be
    created at the Task level.
   Examples of deliverables can be very helpful in setting the Client‟s expectation. Whenever
    this seems helpful, include them as attachments.
   If there is no clear separation of responsibilities for activities or deliverables, between the
    project and the Client, then drop the responsibility column from the table.




                                                                                                      14
Cautions
   In the Approach Overview, it often seems appropriate to show the specific weeks or months
    across the top of the Gantt chart. This information is often viewed as very important by the
    Client. However, this can easily be viewed as a commitment to specific dates. A better
    alternative is to show months or weeks with just a sequence number rather than actual
    dates.
   Be careful with “joint responsibility”, it is an ambiguous choice. It is better to split the
    activity into several components, if possible, each of which can be uniquely assigned to one
    party.
   Don‟t list activities that won‟t be managed by you, the project manager. A good example is
    third party software installation. This is an activity that needs to happen, but it shouldn‟t
    appear that you are responsible for it. It is better to represent this type of activity as out-of-
    scope, or an assumption, or a Client responsibility.
   Remember, don‟t list work products under deliverables. (A Template is a work product; the
    document created by the Template is the Deliverable).
Length
The Overview should be about 1 page. The length of the Project Activities Section will
obviously vary greatly depending on how many phases are being defined. A single phase,
described concisely should probably be 3-5 pages. The deliverables for a single phase should
probably be 1-2 pages.

9. Project Management
9.1 Management Approach
Purpose
This section outlines the management techniques that DENR PMO and you, the Project
Manager, agree to use to maintain control of the project. The processes are outlined here in a
fairly brief form because the intent is to get a clear understanding with the DENR PMO at the
start of the project. Many of these techniques will require more extensive procedures to actually
implement on the project. However, those detailed procedures don‟t need to be in the SOW.
Recommendations
   The template includes a complete description of the management techniques that should be
    addressed in this section. Use the template as a place to start. Read it carefully and figure
    out how you want to modify it for your specific project.
   If you don‟t intend to use a particular management technique, then remove it from this
    section.
   This section assumes joint management responsibility - the Project Manager, DENR PMO
    and the Client - for the project. If this is not the case make the appropriate changes in the
    introductory paragraph and any other sections.
   Agreed-Upon Baseline - probably doesn‟t need to be changed very often
   Process to Monitor Progress - probably doesn‟t need to be changed very often as there are
    DENR PMO established processes to manage this.




                                                                                                    15
   Means of Communication - probably doesn‟t need to be changed very often as there is a
    standard communications plan established by OITS in the UMT Tool, concerning monthly
    project status reporting.
   Approach for Dealing with Issues -established via a Problem and Issues Log in the UMT
    Tool..
   Change Control Procedure - this section is critical on every type of project. Most
    importantly, the Client needs to understand it and agree with it. Include the following bullet
    points to the list that defines what a change is:
           Impact caused by a change in the assumptions defined in this Statement of Work
           Impact of any risk items defined in this Statement of Work
           Delays or rework caused by items identified in this Statement of Work as Client
            responsibilities or activities
           Delays caused by a change in previously agreed-upon acceptance criteria
   Risk Management - the risks identified here should be limited to key/major known risks
    that are outside the direct control of the Project or the Client. Try to limit the list to no more
    than 5-6 items. Some examples of areas of risk are:
           Use of unproven technology or software
           Extremely aggressive project schedule driven by an external event
           Results of interim project activities (e.g. workshops and labs) may have
            unanticipated effect on project scope and schedule
           Loss of critical project team members
         Change in business climate/priorities which causes key personnel to be re-deployed
    A useful way to present the risks in the table is to group them into categories, such as
    Program Approach/Scope, Vendor Management, Technology, etc. They should later be
    transferred via the Risk/Issues Tab into the UMT Tool during the Planning & Design phase.
   Acceptance of Deliverables - the template presents a simple outline of deliverable
    acceptance with the expectation that a more detailed procedure, specific acceptance periods,
    and specific criteria will be defined when the project gets underway. Sometimes this section
    needs to be expanded to address some of these areas when we anticipate problems getting
    the deliverables accepted or getting the Client to agree to the detailed procedure. This
    section should be looked at carefully for a fixed-price vendor project. If payments are tied
    to deliverables, you will probably need to expand this section.
   Project Completion Criteria - the template provides a very brief statement to define
    completion. This will work in many situations. However, make sure that you think about
    the wording in light of your specific project. Recognize that this section describes what
    conditions must be met for the project to be considered complete. It is especially important
    to the Project and to the DENR PMO because it defines when you are “done” and thus have
    no further obligations under the specific SOW. This can be quite important in some
    situations when you are trying to sanction a final payment to the vendor. It also helps to
    clarify any questions about any warranty work that the Client may expect from the Project.
    This section is not a complete list of all deliverables and their acceptance criteria. Those are
    covered in the Approach Section and with a detailed list of acceptance criteria implemented


                                                                                                    16
    as the project progresses. It is a short list of deliverables, or tasks, or events that relate to the
    final stages of completing the specific project covered by the SOW. Depending on the stage
    of the life-cycle, vendor involvement and the type of contractual arrangement (if any), this
    description can vary greatly. For example:
           The Project Charter created in the Project Initiation Phase might simply state that
            completion of the Project Closeout Review by the EPMO QA team to the DENR
            PMO completes the project.
           If the entire project is to create a Requirements Specification, then state that the
            completion of the project is based on Client acceptance of the report or document..
           An integrated application might state that completion occurs upon the satisfactory
            execution of an agreed-upon set of test cases, or the implementation/completion of
            a Pilot or official hand-over of a system at the end of Deployment
           A fully deployed release might state that completion is based on satisfactory
            execution of the agreed-upon deployment site readiness test or using the
            application to process production data.
           A Level of Effort is done when the time runs out and the Client wants to get an
            appreciation of the amount of work still pending. This again would be applicable to
            a vendor based situation.
Cautions
   Don‟t just include the Management Approach Section as presented in the template. You
    have to review it carefully in light of the specific project and Client situation.
   Don‟t cite Client activities or responsibilities as risks. Don‟t repeat assumptions as risks.
   Make sure you make the changes related to Client management and Client team members
    that were described in the recommendations.
 Again, make sure the Client reads this section carefully and agrees with it.
Length
3-4 pages.

9.2 Project Organization
Purpose
This section presents the organizational structure of the project.
Recommendations
   Make the organization chart as simple and easy to understand as possible
   Make sure it represents the actual plan for the organization
   Include all key management roles that need to be associated with the project Be sure to
    adequately reflect the total governance structure.
   Be sensitive to the Client‟s perception of what the organization chart implies about their
    position
Cautions
   Usually, you should identify if a role is filled by a Project or Client person.




                                                                                                      17
   Be sensitive to the Client‟s perception of what the organization chart implies about their
    position
Length
1 page.

9.3 Roles and Responsibilities
Purpose
This section describes all of the key roles on the project that were identified in the organization
chart. It might also describe some other roles that weren‟t actually shown in the organization
chart.
Recommendations
   The first table included in the template breaks down the responsibilities associated with
    project management. It is written with the assumption that the Project Manager and the
    Client have shared management responsibility for a project. That may not always be the
    case; the Client in most cases would like to be kept informed on a weekly basis concerning
    the project‟s progress and impending Risks that cannot be mitigated. Carefully review the
    responsibility column and fill in the appropriate person‟s name. There are several key
    considerations when doing this:
          Make sure you understand and reflect the project‟s responsibilities carefully. Be
           totally realistic. Think about every line where you indicate Project responsibility in
           light of your ability to control that item.
          If the project isn‟t going to be co-managed, then change the introduction
           appropriately and reflect the changes in the responsibility column.
          Add or delete rows as needed to properly reflect the project.
          Avoid shared responsibility. Split it into two rows and describe the difference
           wherever possible.
          Make sure the Client looks at this table carefully.
   The second table included in the template provides a simple structure for describing the
    roles and responsibilities of other key members of the team. Key points in using this table
    are:
          Describe as many roles as possible.
          Name the person for a role if known.
          Use the time required column to ensure proper commitment of Client resources.
           Also, include calendar periods in this column if it helps.
          Don‟t forget executive sponsors, steering committees, and user personnel.
          Identify how many of certain types of resources are needed if more than 1.
Cautions
   In the Approach Section, we have already indicated those work activities and deliverables
    for which the Client has responsibility. Don‟t repeat them here.




                                                                                                  18
   Try not to turn this into an extensive list of Client responsibilities. It should reflect role
    definitions. Other items that the Client must provide belong in the Approach Section or
    under assumptions.
Length
2-3 pages.

10. Assumptions
Purpose
This section is used to describe items that we have determined must be in place to support the
project. In other words, if any of these items turn out to be not valid then the project‟s schedule,
cost, or scope will be impacted. Assumptions are items that cannot be proven to be true, but if
proven to be false would have an impact on the project.
Recommendations
   Include basic physical space and equipment items that needs to be provided. These types of
    items are better here than in the Roles and Responsibilities Section. Specify numbers.
   Group the Assumptions by categories
   Be specific and quantify
   Use this section to identify:
            Prior work or documents as the basis of this project‟s work
            Work that‟s out of scope
            The need for certain documents to be available
            That technical compatibility is assumed
            A particular technique in the use of a product or tool
            The use of particular standards like programming or documentation
Cautions
   Don‟t put items here that have already been mentioned elsewhere.
   Don‟t include items that you know won‟t really impact the project if proven false.
   Use this section sometimes to identify scope items that are out of scope. Usually, it is better
    to include them in the Scope Section as items out of scope. Never, put them in both places.
   Sometimes it works to use this section to identify work activities or deliverables that are not
    included in the project. Usually, it is better to include them in the Approach Section as items
    that are excluded. Never, put them in both places.
   Sometimes it works to use this section to identify certain types of Client responsibilities.
    Usually, it is better to include them in the Roles and Responsibilities Section or in the work
    activities portion of the Approach Section. Never, put them in multiple places.
 Be sure to only use realistic assumptions. Do Not assume away risk or reality!!
Length
Generally, 1-2 pages.



                                                                                                     19
11. Appendices
Purpose
This section should be used to provide additional material that helps to explain and bind the
project.
Recommendations
   Any item included as an appendix should clarify some portion of the SOW.
   Sample deliverables are very helpful as an appendix.
Cautions
   Detailed management procedures are not generally needed as appendices.
   Don‟t include a detailed work plan or detailed budget. The work plan is redundant to the
    Approach Section. The detailed budget provides no value to the Client by being included.
Length
Make it as short as possible.

12. Common Questions
12.1 When is a Statement of Work created?
For a new project, the SOW should be developed as early in the Client Value Cycle as
possible. The SOW should be prepared, approved, and agreed to by the Client prior to starting
the project work. Usually, this means getting it completed before you actually have resources
on the ground. If this happens, the best approach is to only have a few resources on the project
and have them all dedicated to developing and finalizing the SOW.
It is recommended that the Statement of Work be created in the Project Initiation phase before
creating the Project Charter. In fact it will be a viable source of input to the Charter.
Alternatively, the SOW can be created towards the end of the Project Initiation phase and prior
to the starting of the Planning & Design phase. .

If the development of the SOW is delayed, and project activities are initiated, the risk of
misunderstandings between the Project Manager and the EPMO increases exponentially. There
is no baseline so it is very hard to recognize and get agreement on what constitutes a change.
You will lose leverage in negotiations with the EPMO especially if they feel they need to
closely scrutinize the content.

12.2 Is a Statement of Work required for every engagement?
Absolutely. A Statement of Work is required for every Project or Engagement. No exceptions.

12.3 Linkage to Project Plan?
The Approach Section of the SOW should map directly to the activity level items in the MS-
Project Plan. See more detail on this in the Approach Section of these guidelines.




                                                                                                20
12.4 Linkage to Change Management Documents?
All changes that are identified during the project will be documented on a Change Report
designed by the EPMO. The changes are almost always initiated by the Client and should
therefore be negotiated with the Client, approved and signed, after which the Change Report
will serve as a modification to the SOW. To ensure that this is clearly recognized, the Client
should sign the Change Report

12.5 Linkage to Prior Phase Work Products or Deliverables?
If the SOW is prepared in the Planning & Design phase, then including the deliverables of the
Project Initiation phase in the SOW can be very helpful if done properly. The best approach is
to make reference to the deliverable and possibly the specific section of the deliverable in the
SOW. This works better and simplifies the SOW as opposed to cutting and pasting the
document into the SOW or attaching it to the SOW. The best example of where this can be very
helpful is in the Scope Section.

Some cautions related to using prior phase deliverables;
       Always read the deliverable carefully to see if it has conflicting or vague wording
          that needs to be cleaned up
       Be especially cautious if the project team didn‟t produce the deliverable
       Make sure the deliverable doesn‟t conflict with wording in the SOW
       Make sure the deliverable doesn‟t make unrealistic statements about dates, dollars,
          or benefits

12.6 Who should prepare/contribute to the Statement of Work?
The Project Manager, representatives of the DENR PMO and the Client can contribute the most
to the SOW as they will be involved the most with the project. They will have the background
and the exposure required to put down on paper the key points of the engagement. This group
may include: DENR PMO Director, Project Manager, EPMO PMA, Subject Matter Experts,
Technical Architect, “Business Manager”, and others. This will vary with each situation, and
therefore there is no specific job title that can be associated with this responsibility.

12.7 Once created, who should be familiar with the contents of the Statement of
Work?
Everyone working on the project, DENR PMO, and Client resources should be aware of the
key aspects in the Statement of Work regarding scope, approach, deliverables, objectives, and
responsibilities. That does not mean that the SOW is a document that is directly referenced
every day on the project, but it does set the ground rules that will bind the project team‟s work
going forward, and the team needs to be aware of these ground rules. Once the project is
underway and the key staff is assigned to the project, it may be beneficial to conduct a project
team walk-through of the SOW.

12.8 Can one project have multiple Statements of Work?
Yes, if the project consists of multiple sub-projects, there may be one statement of work for
each sub-project, and a global, or program-level SOW that covers the common characteristics
of the work. A project should also have one SOW per project phase, so in this sense there
would be more than one SOW for a project over time.




                                                                                                 21
12.9 Can one Statements of Work cover multiple projects?
This does happen occasionally. However, you should try to avoid it, especially, if the projects
are reasonably discrete with separate time-lines, objectives, user constituencies, or approach.
Separate SOWs make the documents more manageable and easier to understand.

12.10 Once agreed to and signed, does the SOW ever get updated during the
course of the project?
Yes, it does, especially when there is an agreed upon change in Scope.




                                                                                                  22

								
To top