Scope out of control. Courtesy: Ukraine Parliament.
Projects are how organizations deliver and realize their executive strategies. The degree of what people expect is called project scope. Misunderstand scope of what, when, quality, how much, where, and what "done" looks like and you misunderstand scope.
Scope kills projects and projects that fail to deliver kill organizations. Scope is one of the most important ways to manage project success. The ability to deliver a project provides an ability to compete for relevance. Organizations rely on projects to remain competitive and when projects succeed, organizations succeed. Projects fail at an alarming rate:
- 74% of all projects fail to come in on budget or meet their original deadline;
- 90% of major IT project initiatives fail to complete on time and on budget;
- A survey by KPMG, an international consulting firm, finds globally that 56% of IT projects fail at underestimating the scale of the problem;
- Certus, the UK IT director forum, believes that the failure rate of IT projects is closer to 90%
This is a first in a series of scope and project management blogs to improve project delivery. No prescription guarantees repeatable success. Project management is not a process, but a business promise.
To understand scope we need to broaden our scope and this series will look tools, views, and principles from multiple disciplines. After all, the scope of an Information Technology (IT) department is to serve business, not technology.
How Projects Fail People
Why is scope so important? When projects fail, business loses money and that project's lost opportunity becomes lost cost: lost in lost work hours and lost in capital available for alternative investments.
Project failure increases organization risk to deliver projects. As people lose confidence in coworker ability to deliver projects and for teams to design solutions valued people resources are pulled from projects. The more that projects fail the more resistant people are to associate with new projects or to work on projects: no one wants to fail.
The below CIO survey results interest beyond the number one response: Resistance by Employees.
Responses such Unrealistic Expectations; Inadequate Sponsorship; No Organization Change Plan; well, actually, every response is a human capital issue. People set project scope, but people and human capital are far bigger than any project management process.
There is need for something more. The CIOs surveyed reveal the downstream symptoms of poor project scope root cause.
Top 10 IT implementation failures are scope failures
Project Scope Management
Successful change management relies on successful scope management. Successful scope management relies on people management. Projects start with, what seems, the best intention, but along the way to deliver on time, on budget, and up to original expectation scope changes.
Scope is a fixed idea of what to deliver, but scope ruins projects in three ways:
- Scope ill-defined;
- Scope modified (often called scope creep or gold plating); and
- Scope of today is less certain than tomorrow
Too often the zeal to start a project to meet a delivery date supersedes scope. When people take too little time to interact with project sponsors, stakeholders, and customers to collect and analyze their expectations or the impact the project will introduce or require change to their world. Starting the project without a detailed scope management plan is the difference between getting the project done or getting the project accomplished.
Projects fail when scope is not clearly defined. Scope is not clearly defined when sponsors, stakeholders, and customers are not listened to or asked their needs.
Modifications to scope adds project risk down the entire project's life. Projects that fail increase the very real risk of an organization’s ability to compete.
How People Fail Projects
Scope, in project terms, is simply, "what’s in…what's out". When you change the scope of a project, be it an added feature, a delivery date revision, or quality criteria modification, you affect clarity of what is delivered, by whom, for whom. Change to one element impacts the other two, this is known as the triple constraint between:
- Cost/Resources,
- Time/Schedule,
- Scope
Try to tweak any one of the above three without affect on other two. No level-headed mortal can get around that any change ripples impact onto others - despite project sponsors who close their eyes and ears to that reality. Scope management includes process to ensure the project includes all the work required, and only the work required, to complete the project successfully, to include:
- Features
- Quality standards
- Schedule
- Budget
- Resources
- Risk
Scope management includes the processes required to ensure the project includes all the work required, and only the work required, to complete the project successfully.
Managing the project scope is primarily concerned with defining and controlling what is and is not included in the project.
Without a clearly defined scope, projects fail to hit the bull's eye, let alone identify the target. When scope changes, budget changes, delivery dates slip, and resources might expire.
When scope is continually modified, how can anyone expect to deliver a project on time, on budget, and within anyone’s expectation?
What’s Project Scope Got to do With It?
Scope is not a target you aim for. Scope is the bull’s eye. You either hit or you miss.
Constant scope shift obscures the view and without defined clarity no one knows what success looks like. A project changing scope is just as negative as a trying to manage project success with a poorly defined scope. Both poorly defined scope and constantly shifting scope will kill a project.
Poor scope definition hides the opportunity to accurately build a budget, understand the return on investment, staff the project, and manage progress against measurable objectives.
Scope is about communication and trade off, scope can change as new conditions unfold, but sharing what to stop, what to start, and what to continue focuses resources on reality's impact.
Without this work upfront the project or product scope continually changes as people step forward to challenge the project or ask for change. See Scope or: how to manage projects for organization success, part 2.
Below is my first ebook, modified from a presentation I gave to the Project Management Institute Mass Bay Chapter on how to identify, manage, and control scope.
Included are tools, tips, and templates I've used for stakeholders management, impact analysis, communications planning, and risk management.
Sources: A Guide to the Project Management Book of Knowledge (below).
There are better books, but this sterile guide to the Project Management Book of Knowledge is a must-have and one of the best places to begin. 
Share this Post
Comments 10
When projects fail, it can often be tracked back to an inadequate definition and agreement of the scope. In my experience, scope is left vague, because
1) specifics often lead to disagreements disagreements.
2) like prepping a room to paint, scoping a project is often hurried to get to the “real” work.
Author
Both your points really represent a risk averse approach that kicks the likelihood of project failure right off.
Fear of disagreement is an unhealthy organization that has no diversity – if we can't talk about alternatives or perspectives with an eye towards creativity and innovation, poof there goes the project.
Prepping a room for paint is a great analogy. The finished product is only as good as the scraping, sanding, smoothing, primer, cutting in, brush, and paint – but too many let those details get that in the way of saying we painted the room. What can't be said is painting it and painting it well are 2 different things.
Thanks for your comments John and your posts at your site Management Leverage.
As John indicates, up-front planning is a far more efficient way to spend resources than with ad-hoc execution. I'm all in favor of creating early warning indicators so that deviations from plan (such as increases in scope) are caught early or, better yet, before they happen. The Department of Defense mandates the use of an Earned Value Management System (EVMS) to catch such things. While their implementation can be onerous, any usage that complies with the ANSI standard for EVMS should help to prevent things from spinning out of control
Here's a link to the DoD EVMS site at Defense Acquisition University, which contains even more links to other resources: https://acc.dau.mil/evm
Author
Earned Value Management (EVM) is a clear, concise, and understandable way to know when and where your project is off-track, by budget, schedule or both.
EVM desperately relies on an accurate work breakdown during the scope stage. Work breakdowns rely on the subject matter expert who is charged with delivery – as the worker, in the field, not as the lord of the manor.
It is great you mention the DOD's use of EVM. It is unfortunate that the DOD, in a recent study of the brilliant, but unfortunately toothless, Government Accountability Office (GAO) found, in a 2008 report [click to download .pdf] that on 95 systems the average unforeseen schedule delay was 21 months and the total cost of these delays hit $295 B-I-L-L-I-O-N (billion).
The trends GAO looked at were disturbing, in 2000 compared to 2008, the cost of delays, in absolute terms, increased 702%. The average delay in 2000 was 16 months and 2007 21 months.
The cost of requirements changes of projects underway was a sobering, to tax payers at least 72%. 72% increase in costs [click to download .pdf].
EVM as a tool is brilliant. It seems the cobblers children has no shoes.
Thanks for taking the time to read and write – I appreciate your perspective.
Now THIS is good stuff. Thanks for the link to the GAO report. I found that to be terrific.
I did not see a condemnation of EVMS as a tool, however, and I think we'd agree that it is a powerful method. EVMS is not a determinant of program outcomes, however, only a set of indicators. If those indicators are ignored (due to a host of systemic deficiencies) the, clearly, we can see the outcome.
To your point regarding scope creep, this statment in the GAO report would seem to support your remarks: “GAO found that 63 percent of the programs had
changed requirements once system development began.”
Spot on. If (always a dangerous word, but nonetheless) if it is done by the book, EVMS will provide the indicators necessary to depict a situation where things will soon fall apart. Unfortunately, internal politics within the contractor's organization, relationships between contractors and government entitites, as well as those within government bodies themselves will often result in a misinterpretion, or misrepresentation, of what the metrics predict.
The root cause, unfortunately, appears to be the same here as we see almost everywhere, regardless of the industry or the level of the people involved: If you are afraid to tell your boss there's a problem, you will soon have a much bigger problem, no matter the tool used.
Thanks for the additional GAO info, and a very thought-provoking post.
Author
GAO reports are just incredible sources of information across transformation, change management, IT integration.
The GAO or Government Accountability Office as their site says: is known as “the investigative arm of Congress” and “the congressional watchdog.” GAO supports the Congress in meeting its constitutional responsibilities and helps improve the performance and accountability of the federal government for the benefit of the American people.
Nice, but who's watching the watchdogs?
As disappointing as the fact that the GAO rarely get listened to other than cursory white papers, any project I started with for the Federal Government I first went to the GAO to do research. Did they have studies or proposals in their archives, what had they written about?
Their research always had a list of recommended steps for improvement. It was easy for me to start the conversation with, “so, what have you been able to accomplish since this GAO report…”
Even if you are not working in public sector the GAO offers great human capital or transformation/change management-style tips.
Thanks, as always, for your comments David.
Interesting post on scoping. Among the reasons of project failures or going over-budget is less focus on functional scope clarifications. The proposal documents talk in detail about processes, tools, resouces, schedule, milestones, QA and payment terms; however, they fail to address what constitutes funtional scope, and what is out of scope, and what ‘can be’ considered as change requests.
Every one including business analysts, project managers, programmers, assume certain things in scope but rarely ensure that they are ‘assuming’ the same thing in same sense.
Each stakeholder or person a project touches has an assumption or filter that always asks “What’s In It For Me?”
Scope planning is critical to get that on the table and level-set the scope of the project, not the scope of the stakeholder need. It is a fine line and very difficult to manage. But remains the single most important opportunity for a project to meet goals.
Of course scope can change, but the way you manage it is not to let scope grow like a weed, but to discover changes or new conditions and actively assess the impact on the original thoughts: risk, both positive and negative.
Thank you for the comment Vinish.
Where do you find the greatest opportunity to engage in a real discussion around scope and who needs to be in that room?
Great article, Toby! Seems like scope should be the first thing a PM considers in the planning stages of projects. I think you would find this Ultimate Guide to Project Management (https://www.projectmanager.com/project-management) interesting.
Author
Appreciate that you stopped by to read and to comment.
Poor scope plagues many, even Alice in Wonderland had an issue to explain scope to one trying to help, just like us.
Scope helps narrow the possibility and provides a good chance to validate vision.
I wonder how the software you recommend leans towards interacting to uncover, iterate, and validate scope along the way.