Scope creep is one of the most common project management risks, leading to unfortunate outcomes such as projects completing late, over budget and/or lacking in quality.
As such, when initially framing a project it is equally important to clearly determine what is in scope as it is to determine what is NOT in scope. Doing so ensures laser-like focus on ONLY that work necessary to effectively and efficiently meet expectations and complete the project.
Considerations may include things such as:
- Countries we are entering / not entering
- Product(s) and/or version(s) included vs. not
- Organizations, processes and/or systems to be touched / not touched
- A firmly fixed timeline and/or budget
- Other boundaries applicable to the project and/or organization
As great a job as we may have done at this, in support of kickoff, new things (ideas, requirements, etc.) will undoubtedly emerge. And, the longer the project’s timeline the more likely new things WILL materialize. So, be not surprised…
Said another way, we’ve framed our project, clearly defined scope and have a detailed plan mapped out to deliver precisely what was specified. Then, it hits…Something in the market or business changes, a key team member comes up with an idea to make things “even better” or identifies an unforeseen issue/risk. At this point, we need to go through a process to determine if and/or how the new requirement(s) will be included in the current project.
The first step is to perform triage. That is, we must NOT go into solution mode, yet. First, we (along with our key stakeholders) need to ask questions such as:
- Is this REALLY an issue, concern or benefit? If so, quantify?
- MUST this absolutely be addressed for go-live, and why?
- By NOT addressing the item does it make things worse or is it merely a nice-to-have?
- Is addressing this worth the risk of a potential timeline, budget and/or quality impact?
The possible outcomes from this triage include:
- Killing it, if it is unnecessary
- Considering it, by further determining impact
- Hold it, for a future phase or initiative
If, after initial review, stakeholders agree that the item is unnecessary, or after further consideration comes to this conclusion, then we simply log the item in our Risks, Actions, Issues and Decisions (RAID) Log along with the agreed upon disposition.
If it is agreed that an item “seems” to warrant further consideration, we’ll want to perform a cost / benefit analysis to quantify impacts to the:
- Financials of doing / not doing the request, considering and contrasting things such as the:
- additional cost of incorporating the request
- revenue impact (i.e., more if we handle the request, less if we don’t)
- internal efficiencies (i.e., additional headcount required or not required as we scale the business)
- Timeline
- Does the request fall into critical path, or can it be accommodated without impacting critical path?
- If the request is on critical path what is the timeline impact?
- Resources
- Are ALL necessary resources available to commit to performing the necessary (new) work, in the required timeframe?
And, depending on the nature of the project and/or organization there may be other considerations.
Once information such as the above is gathered, we’ll review it with our key stakeholders to obtain agreement on disposition. If there is agreement to proceed with adding the item to scope while accepting the impacts, then it is time to update our project artifacts, re-baseline our plan, communicate the decision and impacts to all stakeholders and execute accordingly.
Some projects, such as those which are software-related, may generate MANY new requirements which materialize during design, development and/or user acceptance testing, for example. When we must consider a number of these items at once, or through-out a project, we’ll want to go through a similar exercise as above, to determine which truly have merit, then add a priority consideration. That is, they may all have some level of merit, but we simply cannot get them all done in the specified timeframe. The levels of priority might be as follows, with consideration given to the quantified impacts that result from the above exercise:
- High / Must-have
- Medium / Important
- Low / Nice-to-have
Once we’ve assigned and agreed upon priorities our course of action becomes much clearer. That is, we’ll want to determine how best to address the Highs or absolute Must-haves and from there determine if and/or how many of the Medium and/or Low priority items we may wish to consider within the agreed upon financial, timeline and resource impacts.
That said, we must use extreme caution so as NOT to increase our scope beyond handling the Highs/Must-haves when on a tight timeline. Otherwise, we further increase risk because (and mark my words) something else ALWAYS comes up. As such, it is important to leave wiggle room to accommodate unforeseen items that will undoubtedly materialize.
And, finally, any items that don’t make the cut for the currently defined project can remain on the list for a future phase of the project or new initiative.
In closing, if you are looking to improve PM effectiveness in yourself, or organization, feel free to reach out so that we can discuss how I can help.
Click here to return to our topical index of articles on High Performance Project Management.

One thought on “PM: Managing Scope”