Five techniques to successfully manage scope

During last week’s study group session (see earlier article), we were running a Question and Answer session to give the students an opportunity to get some practice in interviewing with the aim of producing a coherent, consistent vision statement.

During this exercise, I was asked to step in to show how I would manage requirements which appeared to be inconsistent with the scope. I did this but, if I’m honest, not to my satisfaction.

For the benefit of the group, I thought it would be useful to reflect on this exercise and how I might have tackled it given more time to think and also to start a discussion on other approaches to this problem.


It’s worth saying upfront that this problem which we could call scope management exists in almost every project where there is more than one stakeholder so it is critical to have some tools to tackle it.

To be quite clear, this article is NOT discussing change control which is another but related subject. Change control applies when scope has initially been agreed and baselined. Scope management (as I use the term) applies early in the project when scope and requirements are still quite fluid.

The problem can arise for a number of reasons and here are some:

– The project vision is not fully understood by all the stakeholders

– Some stakeholders will have ‘pet’ requirements which they will introduce regardless of whether it forms part of the vision
These requirements may well make the stakeholder’s life easier but, typically, either the business case is not compelling or they have no or insufficient investment budget which is why they have not been considered before

– It is easy for stakeholders to get sidetracked and, completely unintentionally, introduce requirements which don’t fit within the vision

Why manage scope?

Successful scope management is critical to the success of any project. If it is not closely controlled throughout the course of a project, there are a number of issues which may arise:

– The project overruns it’s timescale

– The project goes beyond budget

In either of these cases, there is a risk that the project gets pulled either because the budget is fixed or it has a delivery deadline that is not negotiable. Even if there is some flexibility in budget or timescales, there is a much greater problem which is credibility.

The project loses credibility if it is unable to control budget or timescale and when it has lost credibility, those who control the finances are much more likely to pull the project to prevent further losses.

Techniques for managing scope

1) In a project where the culture is open and consensual, it can be effective to explain the problem very clearly to the stakeholder proposing the requirement which contradicts the vision. In this case, the business analyst should explain (without being patronising) how the requirement does not fit within the vision. He/she should also explain that it is always the case in any project that it will not be possible to deliver all the requirements as this is inevitably the case with a finite budget.

2) The business analyst should invite the stakeholder to drop the requirement. It is advisable to sweeten the pill by offering to include it in a list of requirements that are ‘nice to haves’ and can be considered in a future release or for a different project.

The stakeholder will not necessarily take up this ‘opportunity’.

3) If the project is very much management led and scope control is invoked very clearly by the project sponsor, it may be beneficial to explain this same view to the project sponsor instead of the stakeholder. In this case, the decision can be made more easily but it is important that transparency is maintained the decision and the reasons are explained to the stakeholder group. Some would be comfortable with a less transparent approach but I feel this works well to build up trust and makes for a more productive working environment.

4) Another approach is to play off one requirement against another in front of the stakeholders to allow them to decide the priorities. This can be approached very simply by asking them to imagine the project was completed but requirement X was not supported because there was insufficient budget to deliver requirement X and requirement Y.

In this case, requirement X should sit very clearly within the vision and requirement Y should be the one you want the stakeholders to drop.

Again, this helps the stakeholders see for themselves the relative priority of requirements and to question which ones are really critical.

5) If none of these approaches work because stakeholders are being resistant then more formal requirements prioritisation techniques should be pursued (see article). There is a strong argument that these should be undertaken anyway to support discussions later in the project regarding what appears in a release or even when it is necessary to reduce the scope due to unforeseen circumstances.

In summary, project success is only possible when project scope is managed very carefully. The risks to budget must be managed to avoid the project losing credibility being cancelled.

There are a number of approaches available which can be employed but must be selected depending on project culture and stakeholder attitudes.

What approaches have you applied successfully? Please add your comments below.

About Alex Papworth

4 Responses to “Five techniques to successfully manage scope”

Read below or add a comment...

  1. alexpapworth says:

    Very true Craig

    Sometimes it can feel like it's only you who cares about the scope. If that's the case, you're not engaging the business and ensuring they both make the decisions and own the results.

    The person who holds the purse strings and the stakeholder who will have to live with the system SHOULD be very motivated to ensure the right decisions are made.


  2. craig says:


    Good points both of you.

    Another part of he mix is to bring in the sponsor and the "senior business owner" who lives with the soluton once the project is over.

    They are your project's primary customers. Make them 'own' the scope by getting involved in boundary disputes.

  3. It isn't like the "project vision" is divine revelation against which requirements can be judged. It's often emergent, as people introduce and discuss various requirements, feeling for the sweet spot.

    If politics, i.e. personal agendas, are a significant part of the mix, the vision and scope are unlikely to ever emerge unless you have effective governance. And effective governance is hard to establish in highly political environments.

    Too many organizations are functionally organized and have reward structures which drive local optimization. The VP of Sales gets a bonus for driving revenue up and the VP of Operations gets a bonus for driving costs down, and this also prevents vision and scope from converging.

    Add to this the fact that early estimates of cost and schedule are inherently inaccurate (something like 2x even if vision/scope are stable) and one requirement, more or less, is hardly the problem.

    Given all this, the only way I can see to consistently deliver value within budget and schedule constraints is to make scope explicitly variable. Scope is the hardest constraint to understand and stabilize anyway, plus the high level of utilization of both people and money tends to make schedule and budget inherently less flexible.

    I agree that prioritizing requirements is critical; indeed, it's the replacement for a defined scope. Then you take a page from the book of Lean and shrink the batch size, i.e. rather than running all the requirements through the lifecycle en masse, run them through in minimum implementable sets. That virtually eliminates the risk of the project hitting a budget or schedule constraint and delivering no value at all. It will have created something of high priority, and the high priority requirements seldom seem to be the ones people argue about..

    Better to run out of time or money with half the requirements completely implemented than all the requirements half implemented. Under the pareto principle, half the requirements "done" probably means well more than half of the value realized, even in face of changing requirements and big estimation uncertainties at the time the schedule and budget were set.

    See for a toy example.

    • alexpapworth says:

      Great comment Robert and my apologies for the very slow reply. I did reply last week whist in transit but my battery died on me!

      I agree that effective project governance is a must – businesses are not democracies and although it is important that voices are heard, there must be a decision making process that everyone buys into.

      I think you are really referring to agile approaches in your latter comments. I think, in general, that Agile has a set of principles at it's core that make a lot of sense. However, for the working business analyst, we are not often not in a position to influence change in an organisation to the degree that makes this approach possible. We should and MUST continue to educate the organisation we work for but, the reality is that we often have to work within the constraints of the project approach dictated by our business/ in house methodology.
      This means that we have to do the best we can to manage these scope conflicts.

      We must to continue to educate the business/management on the risks (or facts) you have outlined to promote an iterative approach but often, we will still have to do what we can within the constraints of our situation which is what this article explores.

      However, it is important to bear in mind that having several iterations does not come without a cost. Business are besieged with continual change and accompanying implementation costs both monetary and psychological (e.g. training, lack of user buy-in).
      Of course, there are ways to mitigate this but it is yet another factor to consider i this complex debate.

Leave A Comment...