Scope creep is the bane of any project manager’s life, and to an extent unavoidable says Andrew Vermes, technology practice leader at consulting firm Kepner Tregoe.
Scope creep can be avoided to begin with, but if you can’t we will move on to ways it can be managed. This is a set of hands-on techniques, not a substitute for the large body of theory and knowledge you can find in the Project Management Body of knowledge (PMBoK), Capability Maturity Model for Projects, PRINCE2 or elsewhere.
There are good reasons for businesses extending or changing the requirements in an IT project: the world moves on; new data security threats are discovered, external demands from customers change, technology advances to the point where the improbable or hopelessly expensive comes within practical reach. The bad reasons for changing requirement can be summed up as ‘we didn’t think it through properly in the first place’.
You can avoid or manage a large proportion of scope creep using the following ideas on each project or sub-project:
- Assess the process you’re trying to work on;
- Involve the stakeholders deeply in planning;
- 5 whys – Get behind the stated requirement;
- Continuously manage risk and opportunity;
- Keep the assumptions visible.
Assess the process
To get a tight hold of the eventual scope you must get stakeholders participating in process review work. In this way, they will point out flaws in the current process, and points where the ‘real’ process departs substantially from the departmental operating manual. Finding surprises later will cause unwelcome changes.
If you’re modifying an existing function, get some users to walk through what they do. Post It notes are a splendid way of capturing the steps. Make sure they show you, rather than describe what they think is going on. For a new process they can walk you through their imagined process.
Once you’ve captured it, get them to try it when working a real task. If necessary draw a few rough screens on paper and ask the user group to see how well they work. Document the gaps, and keep playing with it until you feel a degree of confidence that the process does what it’s supposed to.
White space is a buzz phrase often used recently. First brought to prominence by Alan Brache and Geary Rummler in the nineties, the term refers to the observation that much of the important work in any organisation gets done outside the ‘official’ process steps, and without regard to the organisational hierarchy. If it were not so, many of our companies might collapse.
One approach is to try to force everything into the process boxes. From a project manager’s point of view, it also shows that we have to take care of the interfaces between process steps. What actually happens along that arrow from one step to the next? What are people doing to add value that is not shown anywhere on the process flow?
Involve stakeholders deeply in project planning
Involve the user/stakeholder community much more deeply in the development of project scope. The typical approach is that business and systems analysts ask questions, draft requirements and then review with the stakeholders. The risks are well known; users provide an ill-thought out wish list, and then keep adding to it and changing their minds throughout the development cycle.
A typical project scope will define five elements: what, why, how, when, and how much. The definition of what is the project there to do – known as the project statement is crucial, and needs to describe the end product concisely, in a way which makes clear to the user community what they’re getting, and the producers (us) what we have to make.
Creating the right words – or pictures at this stage is extremely important. It’s also useful to have the stakeholder group participate in producing the work breakdown structure. While involving them in fine detail can be counterproductive, having them there to help frame the major deliverables gives them an appreciation of what is to be built, and how, and serves as a useful reality check.
Project Objectives (Why are we doing this?) are frequently a source of scope creep in themselves, particularly if we sign up to a set of results which the project, by itself cannot deliver.
One simple technique you can use to reality check and get behind requirements is the five whys. The five whys originated in Toyota in Japan, and were intended to reveal the cause of a problem. The idea is that by asking ‘why’ five times in succession you increase the level of knowledge you need to find a solution by understanding the root of the problem the business is trying to solve.
What’s the issue?
We can’t get new server capacity installed in time.
Why?
There are restrictions on the number of machines per rack
Why?
Heat generated is high
Why?
Using machine of older designs
Why?
Because the previous generation provides high stability
This short example reveals that our challenge is to maintain the historic stability, but we need to find a way of increasing the capacity quickly. It also helps to move the focus away from finding more space for server farms towards (perhaps) trying to identify machines that can deliver the same uptime with lower heat generated.
It’s not invariably the case that five whys are enough. KT advocates what it calls questioning to the void- in others words repeating the question until you’re sure you’ve exhausted the available information or ideas.
Five whys is also useful for getting behind the stated requirement:
We need to connect our CRM database to the regulatory reporting system
Why?
We need to have visibility of reportable complaints when dealing with new customer requests
Why?
We want to ensure that technical advice is appropriate
Of course, you’ll vary the words to avoid sounding like a parrot: ‘What led you to that need?’ ‘In what way does that help you?’
Manage happenings
Risk management is advocated by every authority on project management, including the project management body of knowledge, but in real life risk logs too often focus on tangible, obvious risks such as ‘servers fail’ or ‘building catches fire’ and fail to explore the specific project challenges deeply enough. When managing scope, the key is to focus on opportunity as well as risk, and treat all potential departures from scope in the same way.
What we should aim to achieve is a continuous appreciation of the way changes around us may impact or enhance our project. For managing scope, the category of risk/opportunity that should be of greatest concern is the business environment, and the events inside and outside the organisation that could cause us to change our minds about requirements
Run weekly issue/risk/opportunity sessions with stakeholders. Impractical? No – especially not when you use a simple framework and keep the meeting or call to 30 minutes. The key questions are always:
What issues do you see that have any connection with this project?
In what way(s)?
What is the current (actual) impact of these issues, if any?
What is the potential (future) impact?
List the specific risks, likely causes, and potential actions
List the specific opportunities, likely causes, potential actions
Choose which risks and opportunities to –
– Ignore for now
– Keep close watch on
– Take action for
Keep the assumptions visible
Any project is built on many assumptions. These may be about internal and external markets, rates of pay, available technology, regulatory restrictions, margins for products and services and even the nature of the business. Project scope is likely to need modification if there’s any material shift in any assumptions. An early warning system can help us to manage the disruption better.
In extremis a major change to assumptions will mean the project has to close. The quicker we realise this the better, in order to reduce waste in resources. In the earlier example of the technical support team a key assumption – that qualified staff are available and cheap – which was true at the time is less so now. And circumstances can change frighteningly fast.
The list of ideas is not exhaustive, but these are six things that you and your project team can do quickly, and with little additional effort.
Managing scope is above all about paying attention to small things. The clues that things are changing are all around us, if we choose to listen to and see them.