When drafting the SOW, how granular should the technical piece be?

​Preparing a Statement of Work (SOW) is a balancing act between defining the project, estimating the costs, allowing some flexibility, taking account of risk, due diligence checks and speed in actually issuing the quote to the customer.

There will probably be a sales person demanding the fast turnaround to keep the customer happy and the delivery manager wanting to make sure that all risks and due diligence checks have been completed. The perfect statement of work (SOW) is somewhere in between.

Assuming that you have all of the elements and a template then you can spend more time on the scope and defining how granular the technical piece should be.

Project scope is the part of project planning that involves determining and documenting a list of specific project goals, deliverables, features, functions, tasks, deadlines, and ultimately costs.

As a project manager, you'll need to define project scope no matter what methodology you choose to use. The work and resources that go into the creation of the product or service are essentially the things that frame the scope of the project. The scope of the project outlines the objectives of the project.
In other words, it is what needs to be achieved and the work that must be done to deliver a project.

Why is Scope important? 

It is important to pin down the scope early in a project’s life cycle as it can greatly impact the schedule or cost (or both) of the project down the track.

Anyone who has ever done a project will have tales of how scope changes caused grief.Scope is bound to change, and this is to be expected. As the detail becomes clearer, more complications creep in. 

These are not foreseeable at the start and hopefully we build in a contingency for what we cannot see. The scope changes that usually cause problems are those where the perception of what was in and out of scope was different between various parties. 

The Project Manager assumed there would only be four or five reports, and the business assumed ten to twenty. Nobody felt it was worth talking about because they assumed the other person thought the same way they did.

In terms of technical detail it can be useful to define the  business use cases or business functions that will be delivered as it is often possible to provide a solution using different technical componets.

For example a business use case may be:

“The solution will allow ad hoc queries of data held within the system”

However the solution could be built with many different types of databases and front end query tools, each will have advantages and disadvantages and costs. It is often easier to specify the use case in business terms rather than technical terms and allow the developers to prototype during the build phase.

It is important to look at the full project scope.

To scope a project you need to look at several key areas: 

•    Project Objectives
•    Product Requirements
•    Process Requirements
•    Basic reference information
•    Tasks
•    Resources
•    Stakeholders
•    Deliverables or Work Packages
•    Involve correct stake holders
•    Identify Limitations
•    Change Management
•    Other cost inputs
•    Costs
•    Margin
•    Sell

Once you've established these things, you'll then need to clarify the limitations orparameters of the project and clearly identify any aspects that are not to be included. In specifying what will and will not be included, the project scope must make clear to the stakeholders, senior management and team members involved, what product or service will be delivered.

Alongside of this, the project scope should have a tangible and measurable objective for the organisation that is undertaking the project. The purpose may be to create a better product for a company to sell, upgrade a company's internal software so that they can deliver better service to their customers or to create a new service model for an organisation. 

These things are integral to defining the project scope, because they will play a part in how project methodologies are applied to the project to bring it to completion.

In addition it is important to understand the business drivers behind a project. These are used to fund and justify the project. They are usually one of the following

•    Cost saving through reduction of process, overhead, legacy solution
•    Revenue increase through the introduction of new products or services
•    Compliance introduced through new legislation or standards.

The business drivers will also be used as part of the business benefits realisation phase where the costs of the projects are measured by the business benefits achived by executing the projects. These can be either tangible or intangible business benefits.

Top Tip

Include the business benefits realisation activity as part of the project early on so that you can track and measure the benefits as they are realised. It is much harder to measure the benefits after the fact.

For more resources check out our store and for more articles on projects, check out the blog.

Thanks for reading

Andrew Everett