“Project management?\u00a0 That’s just a lot of useless overhead!” \u00a0 I remember hearing variations of this a lot years ago.\u00a0 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.<\/p>\n
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?\u00a0 When we were a startup things seemed to go much faster — and we didn’t even use project management!”<\/p>\n
Upon digging a bit deeper, it turns out that there are a few things to consider.<\/p>\n
Some of the slowness was a perception due to having more formal procedures (and the documentation surrounding those procedures).\u00a0\u00a0 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.\u00a0 Some of these meeting were “needed” because so many different groups of people were involved.<\/p>\n
Some of the “slowness” is really due to the fact that the big company project is often creating a product that is more “polished.”\u00a0 The engineers would admit that in the “old” days they would celebrate success with a product not quite ready for commercial release.<\/p>\n
So, some of this “slowness” is about some of the things that come with being bigger.\u00a0 We can talk about ways some innovative organizations overcome these issues some other time.<\/p>\n
Looking at this big company “friction” or overhead still did not seem to account for this slowdown.\u00a0 Could it be that project management really is an insidious overhead?\u00a0\u00a0 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.\u00a0 So, we deal with these items by doing a project management well.<\/p>\n
On the other hand, there is something that seems to slow projects down by design — schedules.<\/p>\n
How can that be? \u00a0 Let’s start with those unrealistic schedule first.\u00a0 You know, the ones that aren’t really set through a rational process of estimation, but rather a target meant to “push” people.\u00a0 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.<\/p>\n
How about those realistic schedules?\u00a0 They are based on rational estimates and good statistics based reasoning.\u00a0 It’s not uncommon to have a policy of 90% — that is, give me an estimate with a 90% probability of being met.\u00a0 This sounds pretty good, yes?<\/p>\n Let’s use this as an example.\u00a0 A = 12 days, B = 14, C = 13, where each estimate is at\u00a0 90%. 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\u00a0 50%, we add buffer until we get to 90%.<\/p>\n![\"scenario](\"https:\/\/svapm.org\/wp-content\/uploads\/s11.png\")
<\/a>
\nSo, the project = 39 days.\u00a0 Can we say that we have a reliable schedule?\u00a0 Maybe.
\n.
\n.<\/p>\n<\/a>