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.
Looking Ahead
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.
Seeing Eye-to-Eye
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.20/20 Vision
I use these steps to define the vision:
- Define who the primary customers of the project are. They could be the mass market, existing customers, new customers, or a specific market segment. For the Project NewQuant example above, people who need to compare different things are the primary customers.
- Define the one major focus of the project. This could be a specific feature, or the general approach. If you're new to agile and you're starting a pilot project, you might want to say, "Use agile techniques to see how to adapt them here." In the Project NewQuant example, the focus is on the ability to compare previously non-comparable items. Unseasoned project managers can trip over this step if they try to enumerate all the reasons for the project. A project doesn't focus on five things; it focuses on one overall vision. If your project requirements are too broad to encompass in one vision statement, maybe your project is too big.
- Write as much as you need to, and then edit until you're down to two to four sentences. If your vision is longer than four sentences, you haven't described the project focus yet.
A project vision doesn't make it easier to schedule, but it makes it easier to judge how much work is required and when the project is done. Once you have the vision, you can ask the technical staff and sponsors other questions about the project, assess risks, and start creating release criteria. Now you've started the initial planning, which provides more depth and is more valuable to you than a mere schedule.
I thank Esther Derby, Dwayne Phillips, and Keith Ray for their review of this article.
