From time to time, The Standish Group publishes reports about their CHAOS research, which analyzes the factors that drive success and failure in large IT projects. The first CHAOS Report, published in 1994 and now freely available on the Standish Group’s web site, has become famous in the software industry. The report identifies these failure factors:
Lack of User Input
Incomplete Requirements & Specifications
Changing Requirements & Specifications
Lack of Executive Support
Technology Incompetence
Lack of Resources
Unrealistic Expectations
Unclear Objectives
Unrealistic Time Frames
New Technology
I’m astounded that this list omits the single most important failure factor. I call this missing, crucial factor The Prime Project Failure Factor. So important is The Prime Project Failure Factor that if it isn’t present in your project, you can prevent the project from failing even in the presence of all of the other failure factors.
Imagine this scenario. You have been asked to commit to a proposed project. You notice that you have been given unclear objectives, no user input, requirements that are incomplete and unstable, and unrealistic expectations and timeframes. You have no executive support and few resources. You do have some new technology to use, but the few people assigned to the team are technically incompetent to use even the old technology.
This horrifying proposal exhibits all of the Chaos report’s top ten failure factors. The project is clearly doomed to failure, right? Well, no, not quite. No matter how many failure factors a potential project exhibits, you can still prevent failure by choosing not to do the project.
Seems simple enough, and yet I wonder. Think of a failed project in which you took part. Did you really not know at the outset that the project’s objectives were unclear, or that you didn’t have executive support, or that expectations were unrealistic? Did nobody know these things? And did nobody feel in their bones, right from the word go, that these factors doomed the project to failure?
Many “failed” projects fail from the start by ignoring The Prime Project Failure Factor: Choosing to proceed with a doomed project.
However it turns out, the project to build the Olympic stadium for the 2004 Summer Olympics in Athens will make a great case study for students of project management.
Here are three news stories that give a hint about the status of the project:
“In Greece, we are like ‘Sirtaki’ dance. We start very slowly, and then we speed up. And then at the end, you cannot even follow how quickly it goes. So I believe that’s exactly what happened with us,” says [Athens Mayor Dora] Bakoyanni. “We might be afraid until the last minute, but I believe that we will be ready in time.” (60 Minutes)
“So, granted, there have been delays. And there’s been inefficiency. Call it what you will,” says [former foreign ministry official Alex] Rondos. “The fact is that, as we approach the Olympics, not unlike the condemned man approaching the guillotine, it concentrates the mind wonderfully. And we are there right now.” (60 Minutes)
[Deputy culture minister in charge of the Games, Fani Palli-Petralia:] “We are working triple shifts everywhere and we will be ready.” (Reuters)
Petralia said: “We are turning nightime into day and I am convinced the project will be ready and will be magnificent.” (Reuters)
Those quotes don’t inspire confidence in me. But what does the project’s key customer, the International Olympic Committee (IOC), have to say?
“Our experts who have reviewed these plans say, ‘Yes, it’s feasible. It can be done,’” [IOC overseer Denis] Oswald said. (Associated Press)
“All the reports I receive indicate how fast and how hard Greece is working to complete preparations,” IOC president Jacques Rogge said. (Reuters)
“Feasible” and “working fast and hard” don’t have the ring of high confidence.
All of these quotes, from the IOC and from the project team, seem vague and non-committal. I don’t know whether that’s because the people are saying only vague and non-committal things, or because the reporters are selecting only vague and non-committal quotes, or what. Whatever the reason, these quotes smell funny.
The planned roof on the swimming stadium was scrapped weeks ago. Anyone taking bets on the (as yet uninstalled) glass roof over the main stadium?
(As I write this, news comes from Reuters of a series of three bombs exploding in Athens, near the hotel where Olympic officials will stay during the Games.)
In “Congruence and the Prime Directive“, I wrote about how congruence — honoring Self, Other, and Context — allows people to bring their talents more fully into a project. By bringing greater talent to bear, congruence helps projects succeed.
By my definition, a project is successful if:
it delights its customers,
it enhances the team’s ability to work together in the future, and
it creates value and meaning for its individual members.
For most projects, I want all three of those conditions. If the customers aren’t happy, the project wasn’t successful, no matter what value the project team members enjoyed. If the project team is burned out, the project wasn’t successful, no matter how happy the customer are.
In some cases, I might consider a project successful even if it does not leave the team better able to work together in the future. Some projects, for example, are accomplished by a task force that comes together, accomplishes its goal, and disbands, never to work together again. But perhaps even in these cases, the team members would do well to learn something about how to work on projects and how to work in teams. And if the team members will work together on subsequent projects, I want not only for the project to satisfy its customers and its members. I also want the team to learn from its experience, to create value for itself as a team,
Like any definition I offer, my definition of project success tells you more about me than about the thing I’m defining. And I suspect that any definition of project success is essentially an expression of who and what the definer cares about. My definition tells you that I care about the people the project was intended to serve, I care about the individual project team members, and I care about the team as a team.
Who does my definition leave out? It isn’t clear to me where sponsors (or investors) fit in. Are they customers? Are they project team members? I want them to be satisfied, too. What about other stakeholders? What about members of the community in which the project takes place?
I care about those people, too. I feel anxious when I leave out people I care about. So my definition of project success is a work in progress.
Note: I adapted my definition of project success from J. R. Hackman’s definition of “group effectiveness,” which I read in Intervention Skills , Brendan Reddy’s excellent guide for facilitators.
Experiment: How do you define success for your current project? How does your definition express who and what you care about? What people and values are included in your definition? What people and values are not included?
Experiment: How do your project teammates define success for your current project? How does their definitions express who and what they care about? What people and values are included in their definitions? What people and values are not included?
When I first started managing software projects, I used to wonder, “Who is this Scope Creep guy everybody is always talking about? And how does he end up on every one of my projects?” Eventually, I discovered who the Scope Creep is, and how to banish him from my projects.
Before my discovery, I had a fuzzy idea of what scope creep is. Scope creep is when the project’s requirements slowly grow and grow, until the product bloats, the schedule slips, the project team sags, and the customers wonder whether we’ll ever deliver anything. This Scope Creep guy is a bad dude.
My first inkling of the real identity of the Scope Creep started when I took a close look at the words scope creep. If you take the words literally, they say that scope is creeping. Scope is creeping? What on earth does that mean? Bugs creep. In rush hour, traffic creeps. But scope? Scope is an inanimate thing. It can’t creep. Not all by itself, it can’t. If scope is creeping, it’s because someone is creeping it.
So who is creeping the scope? Who is growing the requirements? Must be the customers, right? After all, they’re the ones asking for more and more stuff. Or maybe it’s the developers thinking up fascinating features that they’re sure the customers will love. Maybe they’re the ones who are creeping the scope.
No, that’s not enough to cause scope creep. It’s possible for customers to request dozens of new features, and for developers to imagine scores of bells and whistles, without scope creeping in the slightest. Scope isn’t the set of stuff customers have asked for. Scope is the set of stuff we’ve agreed to deliver. If scope is creeping, someone’s agreements are creeping. And if my agreements are creeping, that means I’m the Scope Creep.
Scope creep isn’t merely about changes in scope. Scope creep is about how we manage changes in scope. Even if we make many changes, and add many features to the scope on which we have agreed, as long as we change our agreements consciously, mindful of our choices and of the consequences, scope doesn’t creep. It simply changes.
These days, when I hear the words scope creep, that’s my reminder to attend to my agreements, and to how I manage changes to my agreements. Managing agreements banishes the Scope Creep.