In my last article, we reviewed a proposed Product Life Cycle process, which starts with a “Define” phase. In the “Define” phase, we are defining the project as well as the product.
We previously discussed the ‘technical leg’ of this process with the market analysis, identifying customer needs, product requirements, verification and validation, etc.
Meanwhile, the Statement of Work (SOW) is often a companion document (usually provided to a vendor from a customer), which states project (non-technical) requirements. To clarify the content/scope of the SOW, it’s worth revisiting our definition of a requirement and applying it to a project:
- “What will the project provide (outputs/deliverables) in order to ensure the customer(s) the product is fully developed? What work will be performed?
- “What does the project need (inputs/deliverables) from the customer(s), in order to ensure optimum project performance?”
The use of the term “will” is usually reserved for work that will be done (as per the SOW), and product requirements are best stated as “shall”. Also, the SOW defines what “done” means in an unambiguous way such that the customer (internal and external customer) could confidently declare it completed.
Note that compliance with the SOW (and/or project plan) represents good project quality in the eyes of the customer.
In an SOW, we might tend to focus on what we will provide to the customer (for example, product prototypes, a validation test report, etc.). However, some inputs or work to be performed might be needed from the customer as well, and would be defined in the SOW accordingly. An example of this is drawings that determine the envelope within which the product must fit. (While the drawing dimensions are a technical requirement, the drawing itself is a SOW item that will be provided by the customer.)
Often a customer-provided SOW may contain a mix of project (non-technical) requirements, customer needs, product (technical) requirements, design constraints, etc. Conversely, customer-provided requirements may contain SOW items. An “internal” SOW and PRD (with traceability to the customer-provided document) can be written to ensure a healthy distinction and clarify the hand-off to project management and engineering.
The SOW is the project managers’ opportunity to clarify and establish a mutual understanding of the project work scope and deliverables, and to integrate them into the project plan, work breakdown structure and project schedule. Following these simple guidelines can help reduce misunderstandings and achieve a successful product and a high quality project.
Leave a Reply