Clarify the fuzzy front end of project planning by focusing on the overall vision. In this column, Johanna Rothman says clear project vision helps everyone involved in the project move forward better and more smoothly than a detailed project schedule. She also explains how to write succinct project visions in three simple steps.
If you've ever planned a project, you know how hard the initial planning can be. There's a reason we call the start of the project the "fuzzy front end." Some project managers give up on the planning altogether and dive into details hoping that a plan will evolve.
It's possible to generate a plan that way, but I've found it easier to develop a project vision first. That way we don't waste time on work that doesn't need to be completed.
I use the project vision in two ways: to communicate to the technical staff why we're working on this project and to verify with management what they'll get out of the project.
Here are two potential project visions. Which one would you rather work on or fund?
- Release 3.4 is to clean up the mess from the last release.
- Release 3.4 is to reduce technical debt and improve product performance.
Both statements are true and refer to the same project. However, the first statement is blaming the Release 3.3 staff (who are the same staff on Release 3.4). The second statement acknowledges the shortcomings of Release 3.3 and gives the staff two reasons to work on the project: completing their earlier work and improving the project.
Project visions are important for new products too. Here's an example:
- Project NewQuant helps people calculate.
- Project NewQuant will change the way people make comparisons of non-quantifiable items. With Project NewQuant, people will be able to validly compare apples and oranges.
Some project visions are lackluster like the first one—"helps people calculate"—and then there are compelling visions, which is what the second one is to me. We may think the second vision is impossible or something we don't want to fund, but at least we have a description explaining why it's useful.
Once you have a project vision, you can test it with the sponsoring management and technical staff. With management, I can ask questions such as:
- Is this what you thought you were buying?
- Does this look like success to you?
- Does this vision create any problems for you or for us as a company?
The vision helps me verify that senior management wants to fund what I think they want us to build.
The vision helps the technical staff see risks—risks that might change how you organize, staff, or steer the project. With the technical staff, you can ask:
- What kinds of risks do you see on this project?
- What kind of people do we need for this project?
- Is there something about this project that you already know that I don't?
When you ask the technical staff about the project in the planning phase, you're more likely to discover problems you didn't know existed. I especially want to know about risks, such as "We need Fred. Fred is the only one who can do this. And Fred's tied up on that other project over there until next spring." Armed with that information, I can choose to: postpone the project; obtain some Fred time; or have Fred train some of the other technical staff, so Fred's not on the critical path.