If it’s a project, plan it.

Seems obvious, doesn’t it?

But it isn’t. I was reminded of this in a recent project postmortem. While the project wasn’t a catastrophe, it was pretty ragged, or so I was told. And when I asked to see the project charter and schedule, and the project manager explained it was such a simple project that he hadn’t bothered to create them, the root cause swam into focus.

The usual thought process about project plans is, the bigger the project, the bigger the plan. It isn’t a bad thought process, either.

What it is is misleading, because it implies that the amount of planning needed as projects increase or decrease in size is described by a straight line, when in fact it’s best described by an S-curve.

The curve flattens out at the far right because as a project (or multi-project initiative or multi-initiative program) continues to increase in size, there comes a point of diminishing returns, beyond which the project manager is simply micromanaging.

In other words, while it can make sense to go beyond “Get dressed” to “Put on your shoes,” and even from there to “Tie your shoes” as the level of task granularity,  going beyond “Tie your shoes” to “Grasp left shoelace between left thumb and left forefinger; then grasp right shoelace between right thumb and right forefinger” means you have the wrong people on the project team.

At the far left, where projects are small and simple? The curve also flattens out, well above zero. There is an irreducible minimum level of planning you should do for even the smallest of projects, for three reasons: (1) Without a plan you can’t be sure you fully understand what’s actually needed; (2) even with a small project, everyone on the team needs to know what they’re responsible for and when it’s due; and  (3) you don’t know it’s that small until after you plan it.

The project in question didn’t suffer from the first issue. It was a software upgrade. Everyone did understand its point and what it was supposed to accomplish (upgrade the software without disrupting the business).

This doesn’t make the issue irrelevant. It means the project manager got lucky. As it happens, there was no desire to look for business advantages from new features the upgrade provided, but there could have been. The project manager should have asked, and would have had he created a charter.

The second issue? You bet. The project in question got messy during testing. (Yes, it can happen … Trust me!)

The reason it got messy was that (another situation you’ve never heard of before) there was no test plan, so everyone involved in testing just banged away on the keyboard until they couldn’t think of anything else to put in.

Which was fine until the time came to cut over to the new system. That’s when the team member responsible for testing got the jitters, and started to think of new tests to run. And more new tests. And more …

The project manager was understandingly unhappy with Testing Guy, but his unhappiness was misplaced. As it turned out, Testing Guy wasn’t a software quality assurance professional, and had no background to understand that there were such things as formal test plans, let alone what a formal test plan looks like.

Which would have been okay had the list of project deliverables included a test plan, or if the task list had included a task labeled “create test plan.” But it didn’t include a test plan on the deliverables list because there was no list of project deliverables, because there was no project charter. There was no appropriately labeled task because there was no project schedule either, because the project was too small to need either one.

That leaves the third and most obvious reason that even the smallest project needs a charter and schedule: Until you have them, you don’t know the project is small enough that it doesn’t need a charter and schedule.

Unless you have an exceptionally well-developed beezer, you can’t determine a project’s size by smell. What you need is a plan — to know what you’re supposed to produce, what it’s for, what it will take to build, and when it’s due. You might then find the project really was too small to plan.

But I doubt it. Even small projects are hard. And the smaller you assume they are, the harder they’ll turn out to be.