Regardless of how well you initiate and plan the project, the journey only starts at that point as you then have to execute the work. For me the biggest risk seems to be the dreaded Scope Creep.
The PMI define Scope as the sum of the products, services, and results to be provided as a project. Scope Creep is defined as the uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.
For me, a far more accurate definition of scope is the outcome for which the stakeholder/client/sponsor who pays for the project is willing to pay.
So first things first; where do we draw those lines for in and out of scope? My assumption here is that we’ve already initiated the project and so a) have confirmed it is a project (temporary, defined start/stop, clear business case, etc.) – all those things we do as part of the Project Charter – and b) the time frame makes a project approach worthwhile to the company (some places mandate minimum size or duration) and the PMO has approved the project start.
Part of this start process must be to identify key stakeholders, starting with the one who will pay the bills and sign off on the Charter, etc. Next we identify the key players, and types of groups of users. If one of these groups are large in number (eg. a floor of traders) then select at least one person who can speak for them and get them on your list.
At this point we run through the basics:
- Review initial documents and project charter
- Identify the ‘big picture’ of how the project fits into the organizational strategy.
- Ensure you fully understand acceptance criteria. Going back to my alternative definition of scope, you need to understand what the client is willing to pay for and what is their definition of done.
- Identify the main project constraints (dates, staff, budget, etc.) and assumptions as these start to provide clues to where the red lines and boundaries are going to be. Start with the money – how much have you got, what’s the contingency, and how long to burn it.
- Identify how many key stakeholders need to be actively involved in any communication you need to generate, and what level of detail they need to keep their expectations under control.
This list along with the Charter should be enough to at least outline the project boundaries and identify key milestones.
It’s at this point that we bring up change control; the PMBoK has Change Control Procedures as part of the Organizational Assets we use to develop the main Project Management Plan and as far as I am concerned the sooner we get this on the table the better.
Let’s go back to the definition of creep again; the uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.
Now review the definition of Scope; the outcome for which the sponsor who pays for the project is willing to pay.
The simple reality is this; if the main project sponsor (the one who pays the bills and ultimately decides if the project is completed to satisfaction) wants feature X added to the project, then it is going to happen. What we need to agree is that if there is an impact, then the PM will confirm the impact to the change control board and if it is material to the budget the sponsor will pay for it, and if material to the delivery date the sponsor will accept it. This saves a whole lot of dancing round later on when changes happen and then people are too scared to stand up and say what the cost is.
At this point we can run through the rest of the Planning tasks and generate the schedule, artifacts, Requirements documentation, Traceability matrix, and Work Breakdown Structure and Dictionary, etc.
What is equally important is that the Project Scope Statement also clearly states what is not in the scope if there have been some discussions and items have been kicked around by the teams. Far better to have a simple statement now that Report X is out of scope than to have Senior Manager Y decide 5 months down the line that they recall clearly and categorically that you promised it was in scope.
Even in the best laid project plans, changes will come. People forget things during the initial scope, markets move, Governments change the playing field, bugs get found. Better to get a clear framework in place from the start.
Of course, the one thing all this preparation cannot do is defend you from the unknown. Once a change request is made, the tools available to you to work out the impact are fairly limited. You basically have to rely on the Expert Judgement of you, your team, and the stakeholders (generally this is all I’ve needed but the list could include professional experts, industry groups, subject matter experts, etc.)
The main requirement is to think through the change and its full downstream impact, but not too much or you can end up over-analyzing everything. Most often, Creep is introduced when we don’t fully capture and think through all those impacts, which on a complex project can be easy to do, but this is the exception more than the rule. After all, that is why we track progress.
However, by at least agreeing in principle that the sponsor will cover the cost of those changes they introduce this reduces a lot of the conversations to “the change will cost $X and delay the project going live by N weeks. Is this acceptable?” The board can then decide if the change makes sense from a strategic and cost viewpoint, or even whether it removes the business case for the project.
By getting the process out in the open and agreed at the start of the project, a clear change management process goes a long way to avoid the uncontrolled expansion to product or project scope without adjustments to time, cost, and resources – that is, it goes a long way to avoid scope creep.