Heading off the rails, again

Several conversations have me thinking about why projects - any kind of project - falls off the rails so many times, even though people have articulated the common reasons for why this happens over and over again.

In Why is it so hard? Glen B. Alleman recreates a list of typical reasons he read from Steve Romero about the traditional ways and reasons projects seem to go off the rails.  (I've had this article sitting around for pondering for a week or so, trying to figure out what to add.)

  • We don't have enough resources to get the work done
  • In our organization, there is no real planning process and when there is no one follows it
  • We don't prioritize our projects or the features in them. every project is a #1 priority along with the "must have" features
  • Our priorities are constantly changing with no explanation, impact analysis
  • Everyone is by passing the approved processes and then wonders why things go wrong
  • Funding tends to be very political, unstable, and not connected to the produced value
  • We can't kill a project or a feature in a project. If we do kill a project or the features, it always seems to show up again. We never have any objective measurements to overcome the politics in decision-making. 

And just recently, the Critical Chain mailing list has been having an in-depth discussion of "systems" and someone brought in Dave Snowden's ideas of systems (simple, complicated, complex, chaotic).  One of the mailing list participants listed several projects that are having trouble in implementation or with specific techniques within the implementation.  These are not unique to those projects, the issues have come up with projects in which I've participated.

The discussion on the mailing list and the list above from Glenn have me thinking of another principle of Theory of Constraints projects: Undesirable Effects, often termed UDE's.  If you look at a system and see many undesired effects related to the overall performance (or lack thereof) of the system, it probably points to some underlying principles that need to be resolved before the UDE's can be removed. 

Most of these effects are the results of the system in which they operate.  And it isn't like we have never seen these things arise.  So... to ask the same question as Glenn, "Why is it so hard" to anticipate these issues and trim them in advance, rather than discovering them as the project heads the wrong direction.

1 Comment(s)

Brett said:


Reading through your thoughts here and the sources you reference, it seems to me that there are two competing learning activities involved: 1) organizational learning (that is, learning how to manage a project) and 2) individual learning (that is, learning what is needed to execute the parts of a project).

This is a quandary that I've been trying to figure out for quite a while: how do you provide an environment where team members can continually learn while at the same time ensuring the maximum efficiency possible in the overall project? And when it comes right down to it, which is more important to an organization: overall performance of the organization or the growth and development of the members of the organization?

In theory those two go hand in hand. In practice, that's not always the case. What's good for one isn't necessarily good for the other.

Leave a comment

Previous entry: Scanning the filters, filtering the scans

Next entry: Severe post-implementation disorder

Picture a steaming coffee cup. Better yet, grab one and have a read!

KJolt Memberships

Follow jackvinson on Twitter

View Jack Vinson's profile on LinkedIn