Often one of the first things asked for when starting a new project is a plan. At a state where nobody exactly knows what we'll have to do and who should be on the team, they want a plan that fixes a release date somewhere next year.

Obviously this doesn't work. But telling them they won't get no plan at all doesn't work either. So what to do? I think one of the keys to a useful plan (actually for every useful document) is to determine who is going to read it and what it can or should do for the reader.

So here is a list of things a plan can do for you or other people involved in the project plus some properties your plan should have in order to fulfill this purpose:

Basis for Go/No Go decisions. This happens early in the project or actually before the project, depending on your definition of project. For this the plan should state: What the project will cost, and what the expected ROI will be (Note: ROI is not a single dollar amount but a function of t -> $). AND it must state a measure of confidence in the plan. If you make any kind of decision based on a plan without understanding the intervals of confidence you are playing lottery. Also note, the intervals of confidence will always be asymmetric. While it is not seldom that a project will end up twice as expensive as planned, it very seldom happens in no time at all.

Basis for coordination. When all you have to do is queue up the tasks in the project an finish them one after the other, there is not much use for a plan. But if you have dependencies between the tasks things get interesting (and ugly). When your infrastructure team need three months for ordering and setting up the production machine, you better order it three four moths in advance. This of course means you have to know your going live date that much in advance. If you don't have such dependencies, you don't need the plan. Actually when people get introduced to MS-Project they start drawing lots of dependencies between tasks because it is so coool when MS-Project moves the tasks around based on these dependencies. But they go completely unaware that every dependency is a problem waiting to happen. Therefore dependencies should get minimized.

Thats it. I don't think there is anything more to it. Of course you have to redo your plan constantly in order to realize when the basis for a decision is about to disappear, or when some kind of coordination won't work as anticipated.

But there are also things plans are getting used for although they aren't good tool for it:

Getting things done / Motivating people. Just face it: It does not work. Just because you write down that I have a day for a task doesn't make it more likely that I'll get it done in that time.

Not forgetting stuff You don't need a plan for that, you just need a list. Oh and when you prioritize that list you pretty much have a backlog, isn't that nice?

Yelling at people You are the boss, you can yell at whom you want as long as you don't care that it demotivates them. You don't have to screw up a plan to do that.

Anything I forgot? Let me know. Thats what the comments are good for.