Problem solve Get help with specific problems with your technologies, process and projects.

Tips for creating software project plans

How do you determine how much detail should go into a software project plan? Site Expert David Christiansen has some suggestions.

I'm starting a new project soon. It's quite a large project, at least 18 months. I need to create a project plan for it, and soon. How much detail do I put in the plan? Should I put the same level of detail into the plan throughout the whole 18 months? Do I have to wait for the whole plan to be "complete" before we start working on the project?

I sometimes think of planning and not moving as the same thing, at least if you stop moving in order to plan. I prefer to plan on my feet -- get things rolling, evaluate direction and adjust. Then roll along for a while and do it over, and keep repeating until the project is complete.

Does this approach make you nervous? I know firsthand it makes many managers nervous. They want to see a project plan from beginning to end, even if the plan you're showing them is based primarily on your imagination. Somehow the project plan that shows the whole road from initiation to close out just makes them feel warm and fuzzy inside. Not me. When I look down a project plan to the "horizon," I can almost see the probability of missing dates increasing the further out they are, like mountains rising over the desert in the distance. It's just too complicated.

Here's the simple truth about managing software projects: The probability of missing a date grows exponentially the further out the date is. Why? Because of all the factors that cause variability in a software project. The longer you are exposed to them, the more they accumulate.

So how can you deal with this? The answer is pretty simple: Don't build monolithic plans. Adjust the level of detail based on how far out you're looking. You should always have a very detailed plan for the next two to three weeks. It's a very reasonable thing to know exactly what's going to be done in that sort of timeframe. That's the range where you can make reasonable predictions about what will take place.

Activities that are more than three weeks out but fewer than three months away should be planned in a general sort of way and should seem more like goals. "Start UAT the week of August 1," for example, is one that you can shoot for. Pin it down to a more accurate date once it falls in the three-week range. Don't break it down into a detailed task list though, at least not until it comes close to the three-week window.

Anything more than three months away should have an extremely general timeframe with a fairly broad range associated with it (like "Go live sometime in October." I prefer to avoid putting dates on these at all; it makes more sense to me to just list them in the order we're going to do them and then get there as fast as we can. That is almost always impossible though, so give it a broad range instead. Once these activities fall in the three-month window, you should start to plan them.

Dig Deeper on Topics Archive