Web2Print Best Practices - Part V: Statement of Work
Jack Perry December 14 2009 09:16:31 AM
I. Introduction: a summary of what the document is about. It provides a brief overview of the goal of the project, and why it is being undertaken. It should include a brief explanation of the parties involved, who is doing what for whom, and the expected outcome of the project.
II. Order of precedent: a brief statement that clarifies the order in which documents should be treated. In most projects there are master agreements, scope documents, a statement of work, etc. It is always helpful to define the order in which the documents govern work to be done. The SOW is usually first in precedent. Eliminate any ambiguity between client documents in this section.
III. Scope of work: this section should detail the project objective, i.e. printer A will build a web2print platform for client B to include an online catalog of printable documents, dynamic publishing capabilities, ecommerce, and general reporting. You get the idea.
IV. Contract Type: in most cases, an SOW is executed as a "firm, fixed" price or is based on "time and materials".
V. Definitions: it is very helpful to build a list of definitions to make sure that all parties are speaking the same language. In past efforts we have been challenged with client understanding of items versus products versus templates. Make sure your definitions are clear and concise and not open to interpretation.
VII. Specific Requirements / constraints / special notes: we use this section to document any issues that affect the execution of an SOW. A client may not be able to deliver certain elements of the project until later in the project, and parties must build a strategy for making sure the delay does not impact project deployment.
VIII. Roles & Responsibilities: this section should include a summary outlining the roles of each party to the process. Who is the primary contractor? Who is the customer? Identify sub-contractors to the process.
IX. Deliverables: Each party will have a list of deliverables. The client may have to deliver lists of administrative and end users, documents for deployment. The primary contractor will have to deliver a host of technical deliverables. Our deliverables section has been organized as follows:
a. Client deliverables
i. Item list
ii. Time line
iii. Dependencies
iv. Testing and customer acceptance duties
b. Contractor deliverables:
i. Technical deliverables - the work associated with deploying technology
ii. Reference materials - addendums to the SOW (schematics, data, illustrations, etc).
iii. Testing scripts for each technical deliverable
iv. Timelines
v. Dependencies
c. Customer Acceptance: the process steps taken by the customer to accept each deliverable of the project.
X. Key contacts: this section outlines key contacts for all parties involved including: addresses, phone numbers, email addresses, etc.
XI. Meeting & communication intervals: a defined scheduled for how and when the parties to the process communicate progress, issues, questions, etc.
XII. Change Control Board: on every project I have worked there have been requests to change elements of the SOW after work has begun. It's bad news, but comes with the territory. The change control board is put in place as part of the SOW to deal with such requests. The change control board is a body comprised of members from all parties who receive, evaluate, and rule on change requests. The board includes the following member positions:
a. Executive sponsor: a representative from the client - the person who makes financial decisions resulting from change requests.
b. Project manager: a representative from the prime contractor - the only party who can receive a change request.
c. Engineering lead: a representative from the party performing the technical work specifically assigned to document how the change request impacts the project
d. Production lead: a representative from the party performing the technical work specifically assigned to detail how a request impacts software development and roll-out.
e. Customer project lead: a representative from the client - the only party who can submit a change request.
The change control board receives, evaluates, and rules on requests to change the SOW. In some cases, the request is deemed to have little impact on the SOW, and can move forward without delay. In some cases, the request can have significant impact on the SOW, and requires additional funds to be approved. The change control board is a tool to manage scope creep; shifting sands that can have dire consequences for all parties involved in a technical SOW.
XIII. Knowledge transfer & training process: define how knowledge will pass from those who built the system to those who will use and manage the system. Define specific training to take place. You should include timelines and requirements for training.
XIV. Compensation: define how much you will be paid to deliver the project. Define when you will be paid and the increments/milestones associated with payment.
XV. Special invoice requirements: include special instructions for invoicing, i.e. client needs the purchase order number to be on all invoices.
Conclusion: depending on the size of a project, building an SOW can take several weeks but is worth the effort. Even if a customer simply wants to deploy two templates to a demo web2print system, you should still take the time to document as much of these details as you can. I've worked on several projects that started as simple template deployments and culminated in tens of thousands of dollars and hundreds of hours of time. Better apply best practices to protect your business, and ensure successful outcomes.
- Comments [0]