“Project management? That’s just a lot of useless overhead!” I remember hearing variations of this a lot years ago. I don’t hear this much anymore (due at least in some part to the good work at PMI), but I have been seeing something of a variation.
Working with some engineering teams at some big companies, I’ve had conversations with engineers go something like this: “Why do our projects go so much slower here? When we were a startup things seemed to go much faster — and we didn’t even use project management!”
Upon digging a bit deeper, it turns out that there are a few things to consider.
Some of the slowness was a perception due to having more formal procedures (and the documentation surrounding those procedures). Some of the slowness was due to pretty bad meeting management — long periods in meetings where nothing pertinent to most of the participants was going on. Some of these meeting were “needed” because so many different groups of people were involved.
Some of the “slowness” is really due to the fact that the big company project is often creating a product that is more “polished.” The engineers would admit that in the “old” days they would celebrate success with a product not quite ready for commercial release.
So, some of this “slowness” is about some of the things that come with being bigger. We can talk about ways some innovative organizations overcome these issues some other time.
Looking at this big company “friction” or overhead still did not seem to account for this slowdown. Could it be that project management really is an insidious overhead? Well, all of us can probably remember a few cases of project management gone wrong — too many meetings, analysis paralysis, inadequate or too elaborate change controls, etc. So, we deal with these items by doing a project management well.
On the other hand, there is something that seems to slow projects down by design — schedules.
How can that be? Let’s start with those unrealistic schedule first. You know, the ones that aren’t really set through a rational process of estimation, but rather a target meant to “push” people. I don’t think we need to dwell on this too much — we end up spending a great deal of effort changing and blaming rather than doing the value adding tasks.
How about those realistic schedules? They are based on rational estimates and good statistics based reasoning. It’s not uncommon to have a policy of 90% — that is, give me an estimate with a 90% probability of being met. This sounds pretty good, yes?
Let’s use this as an example. A = 12 days, B = 14, C = 13, where each estimate is at 90%.
So, the project = 39 days. Can we say that we have a reliable schedule? Maybe.
.
.
One way to look at this is that the 90% is like adding a “buffer” — for example, if each task was a 10 day task at 50%, we add buffer until we get to 90%.
Unfortunately, the way a lot of us build a schedule from this estimation, it is only as good as the last task. Our schedule would show that task C starts at the end of day 26 and ends at the end of day 39. If we coordinate based on the schedule, task C will not be able to take advantage of any earlier finishes — this is especially true if there are different teams used in the different tasks. So, in many projects, task might be late, but never early (we don’t even have to get into the psychological impact of “having more time”).
What about that 50% version? If we use the 10 days each for the tasks, we would get a 30 day project… a 23% improvement in duration. Of course, we can’t expect that we will make this schedule. On the other hand, what is more important — reliability or speed? If we schedule a 39 day project, what are the odds we’ll finish in 30 days? In my experience, it’s so close to zero that it is zero… If we schedule for 30, we may make it very few times, but it’s not zero. We at least have a shot!
Next time, we’ll look at this a bit more — including some additions AND obstacles with this idea.
Hi Alan,
Enjoyed your 90% article especially your analysis of why the big guys appear to be slower. You brought out some excellent points which I have also experienced. However, someimes the turtle beats the hare, especially when doing it slower means doing it right the first time, which is certainly not always the case.
There is a typo in your schedule description where it is stated that C=1 day but is shown to be C=13 days. Also I think it is important to point out that if you add the three 90% confidence tasks, the total project duration of 39 days is at greater than 90% confidence because you can’t add task variances directly. The varaiance of the total project is the square root of the sum of the individual variances and not the sum of the square root of the individual variances. I know this gets too mathy, but many of my students think you can add three 90% confidence tasks and you end up with a 90% confidence project duration. The math says this is not true. As you know, this fact is used in critical chain project management to shorten the task chains while maintaining the same confidence level of the individual task durations and also to calculate the various chain buffers.
Thanks, Frank!
Yes, it sometimes feels too “mathy.” On the other hand, a simple spreadsheet can do the mathy stuff.
I’m still planning a post on this issue of path versus task level confidence (but it’s still too mathy!).
The other issue is how, if we want to use the statistical variation concept that would allow a high confidence plan at less than 39 days, we would have to manage/lead/think at the path (chain) level — rather than merely at the task level.
Oh, man, one of my favorite PM topics! Thanks for writing this, Alan. I think it is really important to consider the 50% and 90% confidence estimates, but ever since Microsoft Project was invented, leaving only one little box for the duration estimate, people forgot that “in the old days” we had “best case”, “worst case”, and “most likely”, and took some kind of average. The range is a great indicator of risk, as you’ve pointed out to me in the past in our work together. In most companies schedules are just part of the big “lying game” that PMs play with executives.
I wrote an article for http://www.projectconnections.com way back when I published my book “Scrappy Project Mangement” http://www.amazon.com/o/ASIN/1600050514/ ranting about this topic. Here’s an excerpt. http://www.projectconnections.com/articles/070606-wiefling.html for the full rant.
In my experience, the most significant preventable causes of unachievable schedules are:
* Human brains are lousy at making estimates.
* Bottoms up scheduling methods give too little attention to handoffs and integration points.
* Executives and project teams engage in “The Lying Game.”
* Teams wait until the schedule slips before intervening.
* Lessons learned from previous project AREN’T!
Kimberly!
Thanks for your comments on my posts. I am, of course, a big fan of your Scrappy PM approach. Probably a good thing that there are still places where going beyond “conventional” isn’t yet happening… more things for us to do!
alan