HomeCareer Management

Projects are never too small to plan

Like Tweet Pin it Share Share Email

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.

Comments (7)

  • Several decades ago (plus a few more) I learned that without a plan you (almost always) have to say yes (to every hair brained request that is made).

    Which, in this article translates to: “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 …”

    I suspect that the pyramid builders had the same type of issues.

    John Blair

  • Thank you for this article – I needed the reminder. I’ve spinning up a “small to medium sized” project that doesn’t have a project plan yet, but it will now.

  • Bob:

    Beezer? Had to resort to the Oxford English Dictionary (fortunately available online for free from my fine local library) to figure that one out. Thanks for the mental stimulation!

    Good column. I’m going to break down, limber up the credit card, and buy that Bare Bones book tonight. I’ve burned myself some, and been burned by others more, this way so many times you’d think I’d have learned better by now. “You’re never too old to learn….”


  • Bob said “… Time to give back, by sharing what you know. That’s what the Comments are for. Well, that, and for telling me when I’m way off base.”

    Steve says Bob is seldom off base and virtually never way off base. In this column, Bob is right smack dab on base.

    Anyone who has been in IT (or IS or MIS or DP or whatever you wish to call it) for any length of time should know that having a Plan is always the best approach. One would not try to build a house without a Plan. So too in our field.

    — note that I capitalize Plan. Planning is so important that I feel the capital letter is justified.

  • My 12th grade English teacher used to say repeatedly: “If you fail to plan, you plan to fail.”

    Thankfully, I’ve never been able to forget that. Small (sounding) projects might need small project plans, but they always need a plan. No way to get around that if success is on your agenda.

    Great article, Bob.

    -ASB: http://XeeMe.com/AndrewBaker

    (BTW, I saw today’s Dilbert and thought about you: http://www.dilbert.com/fast/2012-08-02/ )

Comments are closed.