CodePartners Methodology: the Statement of Work

SHARE THIS
			Print Email

By Brian Terrell

Often I am asked by a prospect or client “What is your process?” or “What are next steps?” Everyone wants to know what CodePartners will do to create a software automation to help increase revenues, decrease costs, or achieve some other measurable business objective. All significant rewards necessarily include some risks, and our clients deserve to know how we manage those risks. As I discussed in this blog recently, that process begins with a Requirements Analysis followed by a Design Document. Once the client or prospect approves the Design Document, then CodePartners drafts the Statement of Work (“SOW”).

A Statement of Work usually begins with an executive summary on the history, background and objectives of the proposed project. This section in the SOW introduces the project and allows the reader to get quickly up-to-speed about the project and the ensuing Statement of Work.

A detailed Scope of Work follows this introductory portion of the SOW. It includes the action steps CodePartners will take to achieve the project’s objectives, and this section makes up the major portion of the document. Many details from the Design Document are included here, and references to the Requirements Analysis or Design Document may be directly or indirectly made. It’s hard to have too much detail in the Scope of Work, so there is no doubt as to what success looks like. Documentation, testing, training, deployment and support requirements are written out, and a timeline for accomplishing each phase of the project is included.

Some Statements of Work include the business details of the engagement, such as invoicing and payment terms as well as non-disclosure agreements and other legal agreements. Or, we include these details in a Master Services Agreement, which is attached to the SOW. When a Master Services Agreement governs the basic business relationship the Statement of Work becomes much more compact and easy to read.

An SOW concludes with a signature page, where both parties note their acceptance of the project’s Scope of Work. When both parties complete the SOW our CodePartners development team takes over. They’ll take the Requirements Analysis, Design Document, and Statement of Work and begin the actual creation of software code, and the client is one step closer to achieving a business objective through software automation!

Next time, we’ll review the details of the development phase in the software development lifecycle and the different methodologies of managing that effort. Writing code is less like building a house or some other manufacturing process and more like creation or research. Chances are, the objective has never before been accomplished, and that means more risks to manage and more rewards to share. And, there is always more than one way to do things, and I’ll look forward to sharing more about that soon!

Comments are closed.


	Separate multiple addresses with commas(,)
To:	* Copy me
Subject:
From:	*
Message:

Blog

CodePartners Blog

CodePartners Methodology: the Statement of Work

Search

Categories

Archives

Tags