Would you run 145 miles from Birmingham to London non-stop for fun? Of course not, but most years about 80 “ultra” runners do just that. They share the loneliness of the long distance project manager. These brave souls running the Grand Union Canal Race risk exhaustion and collapse on some lonely stretch of canal but most of …
Lies, damn lies, and PERT charts
I've had the misfortune to be on a critically understaffed and underbid project, with a project manager who felt that if he just juggled his PERT around, he could make magic happen. Of course, when the chart told him flat out that what he wanted wasn't possible, he "adjusted the truth" - broke dependencies between tasks to allow them to run in parallel, had 5 times the tasks running has he had staff, and of course, the classic "No, I don't like your estimate, so I'm cutting it in half. Now, I've scheduled a meeting on why you never hit your deadlines...."
Like Powerpoint and outsourcing to contractors, PERT is a tool. Used correctly, and if you don't lie to it, it won't lie to you.
However, most managers are far more willing to lie than to accept the cold hard truth.
Bad PM are too common
>>"adjusted the truth" - broke dependencies between tasks to allow them to run in parallel
Oh boy, been there and I've got the scars. This PM didn't like the estimates, so as you said he broke the links between high level design, detailed design and build. When asked if he understood waterfall his comment was, "Well you can always go back and fix the high level design after you finished the build!"
That was one pointy haired boss too many for me. The only good thing was he did get the chop, but we still had a bad project to deliver. And, as usual it was the delivery guys who were blamed.
The key to good project management, is not the software used. The software is only a tool to illustrate what we'd like to happen. A good PM is one who has a good working knowledge of the product or objective, together with a good team of people, a knowledge of his/her suppliers and most of all, contingency. I've seen two types of PM in my time, those who spend all their time continually updating plans (watching the Titanic sink) and those that are overseeing the project, talking to staff, managers and suppliers. A project plan is a prediction of how you'd like the future to turn out, having enough contingency or even doing an FMEA on the plan ensures success in my view.
I guess journalists don't plan projects much
If you're building a house, then you'd better put the walls up before you try sticking the roof on.
However whilst a software development project has some dependencies, typically they're of a different nature. You'll generally find that you have multiple critical paths. That is: a critical path which switches dynamically under your feet. Indeed, one tactic in a software development project is to keep your multiple critical paths close to the same length. Most development dependences are resource-related, not PERT style dependencies.
My view is that plans should be descriptive: they describe where things are today. On a none-trivial project you need a way to know where everything is, and what needs attention today. That's what a plan is really good for.
I've not really come across many project managers who use plans other than to write them for their manager's benefit. I assume this is because my business is fixing broken projects.
On the running analogy....
When I'm running, I have a GPS, so I know precisely where the finish is. I know when I'll arrive and how much energy I'll have burned to get there. My estimates of those values improve as I get closer to the finish. I use that information to give me an unfair advantage over the crawlers.
Version control the files the tools use
Then you can show how the PM has mucked about with the plan, force them to comment and commit changes. Keeps them honest!