Reply to: Writing a plan

[Doggy Styles]

Red, Yellow, Green?

That's gaudy. I prefer pastel themes.

[Ignis Fatuus]

Project plan slipping, so client tries to improve it by having more meetings. Now 2 per day at 1 hour each with everybody there. Could spend that time working.

Yesterday the 2 client people kept all the real workers sitting there while they discussed whether the latest planning spreadsheet should have Red-Yellow-Green when there are only really 2 possibilities, it's OK or it's not OK.

[NickFitz]

To my mind, a good plan is a concise document that says;
- what's going to be done
- who's going to do it
- when and where are they going to do it
- when do we decide the job is done

I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.

- Rudyard Kipling

That's why the cakes are exceedingly good

[Spacecadet]

So you want us to first write a long document at your expense, have it reviewed and rewritten at your expense, and THEN comprehensively screw everything up at your expense?

yes yes and **** yes

if the client pays me to write a huge amount of documentation, reviews and signs off that documentation then it's their own ******* fault when it goes tits up

As for your original point, long documentation isn't a plan, its a requirements and design specification which should have been factored into the original 2 page plan.
Checking with the business what they actually need/want isn't always a bad idea and separates the IT pros from the bum on seat coders.

[Muttley08]

The plan is about getting agreement on the 'How' I'm going to do it - the schedule, resources etc. are more dynamic for me, whilst you need to have them, separate docs etc are fine (and don't do war and peace as it will change!) It's all relative to size of project, how many other parties, need to co-ordinate them etc. etc...

However, particularly the public sector are more than happy to pay you to plan for months, when we all know its going to change. Real delivery is about managing people and reacting when things go wrong - but hey ho if they're happy to pay!

[norrahe]

I recently took over a project, when I asked for a plan off the former PM the reply was, "what plan?"

[darmstadt]

I remember writing a plan once, it actually took 6 months although I had finished it in about 2 (it was a big project.) This was due to such as issues as amount of space between lines and paragraphs, format of the index, this chapter should be here and that one there. As it was I did the project my way without recourse to the plan, much, and it went perfect. Mind you, a current project has no plan it's going tits up and I've been trying my hardest to do a runner (I don't even have a contract not even a bit of paper saying what I'm meant to be doing) but doesn't seem to be happening

[Doggy Styles]

A plan needs to be flexible, so the less detail you stick in it up front the more flexible it is.

Except cunning ones of course.

[MrGrunge]

Why in todays connect everything to everything software world; is that after so many docos, meetings and initiatives; there is so little of concrete plan about non trivial software development?

[Mich the Tester]

We have plans to prevent you enthusiastic amateurs from JFDI'ing it and screwing everything up in the process.

So you want us to first write a long document at your expense, have it reviewed and rewritten at your expense, and THEN comprehensively screw everything up at your expense?

[Svalbaard]

Yes.

Plus, all this other methodolgy guff is perpetuated by academics, self-appointed 'Professional' Societies and training companies to generate income.

Now, give me the keys to the computer room, the root access passwords and the magic box of spare bits and let me just get on with it?

We have plans to prevent you enthusiastic amateurs from JFDI'ing it and screwing everything up in the process.

[Alf W]

To my mind, a good plan is a concise document that says;
- what's going to be done
- who's going to do it
- when and where are they going to do it
- when do we decide the job is done

So why does every company larger than about 3 people insist on using templates for 'test plans' and 'detail test plans' which comprise about 35 pages BEFORE any meaningful content has been added?

Why do we have to fill in all sorts of superfluous crap about methodologies that nobody really uses, standards that no sane person really applies, plus document history, distribution lists, template history, endless references to other documents and so on and so on, thereby meaning that writing and maintaining the 'plan' actually takes longer than making and delivering the bloody product, which is mostly an admin system upon which precisely zero human lives rely?

Is it just a means for some 'consultant' type to maintain the outward show of professionalism while actually producing nothing of value?

Yes.

Plus, all this other methodolgy guff is perpetuated by academics, self-appointed 'Professional' Societies and training companies to generate income.

Now, give me the keys to the computer room, the root access passwords and the magic box of spare bits and let me just get on with it?

[MarillionFan]

I love it when a plan comes together!

[Mich the Tester]

A template in itself isn't bad, as it checks you've not missed anything obvious and forces a consistent structure that can be read more easily than every project being totally different.

But I'm with you, the template itself should be pretty empty.

Yep, I see the value, but it should help in making a concise plan, not encourage the making of long documents for the sake of subsidizing the paper industry.

[d000hg]

A template in itself isn't bad, as it checks you've not missed anything obvious and forces a consistent structure that can be read more easily than every project being totally different.

But I'm with you, the template itself should be pretty empty.