Avoid “Scope Creep”!
A common problem that affects projects is that of scope creep. It’s very easy for a situation to occur where features and changes are suggested that are beyond the original view of the scope. Each change, individually, might seem small and insignificant, yet when they are added up they might result in a significant increase in cost and time. This is likely to have a knock-on impact on the benefits that are realised.
There are many causes of scope creep, and sometimes changes to scope are necessary for very good reasons. However uncontrolled or frivolous changes can be problematic. One particularly problematic issue is when different stakeholders have different perspectives on what the scope is. This can lead to different expectations over:
- Why the change is necessary in the first place
- What is being delivered
- How the delivery will take place
If there isn’t a shared understanding over the why, what and how, then it is very likely that problems will occur. Yet, in the understandable rush to ‘kick off’ a project, it is very tempting to curtail or cut down on the initial analysis work which creates this shared understanding.
The Dangers Of “Superficial Agreement”
When insufficient initial analysis work takes place, stakeholders might fall into a trap of appearing to agree. At a surface level they might actually agree, but the agreement is based on a tacit misunderstanding of each others’ views.
This is particularly the case when the driving factors behind a project sound really simple. “Our aim is to have a fully digital customer journey” or “we need to comply with this new law” sound like relatively simple statements. Yet unpack them and we find a whole range of ambiguities.
Let’s take the first statement “Our aim is to have a fully digital customer journey” and imagine we ask for different stakeholders’ interpretations. It’s likely they’d have very different views, some possible examples are shown below.
This is about allowing online ordering. Nothing more. A basic online ordering facility is all we need.
Head of Marketing
We’re looking to increase revenue. The project is about tracking customer behaviour so we can find out their preferences, tailor the experience to them, and this will lead to them buying more.
Head of Operations
We’re aiming to make operational savings by reducing the number of queries that come into our contact centre via phone.
Head of Warehouse
We want to improve our dispatch processes. OK, these aren’t customer processes, but they affect customers, so it’s all connected.
Of course, well-tested and traditional project initiation techniques will help alleviate some of these differing views… but how often is a Project Initiation Document or Project Charter read by the average project team member? Often the answer is ‘not as often as we’d like…’.
What is needed to help plug this gap is swift, practical and engaging pre-project work which involves key people and cultivates a shared understanding. This is where pre-project problem analysis fits.
What is Pre-Project Problem Analysis?
Pre-project problem analysis involves taking a thin-slice through the why, what and how of a potential project. It is analysis that is typically done collaboratively with key stakeholders, and is done quickly. A key aim is to create a concise, often ‘one page’ summary of the situation, so there is a high-level shared understanding of what needs to be done. It can be used to prioritise or triage potential initiatives, so that non-essential or lower priority projects do not jump the queue.
It typically involves utilising techniques such as:
- Stakeholder analysis
- Root cause analysis (5 whys, fishbone diagram, multiple cause diagrams etc)
- Problem definition (Problem statement)
- Outcome definition (critical success factors (CSFs), key performance indicators (KPIs), balanced scorecard etc.)
- Conceptual scoping (business use case diagrams etc.)
- Identifying potential solution options
The overriding idea is to establish just enough information to assure there is a shared understanding, and to enable the sponsor to make an informed decision.
This analysis typically culminates in a short, concise document. In some situations it can even be distilled into a one-page ‘project concept summary’ document. These techniques, along with the project concept summary document, are discussed further in our pre-project problem analysis course.
What Is The “Project Concept Summary” For?
The concise Project Concept Summary document provides a one-page view of the why, what and how. It ensures there is shared understanding before the project is initiated. However, it is also a useful ‘guiding beacon’ throughout the initiative, and is particularly useful at helping to avoid scope creep.
For example, if a problem statement had been defined, some KPIs & CSFs and a business use case diagram had been agreed upon, then there is an initial clear view of high level scope and desired outcomes. This can be elaborated during project initiation, to set specific lines of scope, but the project concept summary still continues to play a pivotal role. Downstream, when requirements are being prioritised, it is possible to ask “how does this requirement contribute to the outcomes articulated by the CSFs and KPIs, within the scope of the business use case diagram?”.
It is the kind of document that can be referred to time and time again, and in many ways can act as a high-level artefact in the requirements architecture. Every requirement ought to trace back to it, and if a requirement doesn’t then that’s an indication of potential scope creep.
Agility At Heart
Pre-project problem analysis has agility at its heart. It is about ensuring that key stakeholders are ‘on the same page’ and have agreed on key decisions over broadly what is being delivered. This allows flexibility at a delivery level over the detail, along with decisions over relative priority and sequencing.
Artefacts such as a business use case diagram can also help with the creation of an initial backlog, and having a clearly defined ‘top level scope’ helps avoid the situation where the backlog gets filled with unrelated user stories, or where the backlog itself becomes incoherent as there are vastly different views amongst the stakeholder community.
Conclusion: A Key Project Investment That Speeds You Up!
Pre-project problem analysis involves fostering a shared understanding of the high-level “why, what and how” of a potential initiative. Investing a small amount of time to achieve this clarity will pay dividends in the long run. It is likely to reduce misunderstandings and scope conflicts. With less conflict and less rework, it may actually save time and money in the long run. And who wouldn’t want to do that?