Feed on
Posts
Comments

A Statement of Work (SOW or STOW) is a narrative description of the work to be performed, as part of a project. Very useful for work performed under Contract by a Vendor. When multiple vendors are engaged to deliver a project, multiple SOW will be produced. If the project involves only internal resources, an SOW or something very similar (as scope document) is still highly recommended.

Who authors the SOW? Well, the party doing the work is the most reasonable candidate, therefore when Vendors are engaged, they will very likely author the document. And this is where risk lies, when the Vendor is focused on the work and the cost of the work, and not on additional factors critical to the customer, like requirements.

Consider a sample SOW that only shows the activities to be performed by the vendor and their related cost. The big risk in this document – the SOW does not show what requirements are being met. It may not even explain exactly what the customer will have after the work is completed. Think of an SOW for a customized application that elegantly describes the finished product, but lacks a clear thread back to what the customer asked for. Without the thread, the Customer is doing mental gymnastics deciding if what the Vendor is describing “fits the bill”.

And what “fits the bill”  is described in the requirements. For large projects, it is highly recommended to author separate documents for Business, Functional, Technical Requirements as needed (things will get approved faster). For smaller projects, it is acceptable to document all requirements within the SOW.  To establish a thread between the requirements and the work being performed by the Vendor, create a table that lists  Requirements as row labels, and Work Activities as Column Headings. Code your requirements (BR001, BR002, TR001, TR002) and your work activities (V1WA001, V2WA003), to eliminate confusion relying strictly on word descriptions of each. For each requirement, then ask the Vendor – which work activity is delivering this requirement? Do not be surprised if you find the work activities do not align 100% to the requirements, i.e. there are missing activities or activities that don’t align to a requirement.

The value of this discipline it that your end up with no or fewer surprises, because of the diligence you have applied in aligning the work activities with the project requirements. And it’s not nice to surprise your Customer (except on their birthday).

Leave a Reply