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

  1. User Involvement 15.9%
  2. Executive Management Support 13.9%
  3. Clear Statement of Requirements 13.0%
  4. Proper Planning 9.6%
  5. Realistic Expectations 8.2%
  6. Smaller Project Milestones 7.7%
  7. Competent Staff 7.2%
  8. Ownership 5.3%
  9. Clear Vision & Objectives 2.9%
  10. 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.

Published Friday, December 11, 2009 8:00 AM by BruceNielson


# re: Sure It’s the People – But Which People?

Thursday, December 17, 2009 9:29 AM by Nathan Zaugg

Hey, Did I work for the project you talk about in the first paragraph?

# re: Sure It’s the People – But Which People?

Thursday, December 17, 2009 2:16 PM by Nathan Zaugg

Okay, I have been thinking a lot about this post and I have to say that as a programmer this is very frustrating!  We get more than our share of blame when something does go south AND we can to very little to affect the outcome.

From my perspective it seems to me that the most important person is the Project Manager.  Your list is a list of attributes about a project as success factors, but a good PM can and will bring those to the table.  That means that the second most important people are management!  In consulting it's twice as many people to satisfy but if management isn't on the right page with the project then starting it in the first place is not advised!

Being a programmer is a tough gig!  People want estimates. They will hang you by your thumbnails until you make up a number!  Then they want you to track to your estimates.  This is also frustrating because the project never unfolds anything like what you estimated so the original estimation items essentially become buckets of time.  When you go over the estimate it seems like the assumption is that WE are the ones who made some big mistake or were unproductive or inept!  And it's twice as bad if you didn't tell someone before you went over your 5 hour task.  At the end of the day your mind is numb from working and if things are going badly everyone hates you!  

It's little wonder that there are very few programmers who stick in this field their entire career.

# re: Sure It’s the People – But Which People? by Bruce Nielson

Saturday, December 19, 2009 10:19 AM by BruceNielson

Excellent points, Nate!

Can I quote you in future posts? :)

I do think you are right about the Project Manager playing a huge role in the success factors. But still, it's only an "influencing" role, not a direct role. But a good project manager can "stack the deck" so to speak.

# re: Sure It’s the People – But Which People? by Bruce Nielson

Saturday, August 21, 2010 11:20 PM by Nathan Zaugg

I just ran across this and thought of this blog post: