Pragmatic Project Management Behind Closed Doors: Secrets of
Great Management Hiring the Best Knowledge
Workers, Techies & Nerds Corrective Action for the
Software Industry Amplifying Your Effectivess Speaking Calendar Testimonials Resume Contact
Plan Perfect
by Johanna Rothman. This article was originally published in Software Development, May 2003.
Don’t depend on a work breakdown structure to keep your project on target: Write it out to help managers, team members and stakeholders find consensus.
“I can’t get senior management to agree on what I think the project is supposed to do,” a project manager recently complained. “The developers don’t believe me when I tell them our milestones, the testers are behind, and no one’s paying attention to my plan.”
I asked to see his plan, and he showed me a WBS (work breakdown structure). I then asked if he had a plan written in words, or just a schedule. “Just a schedule?” he replied. “I sweated bullets over this—it’s not just a schedule!”
Oops—here’s a smart project manager trying to work the critical path to keep the project on track, and he’s stuck, dangerously unaware of the benefits of The Plan, otherwise known as the project charter: a brief, natural-language explanation of the project. This planning document defines the project’s reason for being, and is the vehicle that defines agreement among all involved parties, describing the way the project is managed, and how decisions about it will be made.
The plan contains at least some of these elements:
- Project vision: Why the project exists.
- Project requirements: The minimum you must accomplish. You use project requirements to define how to make trade-off decisions. For example, you might have a requirement to “ship some stuff by June 1, so we can make revenue from this release.” The product requirements may be vague (“some stuff”), but the deadline is crystal clear (June 1).
- Project goals: What you’d like the project to accomplish.
- Success and/or release criteria: What success looks like, or the criteria by which you know you can release the product.
- ROI (return on investment), if you calculate it.
- Project organization: This includes personnel start and availability dates, and lifecycle type. Depending on your organization, you may include factors such as which practices you’ll incorporate when; if you’ll develop an architecture and how you’ll review it; how you’ll accomplish peer reviews; the length of your iterations and so on.
- Risk list: Include those you can anticipate and the ways you’ll handle them.
Some project managers also include a list of major stakeholders, delineating who makes which decisions and how, and who has the power to veto those decisions.
Iterate and Schedule
When I manage projects, I iterate on the plan and schedule at the very beginning. As I write the plan, I circulate the draft to team members and project stakeholders for discussion. I draft a schedule, especially if the project is particularly schedule-bound, and I use the feedback to refine it. Then, I create a final plan that has at least a prayer of meeting the desired schedule.
Why write a plan? For any project that requires more than two people and one month, a plan helps others remember why you’re working on the project and what your deliverables are. When someone insists, “Come on, just slide this one feature in,” you can whip out your project plan, review the project vision with the requestor and say, “That fits—I’ll see what I can do,” or “That doesn’t fit with our project vision—you remember, the one you agreed to. What’s changed? Tell me more about this request.” Armed with this proof of consensus, you’re in a better position to discuss the merits and risks of new features.
Requirements vs. Goals
I use the plan to differentiate between project requirements and project goals: Requirements are what you have to do, or the project isn’t valuable to your management, your customers or other stakeholders. Goals are the things you want to accomplish if you can.
I’ve worked on commercial product projects with requirements so fuzzy I mistook them for slippers: “Get this version out by June 1. Put enough stuff into it so it’s a major release and we can charge money for it.” Another IT project’s requirements were simply “Transition to this payroll system by October 1, or we’re in trouble with one of the three-letter-acronym organizations.” In each case, the release date and some specific features were the requirements. Those requirements contained other implicit requirements, but everything else was only a goal.
Having a plan helped the entire project team differentiate between requirements (“Transition to this payroll system by October 1.”) and goals (“We’d really like to show accumulated sick days along with accumulated vacation days on the pay stubs.”). In previous projects, the team was willing to take on new features without considering their impact on the project. With the firm requirement “Transition to this payroll system by October 1,” the project team could tell when they were straying into project goals. Using the project plan agreement as a way to discuss who was performing which tasks when, we made our deadlines.
Plan components can help you deal with fuzzy requirements. For example, if you can agree about the release criteria at the beginning and manage the project to those criteria, documenting this in your plan, you don’t need to endure subsequent shouting matches to release early. Just say, “We haven’t met the release criteria yet as agreed. If you want to release before we meet the criteria, here are the risks.” Then you can discuss the risks, instead of endangering your eardrums.
Getting Organized
Project organization is another vital plan element. One difference between a successful and failed project is personnel availability. When you’re discussing your plan with project sponsors, offer a few alternatives depending on staff availability. If you have a few people available at the onset, with more people signing on later, perhaps a spiral lifecycle is appropriate. If you have sufficient staff available at the onset but are pressed for time, you might want to use a staged delivery lifecycle. If you have enough people and the requirements are nowhere near stable, an agile method might be the best choice. Remember, when you select an approach, you can also choose how to organize your personnel. If you’ve made your decision but don’t yet have all the necessary personnel when you need them, it’s worth documenting various options in your plan.
I include the top few risks in my initial project plan, mainly so my sponsors can see that even at the beginning, there are things I can’t control. Sometimes, because of the plan, my sponsors even remember those risks later on when I explain how the project has hit a bump in the road—and what I’m doing to navigate that bump.
I’ve found that a plan can be an invaluable aid in project management. It doesn’t have to be a three-volume novel—just long enough to help your sponsors and the project team understand the project’s goals, needs, risks and direction. Don’t make the mistake of thinking that a WBS is sufficient—it’s not. Start your project with words, not just symbols, and you’ll have a much better chance of success.
Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.