10 August 2008

What is Project Scope? What should it be?


I have been having a bit of a discussion over at the IIBA blog with Kevin (VP BOK) and Julian (Chief architect.) It’s migrated over to definitions of scope. I want to comment on it here because I think it’s an area that a lot of us have trouble with – both understanding and managing it.

Project Scope
Traditionally project managers focus on scope as the body of work that will be done to deliver a working product (or solution) to the customer. We use phrases like ‘the scope of work’ to define what we have agreed to do. And we use the scope of work to define our expected efforts and thus our pricing or budget forecasting for projects we are about to undertake.

The Scope of Work is part of the project management ‘iron triangle’ which is a paradigm that suggests that there are always trade offs between the work you need to do, the money you need to spend and the time needed to complete a project.

Product scope
Julian points out that the IIBA/BABOK’s approach to scope is framed around the delivery of a product/solution. This approach comes out of the realm of product management and is about defining what a product can do in terms of features and functionality. Many modern software project managers also talk about scope in the context of the product rather than the work to be done. In this context we talk about the “scope of the product” or the “scope of the solution,” not the scope of work.

Project issues of cutting back scope are usually referring to cutting back features to be delivered – which is of course related to the effort to be expended (ie scope of work.)


What's the problem?
So, Traditionally project managers are talking about the scope of work and business analysts (and product managers) talk about the scope of a product.

The opportunity for confusion between project team members over what particular scope is being talked about presents a problem. Now you know about it the problem has diminished.

The question I want you to ask yourself is, as a project manager or business analyst, which definition of scope is more important?

The problem I see with the “Scope of Work” approach comes in three dot points;
  1. We still aren’t mature enough as an industry to be certain that a particular amount of effort will result in a reasonable product (or solution to the client’s problem.)
  2. While understanding underlying costs is important, it is not as important as quality. Or better yet; it’s not as important as value. Remember the phrase “you’ll remember bad quality long after you forget the price?)
  3. And lastly, at the end of the day, if you do exactly what you said you were going to, and the client has paid you your pound of flesh, will either you or your client be satisfied if the solution has not been delivered? I didn’t think so.
I figure this is fundamentally related to whether you should take an outcome focused or process focussed approach to your work.  There are arguments for both of these, and maybe they can live together, but I feel that you have to pick one or the other as the main choice.  And my choice these days is the outcome focus.

People, what do you think?  When you talk about scope today which one are you talking about?  Is it working for you?

I also recommend you go read Julian Sammy's post on this topic here.

(Picture by pbo31, CC at Fickr.)