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.)


  1. Craig,

    thanks for a thought provoking post. It provided an interesting Sunday morning opinion, of course, I have an opinion on everything, so this is not surprising nor is it necessarily beneficial. I have an ex-girlfriend who claimed to dump me because she said I'd argue with her about whether dirt is brown...

    Scope is one of the great issues with corporate projects and one of the great benefits a start-up company has. I don't think the problem is a product or project perspective, but rather a WIMBY perspective.

    Many people are familiar with NIMBY (Not In My Back Yard), but fewer are familiar with WIMBY (Wanted In My Back Yard).

    In corporations, often times projects get funded because different executives/managers can get things they want included in the scope. The project is sold by inclusion, be it product or project scope.

    In either case, because funding can be expanded to meet additional requirements, which need to be added to get buy-in from key executives/managers, the project or product get too big.

    I didn't recognize this fully until I realized one of the advantage a start-up has is limited resources. I can't get more funding without selling what I already have. Because I had to pay for it out of my own pocket/consulting arrangements, it had to be simple and clearly present the value we are offering.

    Less is more.

    Now, if you'll excuse me, I have to go give a nice girl reasons to suspect me...


  2. Anonymous7:04 pm

    It is the Project Charter in PMBOK's terminology, that defines business requirements, goals and objectives. From there, Preliminary Project Scope Statement is derived.

    So it is PM's responsibility to assure, that the Scope of Work supports business requirements, goals and objectives, whatever they are.

    It is possible to build Scope of Work in a way, to be certain, that it will support goals.

    Quality doesn't always have higher priority then cost, time or scope. It depends on the business requirements what is acceptable quality.

    If at the end of the day the solution is not delivered, business objectives are not met and you as PM failed to do your job. And if you know that you did everything in the Scope of Work, then you know, that the Scope of Work was not complete.

    It is not a matter of focus but a matter of doing things right. It is up to the project sponsor to define Project Charter and PM's role is to achiece the goals defined there.

    If you start thinking about Product or Project scope then you may be doing sponsor's job. Step back and ask the sponsor to clarify what's not clear. It's his project, he knows why is he doing it and what he wants to achieve.

  3. I'm new to this site - sounds like a great discussion! Having spent nearly 30 years in the software and systems world, as business analyst, development managers, IT director, and project manager, I have seen that the client sees the Scope as 'product scope', i.e 'what will you deliver to me', whereas the delivery team sees scope as 'what tasks and deliverables am I estimating it will require to delivery what you want' (aka 'project scope'). When the client changes Product Scope, the delivery team adjusts Project Scope. Sometimes the client makes no change to Product Scope, but clarity in the product definition will modify the delivery team's understanding of the tasks it will take, or the technology components they were planning to use to deliver it, and will result in Project Scope. Lastly, a change in the availability or technical details of the componentry can cause a Project Scope change, even though the Product Scope didn't change, nor did anyone's understanding of the detailed requirements. As Project Manager, it is critical that you have a clear understanding of the expected Product Scope and that you, or (if defined) your Product Manager, clearly define the intended Project Scope (tasks, deliverables, etc.) so that if EITHER changes, you can deal with the fallout.

  4. A agree with your thoughts Thene. Also I’ve done some analysis and comparison with other industries and my current thinking is the main reason s/w developers have more scope adjustments is:
    a) The tools used in technology projects (e.g. s/w) are infinitely harder to predict than other types of project…. Because technology is more complex and variable than for example a building. Technology lifespans are measured in months not decades. Concrete has been around for 1000's of years. Your s/w tools for how long?
    b) A s/w dev team is way more likely to accommodate a change request to adapt to the business environment which changes way way faster than physical environment needs (like accommodation). In construction the planners charge a very high price for changes and actively discourage it. In s/w the team is more likely to be flexible and adapt and this leads to (often necessary) costs.
    By coping with the above challenges s/w developers have delivered revolutionary business benefits over the last 20 years and must be extremely proud of their projects and contribution. If s/w developers took the same approach as the car industry (which probably does so for safety reasons) the world would be much poorer for it. Well done s/w people!

  5. Thene

    Thanks for the comment.

    It's an interesting problem, the difference and dependence of product and project scope.

    Given it's prominence I wonder what systematic approaches we can employ to best integrate the two?

  6. Alan Jones10:33 am

    It is necessary to define both the scope of the product and the work so that it is clear what is to be delivered so that expectations can be set

    E.g We are going to delivery a replacement system to meet this business need zzzz. We will limit data conversion to 1 year of data. The project will not train all the user community; traiing willbe limited to x people. Further user traing will be arranged directly by the business

  7. Alan

    Since writing this post my ideas on the topic have firmed up quite substantially. I now believe that requirements are the primary driver of project scope but a number of factors need to be present for things to work well. Two things that come to mind right now are;

    Requirements need to be produced in a way that makes them measurable and discreet from one another.

    People need to know the track record for requirements change in their company and build forecast changes into plans.

  8. "Requirements need to be produced in a way that makes them measurable and discreet from one another." Yes!

    But how do you know you will get all the Requirements? Use a Process Scope to define what is in, and what is out.

  9. Dave I am before.Bing go think we were separated at birth

  10. So now I am posting a series of blogs on why Requirements Scope should Equal Project Scope. (It's not an absolute thing, but is a worth goal.)

    See the first in the series here.

  11. can you define "iron triangle" a little more please

  12. Reema, the concept is about the trade offs made when changing constraints in your project plan. For example, when you cut the budget something else gets cut as well (which could be features/scope, or quality.)

    While not perfect it is useful for communicating the idea of balanced forces to people who don't understand the consequences of cutting corners.

    Have a look at this blog post at "Building Better Software" for more.

  13. thanx for the info Craig