Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: PMO, Requirements Management, Scope Management
Creating a Statement of Work when requirements are unknown
When launching a project (with a client) where the requirements are unknown and the requirement gathering/definition effort will occur as part of the billable project, is a Statement of Work the right document to use?

What should you keep in mind if creating a Statement of Work, and you do not know what is meant to be delivered?
Sort By:
Page: 1 2 next>
You need to have at least some high level concept of what is being delivered. If you don't know whether it is a phone app or a highway interchange, you have no basis to elaborate further.

Prior to having a full set of requirements, you should have a problem statement and some high level concept of the solution approach (app or bridge). That includes some very high level requirements but not the complete set of requirements. That high level information is required to develop the contract.

A SOW is still developed at that stage, but it is a high level narrative rather than a detailed level SOW, although often they are called different things than a SOW. It should cover about 3 levels of WBS so you have some idea of what the overall project looks like (1 = project, 2 = major elements, 3 = significant work for major elements). That level of detail tells everyone what problem they have to go solve, and serves as the basis to write a detailed level SOW later.
Christopher -

If the project lends itself to an agile/adaptive lifecycle, the SoW would focus on outcomes and high level requirements rather than provided the full details.

If this is not the case, then it might make sense to do a small project to sufficiently explore the scope and solution approach. The key output of this project would be be the SoW for the 2nd (construction/transition) project.

If the requirements elicitation activity is part of the statement of work then you have no problem with that. In fact, is the only activity that has sense to be included inside the statement of work. But you will need to set up requirements to perform the elicitation activity.
Dear Christopher
Interesting your question
Thanks for sharing

What is your take on this Kiron proposal: "If this is not the case, then it might make sense for a small project to sufficiently explore the scope and solution approach. The key output of this project would be the SoW for the 2nd (construction / transition) project "?

It is a possibility to be faced
We start with a statement of capability deficiency, which becomes our high-level mandatory requirements, which then become a preliminary statement of requirements, which then becomes a statement of requirements, which then becomes our statement of work. For us and our governance process, one follows the other, and we cannot create a statement of work without first having a statement of requirements, and so on.
I would think of this in terms of a statement of work that is about firming requirements, then with a subsequent SOW revision once requirements are complete. It's dangerous to commit to an unknown.
My terminology and approach (and I think it is in essence what others are proposing) would be to use an explicit "Discovery Phase". Only scope and fund that initially (with SoW). It can be run using whichever approach suits the work (Agile----Waterfall). The organisation may like an order of magnitude estimate for the entire project to allow for budget forward planning, but a separate or updated budget, scope, schedule etc would need to be approved before commencing the execution cycles or phase.

Note that the Discovery Phase doesn't need to develop the full requirements or scope (if you're expecting to use an Agile approach during execution), just enough to provide the certainty to get going.
We've also used the approach of splitting the work into two statements of work. The first one is a scope definition exercise and the second is to implement the defined scope.
SOW is a contract between requesting and performing organizations so it is definitely a right document to use. In your case, you should break your project in to phases with the first phase is focusing on Requirement Elicitation. The product of this phase is BRD or PRD document so that your initial SOW document will mostly contain requirements for qualifying BRD or PRD. The next phase will be decided on the result of the first phase and you may need to update SOW document.
Great comments here. I have been in similar positions. We would have a discovery period SOW, then a project SOW. If possible, Kiron's suggestion on outcomes is also great.
Page: 1 2 next>  

Please login or join to reply

Content ID:


- Chinese Proverb