Scope Creep and how to love it!
Pete Wilson discusses why ‘Scope Creep’ has a bad rep, and why it shouldn’t.
Amongst Project Managers and business stakeholders alike, so-called ‘Scope-Creep’ has a bad reputation. But why? Probably because in many cases changes to project scope are unforeseen and unplanned. Which is odd, because given that the pace business change is speeding up, why would we believe that after setting off on a journey that may well take 3 or 6 months, someone somewhere isn’t going to change the final destination?
“Begin with the end in mind”, [Habit #2] Stephen Covey – The 7 Habits of Highly Effective People.
I firmly believe that scope change should be embraced and recognised for what it is – understandable and indeed, it should be planned for. A number of things can be done during initiation to cater for changes in scope. Recognising that a degree of change agility is a necessity would be a great start. Over a 25-year period I’ve rarely been involved in a project that doesn’t have a degree of tension around changes to scope. Fighting against that tension is a wasteful and is a symptom of a failure to recognise business imperatives. Think about it this way, the business buys into a change initiative and mobilises a team of expert ‘doers’. Why wouldn’t the senior team, given changing circumstances, want to leverage the team? Of course it does depend on who is actually seeking additions to the scope.
With the recognition that initial aims and objectives, especially for longer term projects may change, we now need to understand what we can do to ensure that the impact of changing circumstances is controlled. What we must avoid is the temptation to change the course of the project on the fly, but to do so in a controlled manner. This controlled scope change is not scope creep. Scope creep is uncontrolled (or highly informal) change to project scope. What’s really important here is stakeholder expectations. If there has been a change to your scope and some or all of the stakeholders haven’t been consulted, then that’s scope creep.
So the real issue is controlling that change and managing expectations. Uncontrolled scope change is detrimental to efficient, effective project management, and might also be the result of underestimating the intent of an initiative. So, during initiation Project and Programme Managers need to gauge the appetite for changes in objectives, mid-steam. If there is no appetite whatsoever, then you’re going to have to be quite tough. That said you must also make sure you understand the context within which your project is set, even if stakeholders have no appetite for changes in scope, you might assess that it will be inevitable.
You can avoid the problem of scope creep by taking the following actions.
Clearly Defined Project/Programme Goals
Project Managers are pretty optimistic problem solvers. They tend to want to get straight to the ‘how’, i.e. “how am I going to do this?” In understanding the final aims and objectives/outcomes of the project we really need to understand the ‘why’ of the project, not just the ‘how’. For example, if the sponsor wants a building project to be completed by a particular deadline, instead of immediately focusing ‘how’, i.e. how will I deliver the building by that date? Start by focusing on the ‘what’. In this case the actual outcome of the project is not to finish the project; it’s how the project will impact the operations/people. For example, if a sponsor wants to build a 30-foot structure in the middle of a field, the initial thought about ‘how’ might lead to the intent to just have a facility. By switching focus to the ‘what’, we can identify that the structure’s specifications depend on what the structure will be used for. Will it be a retail location? Will it process raw materials, or will it simply be a place of recreation?
The answers to the ‘what’ questions can help you identify what the real outcomes are and how they will impact on the ‘how’. So the place to start, is at the end. i.e ‘begin with the end in mind’ – what is it that you really need to deliver? Answer this and feed this into your planning.
The Change Control Process
As we’ve already discussed, in reality scope creep will most likely occur. While this can seem disheartening, it does not mean you (or the governing body of the project) have to be willing to accept changes in the original plan. It simply emphasises the need to have a specific plan in place to handle any and all requests for changes in the project scope.
This plan must account for all increases in costs to meet the changes in the project’s scope. Furthermore, a process for modifying the project scope must always consider the element of time. Larger changes in scope will require longer completion times, and your team needs to have a process in place to clarify if these changes will be acceptable to workers, the project management team and the client.
Scope is one leg of the 3 legged stool that PMs must constantly balance. The quality of the final deliverable is based on the combination of scope, resources and time. Each of the 3 must be balanced in order to deliver the required quality.
If Scope increases and the Quality of the deliverable is to remain the same, then either (or both) an increase in Time and/or Resources is required. For example, if the Scope of systems roll out is amended to include a new department, it stands to reason that if Time (i.e. the deadline) is to remain the same then additional Resources are required to deliver the additional work.
Ultimately, the business may not realise how minor changes could impact the overall project, and it’s up to you to ensure any changes result in appropriate changes to the budget and schedule.
Stay on Plan
You or members of your project management team may have a tendency to go beyond what the the business originally asked for, to over deliver. While this may seem like a good idea, it can lead to other issues. Sponsors will learn to expect more than promised, and scope creep will become a major problem as they learn to ask for more. In some cases, going slightly beyond expectations is acceptable, but it should always be within reason and never be considered a given in any part of the project.
These actions can help you reduce scope creep. Each action should be part of your strategy for managing scope creep, which will actually help you maintain the value and integrity in your team as well.
In summary here’s my scoping checklist which if followed will ensure everyone will have a common understanding about what is being delivered. In order to be really specific about ultimate aims and objective, it’s important to seek answers to the question “why do we need do this?”. Essentially the answers to this question will deliver a series of very specific issues and problems that need to be addressed.
- Determine the intentions, expectations and views of all those involved.
- List the parts of the intentions, expectation and views that CAN be achieved and the possible/likely consequences if they are not achieved.
- Fully describe the current (and likely future) problems and bottlenecks and where possible back these up with data.
- Unambiguously detail the project’s end result or objective. The detail should be complete and written down.
- Describe the interim deliverables that combine to make up the project objective, these can include, for example: products; reports; systems and agreements.
- Whilst deliverables should be tangible where possible, it is possible that they might be intangible. Intangible deliverables should be avoided where possible and an intangible deliverable should be further sub-divided until the results are truly tangible.
- Clarify the boundaries of the project and deliverables. This should entail, for clarity, very specifically what is outside the scope of the project.
- Carry out a critical analysis of the feasibility of each of the deliverables, and their links to the final project objective.
- Ensure all participant understand the scope of deliverables and final objective, in detail.
- Embed a well thought out Change Control process into the governance of the initiative and ensure everyone is bought into it.
Finally, the Key Points to Remember
- Start by developing a solid understanding of aims, objectives/outcomes before you begin planning. Listen to a wide an audience as possible.
- Set standard procedures for addressing changes in project scope.
- Avoid the temptation to “throw in” extras in the project.
…………and finally, finally here’s my list of typical Scope areas
- Business process – which processes are in, and which are specifically out of scope;
- Functional – what is the functional requirement of the objective/outcome;
- Organisational – which parts of the organisation will be affected, and which will not;
- Geographical – for a geographically dispersed organisation;
- Technical – from a technical perspective, what’s in/out;
- Infrastructure – What parts of the organisation’s infrastructure will be impacted;
- Security – are there any security considerations?
- Interface – technical interfaces, intra and inter- business interfaces;
- Data – which data is in scope, and which is out. How will it be affected?
- Reports & Forms – For new systems, what existing reports and forms will be impacted?