Never on the Rails
September 3rd, 2003 by Hal
Back in the spring George Sifri wrote a series for Builder.com on Project Recovery. I could only find the first three parts [1], [2], [3] of the planned four-part series on derailed projects. I know it has been 4 months since Sifri published these articles. [I'm a little late working through my file on articles to write about. Oh, well.] The series is worth reading through. Sifri offers a conventional view of what happens and what to do about it.
I have a different view. My less than scientific analysis leads me to conclude that most poor performing projects never were on the rails. There are three issues I see repeatedly:
- The project is conceived and planned by people who are not in the role of doing the work on a day-to-day basis. Plans are out of touch with the challenges of the project.
- The plan is developed at a level of detail that can be planned but not the level appropriate for the time. The issues that need to be explored are left to later, yet the overall time line stays the same.
- People are never brought together as a team all committed to produce the intended results. The project is just a collection of people, many who have more than one priority at any given time.
I encourage you to add your favorite reason for not being on the rails. There's no guaranteeing that doing what I say needs to be done will ensure a successful project. In fact, I'd say that having a successful project is a crap shoot. Putting two successful projects together back-to-back just doesn't happen.
I'm really not a pessimist. [Is that howling I hear?] I'm a guy who has come to expect the vast majority of projects are being started poorly and then attempts are made to adjust reality to the plan in place. Do I think a linguistic action approach would help? Sure. How about the last planner system™? That too will help. But I don't think either is enough to ensure two back-to-back projects will succeed. Projects need great leaders who put the people before the plan. Great leadership can compensate for poorly conceived projects. But great project plans don't stand a chance on a project without leadership.
Related Posts
- Running on Rails: Two Kinds of Action I had the pleasure of visiting a construction site last week in Milwaukee. It is a good sized project -- over $100 mill...
- Let’s Be Prudent I love it when readers take me on...Particularly regular readers. Frank Winters commented on my Sept 3 posting titled N...
- On-Time and On-Budget — but Projects Still Fail From down under we are advised to align management compensation to project success. On the surface this looks right. ...
- You Can Wreck the Project by Following the Rules Seth Godin writes a monthly column in Fast Company where he rails against our attachment to our common sense. There a...
September 4th, 2003 at 2:22 am
My newest favorite reason for not being on the rails is that nobody knows where the rails are.
Another reason I like is that the culture in many organizations is such that it really doesn’t encourage success because people in the culture don’t believe success is possible.
Hal - hate to say it but you sound like you might fall into the second cultural category.
Failure may be a real possibility on any project of significance but its not a forgone conclusion either — even if the last project the team ran was successful.
In my experience one success tends to create the opportunity for another, if you can keep the team together.
The team does influence the probability of success a great deal and needs to be factored in when estimates and plans are developed.
Bottom line — there is no reason to start any project thinking it will fail. But success does take lots of leadership, focus, support and sweat.
Nobody said this would be easy!
September 4th, 2003 at 11:22 pm
Ah, but I know success is possible. I’ve managed an organization where failure was unusual. One division had a record of doing 29 porjects in a row on time or early AND at or below budget. While time and budget aren’t the only determinants of success, the rest gets easy when the team knows how to operate to budget and promised completion dates. The most interesting info is the make-up of the teams. The division had 8 project managers and 12 superintendents along with a group of six architects. Teams were created new for each project based on the assessed challenges and opportunities of the project. The projects ranged from $40,000 remodels to $4 million ground-up projects.
Let’s look for the general conditions for success (the rails as you say), rather than the special condition of keeping teams together who’ve had a success.
p.s. Frank, I really like you challenging me on my perspective. I do believe that projects are started poorly. (Something for me to elaborate on in a posting) And I think that in the vast majority of cases involving project failure, teams are dysfunctional. That sounds strong, but let’s just say that people who only see themselves as performing tasks in their area of specialty are not a team.