People Make Projects Fail
The other day a friend said that there were three reasons for project failure. I took exception and stated there were two. As I thought about it more, there is only one. People are at the root of all failures, everything else is a symptom. Let’s look at some common reasons.
The project is over constrained. People set the constraints. If they do not understand the project well enough to set the constraints, or listen to the people that are suggesting the constraints, then they are the problem.
It is poorly managed. Enough said about this. It is a people problem by definition.
It was unachievable to begin with. This is really a subset of over constraint—severe over constraint. Nearly anything is achievable given the right resources. Yes, there may be some that are truly a waste of time, bringing back the dead falls into this category. Or, does it? Wouldn’t cloning the person be a form of this? Isn’t that, in reality, only a constraint? The cases that are technically infeasible, are management issues. The proper due diligence, done at the onset, will prevent them from happening.
When I posted this blog originally, I used a tweet saying failure was due to people not process. There was an immediate response that Deming and Juran would disagree. They were all about systems, not really process. Process, proper process, made the system more predictable. They followed the 85/15 rule regarding people. This rule is, 85% of a worker's effectiveness is determined by the system he works within, only 15% by his own skill. However, implementing an improper process is a human problem, not a process problem.
Experience says stick with people as the problem. If we focus on people and not totally on process, our projects would be better off.
The human factor is sorely missing from project management. People seem to think that process will fix it all. Process will do nothing until we can get the people to develop good processes and then get everyone to apply that process correctly and follow it.
Simply applying a process solves nothing. A process to define all requirements prior to building a product might be great for pulling |
The two-part People vs Process (July 2009 and September 2009 issues) in PM Technique eZine cover this in more detail in .
Tags: 
IT Failure Project Management Leadership
 |  |
