This website covers topics on knowledge management, personal effectiveness, theory of constraints, amongst other topics. Opinions expressed here are strictly those of the owner, Jack Vinson, and those of the commenters.

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.

Severe post-implementation disorder

Scanning the filters, filtering the scans