Building Success: Developing a Project Plan
I hate projects.
Or to be more precise, I hate the word “project.” I hate it because it’s completely wrong for what it describes. A “project” is something finite, something with a start and an end, something you can get your hands around. But as you and I know from years in IT, technology projects are rarely as finite, as simple or as simply controlled as people think. What begins as a small project often turns into a large one. What begins as a large project often gets huge. And what begins as a huge project can become, without safeguards, a juggernaut.
Part of that is poor management. Part is just a simple truth about work: Left unchecked, it expands to fill up available time. In the rarefied world of project management, this is called “scope creep,” the subtle way that projects grow larger, often unnoticed, by the day. And the best way to fight scope creep—in fact, the best way to make your project a triumph—is to write a flawless, fabulous, perfect project plan.
Too bad it doesn’t exist. Show me a project plan, and I’ll show you a lie.
It’s not that project managers, IT directors, software engineers and other plan-writers want to deceive people (including themselves). But planning, by its very nature, is imprecise and prone to error. It’s hard enough to estimate the time you’ll spend on a single task in a day. Expand that to hundreds of tasks by dozens of people—some in different time zones and different countries—and you’ve got a flat-out foray into the unknown.
Yet for all my fuss and fury, for all my curmudgeonly rhetoric, it’s true that good project plans do exist. In fact, some of them are very good, and they follow common sense rules that you won’t find in books.
Most plans suffer from a single, common mistake: They’re too ambitious.
It’s human nature: At the start of a project, we’re eager, excited and ready to roll up our sleeves. We want things to happen, and the more the better. We have a vision of the future that’s got every bell and whistle you can think of.
But planning is simpler than doing. It’s easy to write some dates on a piece of paper, but much harder to hit those dates as real—and reasonable—deadlines. Whether it’s Murphy’s Law, O’Toole’s Commentary on Murphy’s Law (“Murphy was an optimist”) or even Harvard’s Law as applied to computers (“Under the most well controlled conditions of pressure, temperature, volume, humidity and other variables, the computer will do as it damn well pleases”), life has a way of making hash out of big, grand plans.
So the next time you write up a plan, make it simple. Limit your goals to things you know you can do with the time and money you have. Try, in the words of a sage manager and former boss, to hit a series of ground balls, and not a set of home runs.
Above all, plan for more than just the work at hand. Plan for what you’ll have to overcome to do the work at hand—the risks and problems you’ll face.
Who knows what the future holds? In writing your project plan, make risk management an integral part. It’s something that most project managers do as a matter of course, but something that techheads, eggheads and other code junkies like you and I often forget.
It’s also simple. First, list the risks you know about now. Maybe you could run out of money. Maybe there’s a contractor you don’t trust, and you’re not sure that he’ll deliver on time. Whatever the risk, write it down, then write out the steps you can take to avoid it before it happens, so it’s never a problem.
Next, build time into your plan for risks you can’t foresee. It’s called a cushion. If you’re doing a simple, stable project, add 10 percent to the time estimate for every task. If you’re doing something new or unknown, double the estimate. That may sound extreme, but it’s saved more than one project—and career—from disaster.
And last, let the people who do the work do the estimates. It’s a piece of common sense that too many planners ignore to their peril. But good planners let worker bees whose knowledge is often ignored give them a range of time for each task, and as a result, their plans have a range of times to completion, along with a margin of error—the cushion—that gives them some breathing room.
Not Just A Timeline
Speaking of timelines and cushions, remember that good plans are more than mere schedules. In fact, when they’re done well, plans can be highly detailed, with a mission statement, a statement of scope, a timeline (or many timelines, some with sub-timelines), a list of stakeholders and a communications plan. Or to put it more simply, they’ll cover the who, what, where, when and how of a given project, and carefully.
But as you aim for completeness, don’t forget that brevity—and simplicity—are godsends. Be sure to include the items above, but don’t be wordy or boring in writing them up. If nothing else, a little direct language will help people read what you write, and the more they do, the more you’ll be in sync.
Plan to Talk
Too many projects wither and die when the team stops talking. No matter how much you plan, your project depends on open, frequent communication, so work that into the plan itself.
How? Just answer these questions: Who reports what, to whom, and when? If a problem happens, who brings it up? How soon? In what medium? Will you use e-mail, voice mail, an intranet or all of the above? Will you write memos (which, by the way, few people read)? Will you have meetings (which, by the way, can be the enemies of projects because, with few exceptions, they keep people sitting, hence keep them from doing)? If you do plan on meetings, when, where, with whom, and for how long will they be?
The point it simple: Make talking—and talking about problems and progress—a part of the plan itself. Give it structure—make it a system.
The Statement of Scope (And the Not-to-Do List)
Scope is what you’ll do on a project and what you won’t. It’s the project manager’s term for a precise list of what you’ll produce, make, achieve, write, build or break apart. Scope is what happens, and scope is what you’ll get done.
So as part of your next project plan, include a good statement of scope: a page or two that defines what you’ll deliver by the end of your project. It should explain what you’ll do in depth and where the bounds of your work will end.
In fact, what you won’t do is often as vital as what you will—and it’s a point that project managers, even the pros, can overlook. Your plan should help you avoid scope creep, so go to pains to point out what features, functions, actions or tasks you won’t do as part of this project, and make it a clear part of your statement of scope. Or to put it more simply, when you write your to-do list, write a not-to-do list, too. And make sure it gets read.
The John Hancock
Speaking of reading, you want your team members—not to mention your boss—to read your plan. All too often they don’t, and project managers write up gorgeous plans only to see them languish on desks, gathering dust.
To avoid this, have your team members, your boss and any corporate Bigfoot with power over your project sign a copy of the plan. Simple initials will do. If nothing else, the mere act of having them sign will force them to read your plan—and that can save you time, money and headaches down the road.
The Magic of Metrics
You also need a way to measure your project’s success, since fabulous projects are often called failures.
Let’s say you plan to rebuild your Web site. You gather the stakeholders in a room and listen to their rants. You ask them for their opinions and make a list of features they want, you write up the content they need, and you listen to their needs. Over time, you build a flawless site and post it online—on time, on budget and without errors, to the let