ZeePedia buy college essays online


Project Management

<<< Previous PROJECT PLANNING (CONTD.):The Statement of Work (Sow) Next >>>
 
img
Project Management ­MGMT627
VU
LESSON 21
PROJECT PLANNING (CONTD.)
Broad Contents
The Statement of Work (SOW)
Guideline for Preparing Statement of Work (SOW)
21.1
The Statement of Work (Sow):
As already mentioned in Lecture 15, the Statement of Work (SOW) is a narrative description of
the work required for the project. The complexity of the Statement of Work (SOW) is
determined by the desires of top management, the customer, and/or the user groups. For projects
internal to the company, the Statement of Work (SOW) is prepared by the project office with
input from the user groups. The reason for this is that user groups tend to write in such scientific
terms that only the user groups understand their meaning. Since the project office is usually
composed of personnel with writing skills, it is only fitting that the project office prepares the
Statement of Work (SOW) and submit it to the user groups for verification and approval.
In case of projects external to the organization, as in competitive bidding, the contractor may
have to prepare the Statement of Work (SOW) for the customer because the customer may not
have a team of people trained in its preparation. In this case, as before, the contractor would
submit the Statement of Work (SOW) to the customer for approval. It is also quite common for
the project manager to rewrite a customer's Statement of Work (SOW) so that the contractor's
line managers can price out the effort.
As far as a competitive bidding environment is concerned, the reader should be aware of the
fact that there are two Statements of Works (SOWs)-- the Statement of Work (SOW) used in
the proposal and a "Contract Statement of Work" (CSOW). There might also be a proposal
"Work Breakdown Structure" (WBS) and a "Contract Work Breakdown Structure" (CWBS).
Special care must be taken by contract and negotiation teams that all discrepancies between the
Statement of Work (SOW)/ Work Breakdown Structure (WBS) and Contract Statement of
Work (CSOW)/ Contract Work Breakdown Structure (CWBS) are discovered, or additional
costs may be incurred. A good (or winning) proposal is no guarantee that the customer or
contractor understands the Statement of Work (SOW). For large projects, fact-finding is usually
required before final negotiations because it is essential that both the customer and the
contractor understand and agree on the Statement of Work (SOW), what work is required, what
work is proposed, the factual basis for the costs, and other related elements. In addition, it is
imperative that there be agreement between the final Contract Statement of Work (CSOW) and
Contract Work Breakdown Structure (CWBS).
It is important to note that the Statement of Work (SOW) preparation is not as easy as it sounds.
Consider the following:
The Statement of Work (SOW) says that you are to conduct a minimum of fifteen tests to
determine the material properties of a new substance. You price out twenty tests just to
"play it safe." At the end of the fifteenth test, the customer says that the results are
inconclusive and that you must run another fifteen tests. The cost overrun is $40,000.
The Navy gives you a contract in which the Statement of Work (SOW) states that the
prototype must be tested in "water." You drop the prototype into a swimming pool to test it.
Unfortunately, the Navy's definition of "water" is the Atlantic Ocean, and it costs you $1
million to transport all of your test engineers and test equipment to the Atlantic Ocean.
147
img
Project Management ­MGMT627
VU
You receive a contract in which the Statement of Work (SOW) says that you must transport
goods across the country using "aerated" boxcars. You select boxcars that have open tops so
that air can flow in. During the trip, the train goes through an area of torrential rains, and the
goods are ruined. The customer wanted boxcars that were aerated from below. The court is
currently deciding who should be blamed for misinterpretation of the word "aerated."
These three examples show that misinterpretations of the Statement of Work (SOW) can result
in losses of hundreds of millions of dollars a year. Common causes of misinterpretation are:
Mixing tasks, specifications, approvals, and special instructions
Using imprecise language ("nearly," "optimum," "approximately," etc.)
No pattern, structure, or chronological order
Wide variation in size of tasks
Wide variation in how to describe details of the work
Failing to get third-party review
Note that misinterpretations of the statement of work can and will occur no matter how hard the
quest for perfection during the definition phase. The result is creeping scope, or, as one
telecommunications company calls it, "creeping elegance." The best way to control creeping
scope is with a good definition of the requirements up front. Unfortunately, this is not always
possible.
For example, in some industries, such as aerospace, defense, and Management Information
System, creeping scope had become a way of life until recently. In the Information Technology
Group of a major appliance manufacturer, the project manager made it clear that she would not
accept any scope changes once the definition of the requirement (prepared by the user group)
was completed. Midway through the project, the user group tried to change the requirements.
The project manager refused to accept the changes and, against the wishes of the user group, put
all requests for changes into a follow-on enhancement project that would be budgeted for and
scheduled after the initial project was completed. When the initial project was completed and
installed at the user's location, the users stated that they could live with the original package,
and the enhancement project was neither funded nor approved.
Keeping the above-mentioned factors in view, today, both private industry and government
agencies are developing manuals on SOW preparation.
21.2
Statement of Work (Sow) Preparation Guidelines:
1. Firstly, every Statement of Work (SOW) that exceeds two pages in length should have a
table of contents conforming to the Contract Work Breakdown Structure (CWBS) coding
structure. There should rarely be items in the Statement of Work (SOW) that are not shown
on the Contract Work Breakdown Structure (CWBS); however, it is not absolutely
necessary to restrict items to those cited in the CWBS.
2. For the preparation of Statement of Work (SOW), clear and precise task descriptions are
essential. The Statement of Work (SOW) writer should realize that his or her efforts will
have to be read and interpreted by persons of varied background (such as lawyers, buyers,
engineers, cost estimators, accountants, and specialists in production, transportation,
security, audit, quality, finance, and contract management). A good Statement of Work
(SOW) states precisely the product or service desired. The clarity of the Statement of Work
(SOW) will affect administration of the contract, since it defines the scope of work to be
performed. Any work that falls outside that scope will involve new procurement with
probable increased costs.
148
img
Project Management ­MGMT627
VU
3. One of the most important things to keep in mind when writing a Statement of Work
(SOW) is the most likely effect the written work will have upon the reader. Therefore, every
effort must be made to avoid ambiguity. All obligations of the government should be
carefully spelled out. If approval actions are to be provided by the government, set a time
limit. If Government-Furnished Equipment (GFE) and/or services, etc., are to be provided,
state the nature, condition, and time of delivery, if feasible.
4. It is essential to remember that any provision that takes control of the work away from the
contractor, even temporarily, may result in relieving the contractor of responsibility.
5. Use active rather than passive terminology in specifying requirements. Say that the
contractor shall conduct a test rather than that a test should be conducted. In other words,
when a firm requirement is intended, use the mandatory term "shall" rather than the
permissive term "should."
6. Always remember to limit abbreviations to those in common usage. Provide a list of all
pertinent abbreviations and acronyms at the beginning of the Statement of Work (SOW).
When using a term for the first time, spell it out and show the abbreviation or acronym in
parentheses following the word or words.
7. When it is important to define a division of responsibilities between the contractor, other
agencies, etc., a separate section of the Statement of Work (SOW) (in an appropriate
location) should be included and delineate such responsibilities.
8. Do not forget to include procedures. When immediate decisions cannot be made, it may be
possible to include a procedure for making them (e.g., "as approved by the contracting
officer," or "the contractor shall submit a report each time a failure occurs.
9. Do not over-specify. Depending upon the nature of the work and the type of contract, the
ideal situation may be to specify results required or end-items to be delivered and let the
contractor propose his best method.
10. It is important to describe requirements in sufficient detail to assure clarity, not only for
legal reasons, but also for practical application. It is easy to overlook many details. It is
equally easy to be repetitious. Beware of doing either. For every piece of deliverable
hardware, for every report, for every immediate action, do not specify that something be
done "as necessary." Rather, specify whether the judgment is to be made by the contractor
or by the government. Be aware that these types of contingent actions may have an impact
on price as well as schedule. Where expensive services, such as technical liaison, are to be
furnished, do not say, "as required." Provide a ceiling on the extent of such services, or
work out a procedure (e.g., a level of effort, pool of man-hours) that will ensure adequate
control.
11. Avoid incorporating extraneous material and requirements. They may add unnecessary cost.
Data requirements are common examples of problems in this area. Screen out unnecessary
data requirements, and specify only what is essential and when. It is recommended that data
requirements be specified separately in a data requirements appendix or equivalent.
12. Do not repeat detailed requirements or specifications that are already spelled out in
applicable documents. Instead, incorporate them by reference. If amplification,
modification, or exceptions are required, make specific reference to the applicable portions
and describe the change.
In addition to the guidelines, some preparation documents also contain checklists for Statement
of Work (SOW) preparation. A checklist is furnished below to provide considerations that
Statement of Work (SOW) writers should keep in mind in preparing statements of work:
1. Is the Statement of Work (SOW), when used in conjunction with the preliminary Contract
Work Breakdown Structure (CWBS), specific enough to permit a contractor to make a
tabulation and summary of manpower and resources needed to accomplish each SOW task
element?
149
img
Project Management ­MGMT627
VU
2. Are specific duties of the contractor stated so he will know what is required, and can the
contracting officer's representative, who signs the acceptance report, tell whether the
contractor has complied?
3. Are all parts of the Statement of Work (SOW) so written that there is no question as to what
the contractor is obligated to do, and when?
4. When it is necessary to reference other documents, is the proper reference document
described? Is it properly cited? Is all of it really pertinent to the task, or should only portions
be referenced? Is it cross-referenced to the applicable Statement of Work (SOW) task
element?
5. Are any specifications or exhibits applicable in whole or in part? If so, are they properly
cited and referenced to the appropriate Statement of Work (SOW) element?
6. Are directions clearly distinguishable from general information?
7. Is there a time-phased data requirement for each deliverable item? If elapsed time is used,
does it specify calendar or work days?
8. Are proper quantities shown?
9. Have headings been checked for format and grammar? Are subheadings comparable? Is the
text compatible with the title? Is a multi decimal or alphanumeric numbering system used in
the Statement of Work (SOW)? Can it be cross-referenced with the Contract Work
Breakdown Structure (CWBS)?
10. Have appropriate portions of procurement regulations been followed?
11. Has extraneous material been eliminated?
12. Can Statement of Work (SOW) task/contract line items and configuration item breakouts at
lower levels be identified and defined in sufficient detail so they can be summarized to
discrete third-level Contract Work Breakdown Structure (CWBS) elements?
13. Have all requirements for data been specified separately in a data requirements appendix or
its equivalent?
14. Have all extraneous data requirements been eliminated?
15. Are security requirements adequately covered if required?
16. Has its availability to contractors been specified?
Lastly, but most importantly, there should be a management review of the Statement of Work
(SOW) preparation interpretation. During development of the Statement of Work, the project
manager should ensure adequacy of content by holding frequent reviews with project and
functional specialists to determine that technical and data requirements specified do conform to
the guidelines herein and adequately support the common system objective. The Contract Work
Breakdown Structure (CWBS)/ Statement of Work (SOW) (CWBS/SOW) matrix should be
used to analyze the Statement of Work (SOW) for completeness. After all comments and inputs
have been incorporated, a final team review should be held to produce a draft Statement of
Work (SOW) for review by functional and project managers. Specific problems should be
resolved and changes made as appropriate. A final draft should then be prepared and reviewed
with the program manager, contracting officer, or with higher management if the procurement is
a major acquisition. The final review should include a briefing on the total Request for Proposal
(RFP) package. If other program offices or other Government agencies will be involved in the
procurement, obtain their concurrence also.
150
Table of Contents:
  1. INTRODUCTION TO PROJECT MANAGEMENT:Broad Contents, Functions of Management
  2. CONCEPTS, DEFINITIONS AND NATURE OF PROJECTS:Why Projects are initiated?, Project Participants
  3. CONCEPTS OF PROJECT MANAGEMENT:THE PROJECT MANAGEMENT SYSTEM, Managerial Skills
  4. PROJECT MANAGEMENT METHODOLOGIES AND ORGANIZATIONAL STRUCTURES:Systems, Programs, and Projects
  5. PROJECT LIFE CYCLES:Conceptual Phase, Implementation Phase, Engineering Project
  6. THE PROJECT MANAGER:Team Building Skills, Conflict Resolution Skills, Organizing
  7. THE PROJECT MANAGER (CONTD.):Project Champions, Project Authority Breakdown
  8. PROJECT CONCEPTION AND PROJECT FEASIBILITY:Feasibility Analysis
  9. PROJECT FEASIBILITY (CONTD.):Scope of Feasibility Analysis, Project Impacts
  10. PROJECT FEASIBILITY (CONTD.):Operations and Production, Sales and Marketing
  11. PROJECT SELECTION:Modeling, The Operating Necessity, The Competitive Necessity
  12. PROJECT SELECTION (CONTD.):Payback Period, Internal Rate of Return (IRR)
  13. PROJECT PROPOSAL:Preparation for Future Proposal, Proposal Effort
  14. PROJECT PROPOSAL (CONTD.):Background on the Opportunity, Costs, Resources Required
  15. PROJECT PLANNING:Planning of Execution, Operations, Installation and Use
  16. PROJECT PLANNING (CONTD.):Outside Clients, Quality Control Planning
  17. PROJECT PLANNING (CONTD.):Elements of a Project Plan, Potential Problems
  18. PROJECT PLANNING (CONTD.):Sorting Out Project, Project Mission, Categories of Planning
  19. PROJECT PLANNING (CONTD.):Identifying Strategic Project Variables, Competitive Resources
  20. PROJECT PLANNING (CONTD.):Responsibilities of Key Players, Line manager will define
  21. PROJECT PLANNING (CONTD.):The Statement of Work (Sow)
  22. WORK BREAKDOWN STRUCTURE:Characteristics of Work Package
  23. WORK BREAKDOWN STRUCTURE:Why Do Plans Fail?
  24. SCHEDULES AND CHARTS:Master Production Scheduling, Program Plan
  25. TOTAL PROJECT PLANNING:Management Control, Project Fast-Tracking
  26. PROJECT SCOPE MANAGEMENT:Why is Scope Important?, Scope Management Plan
  27. PROJECT SCOPE MANAGEMENT:Project Scope Definition, Scope Change Control
  28. NETWORK SCHEDULING TECHNIQUES:Historical Evolution of Networks, Dummy Activities
  29. NETWORK SCHEDULING TECHNIQUES:Slack Time Calculation, Network Re-planning
  30. NETWORK SCHEDULING TECHNIQUES:Total PERT/CPM Planning, PERT/CPM Problem Areas
  31. PRICING AND ESTIMATION:GLOBAL PRICING STRATEGIES, TYPES OF ESTIMATES
  32. PRICING AND ESTIMATION (CONTD.):LABOR DISTRIBUTIONS, OVERHEAD RATES
  33. PRICING AND ESTIMATION (CONTD.):MATERIALS/SUPPORT COSTS, PRICING OUT THE WORK
  34. QUALITY IN PROJECT MANAGEMENT:Value-Based Perspective, Customer-Driven Quality
  35. QUALITY IN PROJECT MANAGEMENT (CONTD.):Total Quality Management
  36. PRINCIPLES OF TOTAL QUALITY:EMPOWERMENT, COST OF QUALITY
  37. CUSTOMER FOCUSED PROJECT MANAGEMENT:Threshold Attributes
  38. QUALITY IMPROVEMENT TOOLS:Data Tables, Identify the problem, Random method
  39. PROJECT EFFECTIVENESS THROUGH ENHANCED PRODUCTIVITY:Messages of Productivity, Productivity Improvement
  40. COST MANAGEMENT AND CONTROL IN PROJECTS:Project benefits, Understanding Control
  41. COST MANAGEMENT AND CONTROL IN PROJECTS:Variance, Depreciation
  42. PROJECT MANAGEMENT THROUGH LEADERSHIP:The Tasks of Leadership, The Job of a Leader
  43. COMMUNICATION IN THE PROJECT MANAGEMENT:Cost of Correspondence, CHANNEL
  44. PROJECT RISK MANAGEMENT:Components of Risk, Categories of Risk, Risk Planning
  45. PROJECT PROCUREMENT, CONTRACT MANAGEMENT, AND ETHICS IN PROJECT MANAGEMENT:Procurement Cycles