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.

Background

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.