Software Project Phase 1.1: Drafting the Project Plan

Posted on: April 18th, 2009 by Johan van Seijen No Comments

Let’s see, what can I say about project plans with­out bor­ing you to death and cov­er­ing the main points any­thing but suc­cinctly, because that’s what project plans usu­ally do. There’s a whole lot of hot air in for­mal doc­u­men­ta­tion, project plans being just one instance, where you have to read through gen­eral infor­ma­tion you prob­a­bly know already. The real impor­tant stuff remains hid­den because of that. That’s why, when I have to make a project plan, I don’t incor­po­rate any­thing more than what’s absolutely nec­es­sary. Nonethe­less a project plan is a very impor­tant doc­u­ment peo­ple treat as yet another copy-paste doc­u­ment. If you approach this sub­ject with an atti­tude of indif­fer­ence there not only will be a whole lot of fluff but far worse, plain wrong infor­ma­tion in the doc­u­ment. If that’s the case you shouldn’t make the damn thing at all.

“I received a thirteen-page project plan a cou­ple of weeks ago. Closer inspec­tion revealed it to have just five pages of remotely rel­e­vant infor­ma­tion. I can live with that, but the plan came after the soft­ware design was already dis­cussed, a scope agreed upon, a dead­line set and a start with imple­men­ta­tion was under way.

In other words, the plan was long over­due. Now I’m begin­ning to get less enthu­si­as­tic with over­due fluff clut­ter­ing my mail­box. Then I started review­ing the thing and you can guess what the out­come of that was. Another exam­ple to rein­force the gen­er­al­iza­tion of project man­agers in a neg­a­tive way. That’s bad news. The plan did more harm than good because it was plas­tered with those thing you hate step­ping into.

It reminds me of an inter­view “Stone Cold” Steve Austin, the WWF wrestler, had with George Stroum­boulopoulis dur­ing his talk­show The Hour. He’s got a remark­ably sim­ple atti­tude towards life that brought him places. When dis­cussing his child­hood grow­ing up at one time he men­tions to George some­thing his dad taught him. He says his father told him:

“Steve, if you gotta do some­thing, 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 irri­tated because the project plan was lousy, it’s was because I knew the one mak­ing the thing could have done a much bet­ter job if he’d com­mit­ted him­self, but he choose not to do so. How I know such a thing? I don’t, but when somebody’s that late with deliv­er­ing a prod­uct he’s sup­posed to be respon­si­ble for after I had dis­cussed it with him, telling me he’s so busy. And then just deliv­ers 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 hel­luva 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 fol­low­ing subject’s  should be covered:

Busi­ness Case

  • Tech­ni­cal conditions
  • Project risks
  • Project goals
  • Time and costs

Soft­ware Project Phases

  • Characteristics
  • Milestones
  • Indi­vid­ual phases

Plan­ning

  • Project phas­ing with timelines

Related posts:

  1. Soft­ware Project Trait #7: Project Iterations
  2. Soft­ware Project Trait #1: Hall Stand
  3. Soft­ware Project Mile­stone #1: Scope Determination

Leave a Reply

You must be logged in to post a comment.