.png)
Setting Roadmaps
Next the program leader builds a roadmap of intermediate results, providing clarity to upstream and downstream stakeholders on what will be changing, and roughly when.
A context’s roadmap should be publicly (and easily) accessible across the organization. Make it as easy as clicking a link.
Find Initiatives
Program leaders organize changes that can “move the needle” on the goals, or desired outcomes. But if the prioritized levers also exposed some uncertainty, or some problems to explore, then this exploration should be included in program planning.
Consider the nature of the problem(s) to drive the definition of some Criteria that can spark ideas for research and experimentation. Given the problem, what characteristics would a “good” exploration idea have?
This is where program leaders must assess the uncertainty, to emphasize exploration or driving changes. When uncertainty is high, criteria should invite ideas for exploration. When uncertainty is low, criteria should invite ideas for swift delivery of changes.
Next the program leaders can create (or employ) a system to cast a wide net across stakeholders (and SMEs like asset owners) to collect Ideas. In simple settings, this might just be a meeting with a white-boarding app. In larger, more complex settings, this might warrant an innovation management tool. The project leaders vet these ideas, against the criteria, to narrow down to a set of promising Opportunities, to form a high-level backlog (e.g. epics) for the program. Opportunities are assessed for uncertainty, by listing the open questions and unvalidated assumptions circulating around each one. This gauge of uncertainty is used to steer the evolution of an opportunity into some change initiative for the product.
Initiatives can take the form of:
- an exploration, to validate ideas with interviews or research (high uncertainty)
- an experiment, to test a Hypothesis (moderate uncertainty)
- a specific set of needed asset change(s), to drive project planning (low uncertainty)
The rough size of initiatives (what we think we should spend from the context budget) can be estimated, to support better dialog around scoping, and “bang-for-buck” as the initiatives are being defined.
Set target execution dates for each initiative (e.g. project) in rough horizons or timeframes like “Now”, “Next”, and “Later”. When dependencies drive a need for tighter synchronization, these Roadmaps can be refined to show initiatives (fueling execution) against specific (e.g. monthly) dates on a timeline. Remember, roadmaps are just communication tools (not contracts), used to show intent and help manage dependencies within the organization (and sometimes, cautiously, used to show intent with the consumers of the business capability).
Frame Next Quarter
Initiatives provide fuel for learning more about the problem space of the business capability. Learning is achieved when we see that our enhancements will enable the business to win. And it is the execution within the Team working on the project, that drive the learning.
A quick sidebar on the relationship between Contexts and Teams:
A team is a small group of people who:
- Share a set of goals
- Share a backlog of work
- Share a way of working (e.g. from stand-ups to configuration mgmt)
- Share authority to make changes (both to assets and to their ways of working)
Leaders in contexts make decisions that create strategy. Members of teams make changes to improve assets. Some contexts are vast enough, that they require leadership teams that treat decision making as their work (i.e. visible in a backlog) and treat the strategy as an asset to change. Most teams have leadership in place, but do not require a dedicated context to set their decision authority and manage a strategy.
Contexts allocate much of their budget to sponsor existing (or form new) teams that support the context’s goals. A common pattern is a context that sponsors (i.e. funds) 3-5 teams to execute its strategy and responsibilities.
A program context often spawns project teams. The program context usually forms the team, exclusively for their mission. Sometimes a project spans multiple quarters. Sometimes it is small enough to kickoff and complete within a single quarter.
To frame the next quarter, leaders focus on the initiatives (e.g. projects) that are targeted in the next quarter. They work with downstream stakeholders (i.e. leaders of the teams that define and execute the work) to arrive at short-term Sub-Goals that can be achieved within the next quarter. For explorations, these sub-goals might frame some interviews or research intent. For experiments, they might be to validate (or invalidate) a specific hypothesis. For asset changes, they describe the expected impact of the change (as an objective) that can reasonably be achieved in the next quarter. These sub-goals will trace up to the business’s overall strategic goals for the next year.
Supplementing the sub-goals with observable (and ideally measurable) Desired Outcomes sets the stage for short feedback loops of learning, which is powerful for any kind of initiative.
These sub-goals will drive the planning of work by the teams. Program and project leaders can also constrain the amount of planning (and amount of work in the next quarter) by supplementing an initiative with a Bet (for the quarter). The syntax of a bet sets expectations around willingness-to-spend for a specific learning objective, while acknowledging the uncertainty in the “game”. It helps program leaders work with teams to maximize the learning and minimize the spend.
.png)
Comments & Feedback: