Sure It’s the People – But Which People? by Bruce Nielson
So if we admit that software is really about human intelligence, not tools, then we know that human factors matter the most.
Tom Demarco and Lister, in their famous (infamous?) book Peopleware, were the first to make popular the idea that it was people that mattered the most.
But I can't shake the sneaking suspicion that they missed something. You see, I've taken top notch programmers and had them succeed on one project and failure miserably on another.
I remember one client that, whenever he called, I'd cringe. I knew – knew – that no matter who I assigned to the project, it was already a failure from the moment he called. But when his counterpart at the same company called, I knew – knew -- the project was going to succeed no matter what.
Somewhere along the line the thought occurred to me: could it be that the customer was the primary success or failure factor on my projects?
But how could that be? I knew tools weren’t the main factor, but how could programmers not be? How could it be the customer -- who never wrote a line of code!?
Thus began my study of the broader software project success factors.
The Chaos Report
Perhaps you are familiar with the original Chaos study from the Standish group and it's project failure and project impair factors. This was a study that started out trying to determine what affect tools has on the success or failure of a project. As they started interviewing people, people would volunteer things like “well, the tools don't really matter, but let me tell you what does.”
Eventually, due to the overwhelming evidence, they had to rethink the study based on the documented factors that correlated with success.
First, they found that a lot of software projects –nearly a third! – fail entirely. As in, you spend a lot of money and get nothing back for it. (See this link for more information.) This is sort of scary and I hope word doesn't get out about this little fact about software production.
Think about that for a moment. If one third of all software projects fail (or did back when the study was done, anyhow) then that means that every software project you do already costs you one third more than you thought, even if you come in on time and on budget. Okay, I admit that's bad math. In reality, it's the big projects that fail, so it's probably closer to half or more if you're a big company with big projects and a lot less if you're a smaller company with smaller projects. But you get the point.
The Chaos report further showed that over half of projects will cost 189% or more of their original estimate. Imagine if that happened to your house when you built it.
“Hey, buddy, sorry about that. I told your house would be $200,000 – greater starter home by the way – but instead I'm going to have to charge you $378,000 for it. But don't worry, you can mortgage it and pay it back over 30 years. That's there what we in this industry call capitalization!”
What Were the Real Success / Failure Factors?
More interesting was the fact that the success and failure factors that we normally think about, such as having a good project team, didn't turn out to be that important to the project after all. Here is the list they found in the study:
Project Success Factors % of Responses
- User Involvement 15.9%
- Executive Management Support 13.9%
- Clear Statement of Requirements 13.0%
- Proper Planning 9.6%
- Realistic Expectations 8.2%
- Smaller Project Milestones 7.7%
- Competent Staff 7.2%
- Ownership 5.3%
- Clear Vision & Objectives 2.9%
- Hard-Working, Focused Staff 2.4%
Other 13.9%
Apparently a competent staff only mattered 7.2% of the time. You get another 2.4% if they are hard-working and focused. That's a whopping 9.6% of the time that the development team ended up causing the success of the project.
What really amazes me is which members of the extended project team really mattered: End Users (15.9%) and Executive Mismanagement (13.9%).
But it gets better. It turns out that the process you used (Run for the hills! He's talking about process!) mattered more than the development team!
If your “process” included a “clear statement of requirements,” you score an extra 13.0%. If it included that little thing called “planning,” you get another 9.6% (that's equivalent to the entire development staff under best circumstances!). If you have “smaller project milestones,” score another 7.7%.
So apparently “process” does matter and maybe even more than the development team. Counter intuitive? You betcha ya!
It’s Not the Development Team That Matters!?
So, as it turns out, people are what matter the most, but it's not primarily the “developer-people” that cause projects to succeed or fail.
How can this be? Since when does a project get determined by the people not doing the work on the project? Welcome to the topsy turvy roller coaster ride that is software projects. Buckle up and grab the barf bag. You're going to need it.