Several of my clients claim they have plans. But I don't see the elements of a plan in what they do. Instead, I see wishes that the future will unfold in a particular way.
I also have wishes. But the more we confuse them with plans, the less likely we will get the future we want. It's time to change from wishing to just enough planning.
Examples of Wishes for the Future Instead of Plans
Jim, a project manager, asked me where he should put his risk list. “I don't have any planning documents because all of our plans are in the backlog or the roadmap. But the risk list helps me look ahead a little, just to make sure I'm planning for the future. How do I expose that so the entire team can be aware we have risks?”
Cindy, a product manager, asked about alternate paths through the roadmap. “I'm supposed to make a quarterly roadmap for the next year or so.” She shook her head. “But I know things will not turn out the way we want at some level. And there are things I want to experiment with. How do I put that on the roadmap?”
In the same vein, Susan, a VP of Engineering, said, “We continue to plan the portfolio as if we are not going to change anything for an entire quarter.” She chuckled. “That's better than an entire year, but we still need to react when a triggering event occurs. How can I help my peers realize we need to look out for those triggering events?”
Jim, Cindy, and Susan are all talking about seeing and then managing risks. Risk management is why we have plans.
Plans Include Risk Management
When teams first started to experiment with agility, they realized things had changed:
- It was possible to deliver software without the need to literally package it in the form of a hard drive or a box. (Not all software, but much of it.)
- The more often the team could deliver software, the faster they could see the effects: the good (what customers wanted), the bad (what customers did not want), and the ugly (defects or other problems).
If the team delivered software daily, the team could react fast, without needing too much risk management.
However, most teams had to manage the previous choices that either they or their predecessors had made. Most of those decisions led to cruft, real technical debt, or insufficient architecture for new features.
What was the answer? Too often, the answer was “Put those new features on the backlog or the roadmap. Or add a new project to the portfolio.”
That's not risk management. That's kicking the can down the road and hoping that the can is not hiding an explosive device.
Hope is not a strategy. We need plans with risk management, roadmaps with experiments (those alternatives), and criteria to choose when to evaluate the portfolio.
Plans don't need to be big—and they do need to exist.
How Small a Plan Can You Create?
In Manage It! Your Guide to Modern, Pragmatic Project Management, I offered two key ideas that I continue to advocate:
- Apply the idea of “how little” to everything, including plans and planning. That's because we have no idea what will happen until we start the work and try to deliver. Why plan for longer than we need to?
- Understand what done means and the risks to achieving that done state.
The idea of “done” is easy for projects—that's the release criteria.
However, a product roadmap is a different beast. First, because we expect to need several releases (or projects) to be able to solve the problems the customers have. In addition, we might want to know when to spin off a new product. Or, we might decide to cancel this product altogether. Both a spinoff or a cancellation are triggering events for new decisions.
The project portfolio also requires triggering events for new decisions. How much do we invest in a given project before we choose again for the project portfolio? When do we choose to merge several teams—and/or their backlogs—to create a program or a new product? Do our strategy changes require a new portfolio?
The risks are different, so our planning needs to be different.
Plan According to Risks
Projects are a single effort with specific risks. We can use a project plan, possibly with an integrated risk list or a pointer to that list.
But product roadmaps have many assumptions about the customers and their problems. How do we show the various risks? (This is why I prefer to use Flow-Based Agile and Lean Roadmapping, with the big black line that defines the minimum, with more options below. Add a one-pager about the customers and assumptions, and triggering events for new planning. That allows the organization to have a small enough plan for the roadmap.
How often should you choose again for your project portfolio? That depends on where you are in your organization's growth and the various product lifecycles. The more you want the organization to grow, the more often you need to rethink the project portfolio. And if you're experimenting with new products, the more you need to choose when to cancel a product and update the portfolio. I explained about the possible triggering events for new portfolio decisions in Manage Your Project Portfolio.
But here's the real issue: If we do not acknowledge risks, we are wishing, not planning.
Plans Help Create the Future We Want
When we acknowledge risks, we can plan for them. That might be as low-key as recognizing them. Or we might want to take more pre-emptive action to make sure we avoid these risks.
But if we do not acknowledge—and write down—the risks, too many people think that the project, roadmap or portfolio will “just happen.”
Nothing “just happens.” Not a project, and definitely not wishes. We have to work to make them happen.
Consider how little planning you can do to create plans for your projects, roadmaps, and portfolios that allow you to see and manage risks as you proceed. Because all useful plans include risks.