Project Failure or Project Success?
By Ty Kiisel
The Russian writer and physician Anton Pavlovich Chekhov once said, “One must be a god to be able to tell successes from failures without making a mistake.”
Where projects are concerned that is often the case. Recently, a colleague and I were discussing the Standish Group’s Chaos report and debating whether or not their definition of project failure is really accurate. Although I agree that if a project fails to deliver the anticipated value, takes longer than expected or costs more than is budgeted I think it’s safe to say that it wasn’t a success—but does that also make it a failure?
Yeah, I’m weaseling a little bit here. However there have been some pretty high-profile failures that turned out to be anything but failures. Take Columbus for instance, he was looking for a quick route to India and found the New World. Was he successful at finding India by going West, no. Was it a failure?
Sometimes I think projects are doomed to meet the Standish Group’s definition of failure from the start. Stakeholders and sponsors aren’t clear with their expectations, project leaders are handicapped with unrealistic time-lines and project teams are woefully understaffed. When these conditions exist, is it any wonder that a project team struggles to hit a moving target with a broken bow and arrow?
With that in mind, let me make a couple of suggestions that might help keep your projects out of the “failed” category (at least according to the Standish Group’s definition):
- Define Success: This sounds pretty simple, maybe even too simple. Nonetheless, how many projects have you been a part of that didn’t have a clear definition of what success was before it started? Imagine shooting a basketball at a hoop that randomly moved during the game. It’s tough for project teams to hit a moving target.
If the Scope Changes, So Should the Definition of Success: I’m not a big fan of willy-nilly changes in the scope of a project, but if there are compelling reasons (other than the team is trying to reduce requirements to meet a deadline—which would indicate “failure” in my opinion) to change the scope or requirements, it’s not accurate to call the project a failure if it costs more or takes longer to finish.
Be Honest and Engage the Team in Resource Estimates: Arbitrary deadlines just don’t make sense and should be avoided at all costs. One of the things I like about the SCRUM methodology is the Sprint Planning Meeting. The team estimates resource requirements and takes ownership of their estimates. For project managers, this type of approach makes sense to me. Those closest to the work understand it the best and should be involved in making decisions about the time-line. What’s more, giving the boss the time-line he or she wants because he or she wants it isn’t a good idea if it’s not realistic—and sets the team up for failure.
Build the Right Team: Just because someone is available doesn’t mean that they are the person for the team. I know that many project managers don’t have the luxury of picking their team, but can exert influence over who is or isn’t part of the group.
Of course there is no silver bullet to avoiding the “failure” category. I’ve participated in discussions that suggest (for a number of reasons) that the Chaos information is inaccurate. Even if the actually results are 50 percent better than reported, it’s still too many failures. As project leaders, our job is to help get things done—successfully. That being said, what do you do to ensure project success?
About Ty Kiisel
Writing about project management for @task gives Ty the opportunity to share his personal experiences as an “accidental” project manager along with the lessons learned from conversations with customers, hopefully demonstrating that it really doesn’t matter what industry you’re in, the rewards of successfully executing project-based work are universal.
@task helps organizations focus on being more effective, innovative, and more competitive with a rich project and portfolio management solution that enables decision-makers to maximize their resources by implementing those initiatives that provide the greatest business value. @task helps align the strategic goals of objectives with the implementation and execution goals of project teams.