“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.