Let’s see, what can I say about project plans without boring you to death and covering the main points anything but succinctly, because that’s what project plans usually do. There’s a whole lot of hot air in formal documentation, project plans being just one instance, where you have to read through general information you probably know already. The real important stuff remains hidden because of that. That’s why, when I have to make a project plan, I don’t incorporate anything more than what’s absolutely necessary. Nonetheless a project plan is a very important document people treat as yet another copy-paste document. If you approach this subject with an attitude of indifference there not only will be a whole lot of fluff but far worse, plain wrong information in the document. If that’s the case you shouldn’t make the damn thing at all.
“I received a thirteen-page project plan a couple of weeks ago. Closer inspection revealed it to have just five pages of remotely relevant information. I can live with that, but the plan came after the software design was already discussed, a scope agreed upon, a deadline set and a start with implementation was under way.”
In other words, the plan was long overdue. Now I’m beginning to get less enthusiastic with overdue fluff cluttering my mailbox. Then I started reviewing the thing and you can guess what the outcome of that was. Another example to reinforce the generalization of project managers in a negative way. That’s bad news. The plan did more harm than good because it was plastered with those thing you hate stepping into.
It reminds me of an interview “Stone Cold” Steve Austin, the WWF wrestler, had with George Stroumboulopoulis during his talkshow The Hour. He’s got a remarkably simple attitude towards life that brought him places. When discussing his childhood growing up at one time he mentions to George something his dad taught him. He says his father told him:
“Steve, if you gotta do something, do it right the first time so you don’t have to come back and do it again.”
I life for that kind of logic. I didn’t get irritated because the project plan was lousy, it’s was because I knew the one making the thing could have done a much better job if he’d committed himself, but he choose not to do so. How I know such a thing? I don’t, but when somebody’s that late with delivering a product he’s supposed to be responsible for after I had discussed it with him, telling me he’s so busy. And then just delivers crap to be done with it, I have a gut-feeling about what’s going on, because at times I’ve been doing the exact same thing. Recently I’ve done a very lousy paint-job on the house because it took me a helluva lot longer than I wanted it to. And guess what, now I have to do just that thing Steve’s dad warned him about. I have to come back and do it again.
To give you an idea about what a good project plan should look like, the following subject’s should be covered:
Business Case
- Technical conditions
- Project risks
- Project goals
- Time and costs
Software Project Phases
- Characteristics
- Milestones
- Individual phases
Planning
- Project phasing with timelines
Related posts: