Skip to content

Series 4/4: How to plan and set the course of a program

Idea

Outline

Having built communication channels across all levels and instilled status reporting, how do we enable program leadership to steer the ship?

In the last two blogs, I outlined how to establish a program governance structure and set up trackers to capture developments in delivery, financials, resources, and risks. So far, these instruments allow program leadership to detect and react to incoming blockers and issues quickly, which is often referred to as firefighting mode. In this blog, I’m outlining how programs can plan ahead and remove potential blockers proactively without causing new tensions caused by top-down-only leadership or frontline resistance.

A firefighter and a captain doing their jobs

From bottom-up reporting to top-down steering

The intention behind starting to set up a program governance structure by establishing management levels and communication to report status bottom-up is to create a first layer of trust between program leadership and project delivery teams. By making sure that leadership’s first priority is to ensure that project teams are heard, it buys goodwill for project delivery teams to be guided by the program leadership if the course of the program has to be adjusted. Adjustments to the program delivery are based on navigation and planning, which is broken up into three levels:

  1. Strategic review, program setup and funding
  2. Program management planning to reallocate existing resources
  3. Detailed project delivery planning by project teams

The interplay between navigation and planning

When splitting the program governance into strategic, tactical, and operational levels, we need to understand the powers that change the course of a program, which often has a strategic impact on the organization: Navigation and Planning. There is the danger that these two instruments are mixed, leading to known problems where leadership dictates unrealistic targets to the project teams, thus sapping motivation and buy-in. Or where project teams try to steer their own destiny because they are ‘on the frontline’ and argue to know better than leadership. Distinctively separating these terms allows us to manage how each level influences the program’s success and destiny.

a compass

Navigation is setting a vision and high-level objectives that outline where program leadership wants to steer. It also includes allocating resources like people or finances that set the parameters for project teams to pursue these objectives. Leadership sets these objectives and communicates them top-down. Ideally, the navigation is set together with all levels based on data from status trackers and reports.

A hiking plan

Planning is the exact path on how to achieve the vision and high-level objectives that were set by program leadership. It includes adjustments to the work breakdown structure (WBS), scheduling, and resource allocation of existing resources in order to achieve the new direction that leadership has set. Effective planning is done from bottom-up while consulting tactical and strategic layers in prioritization and resource allocation. Then, the planning needs to be validated, which allows project teams to work on the adjusted course of action.

After defining these two terms, let us see how each level handles these two instruments.

Strategic level – Sponsor and Steering Committees

Navigation: Usually, the strategic level is represented by a Sponsor or a Steering Committee. On a strategic level, decisions are taken that guide the entire program and impact the allocation of resources predominantly by removing or allocating financial means for the program from outside sources like the organization’s funds. On a regular basis, all projects within the program should be reviewed whether they are returning the expected results or if they unlocked new opportunities that can be seized. The installed status trackers, as well as the regular project status update slides, provide valuable data to measure the performances of all program projects. In summary, this could lead to the termination of some projects or the creation of new ones, which should follow a certain decision matrix as outlined in the portfolio management blog. The strategic level also reviews the overall goals and makes adjustments to them, passing the refinement of the vision or overall goals to the tactical level.

Planning: The strategic level of a program is typically at the end of the planning process that goes from bottom-up. Nonetheless, it can set some high-level milestones and should be consulted by the tactical and operational levels to validate the plans and manage senior stakeholder expectations.

Tactical level – Program Meetings or Operational Committees

Navigation: The tactical level is where the program leadership sits and often is composed of the program manager, the governance team, and the project managers. Knowing and owning the resources of the program, they refine the high-level goals set out on the strategic level with goals that the project teams try to achieve. A helpful framework is OKR planning, which encourages the definition of objectives with 3 to 5 key results that teams aim to deliver. For example, for an e-commerce website it could look like this

Objective: Grow our community: Double the number of active users

Key Results:

  • Attract New Users of 3m by end 2025
  • Keep Actives to 2.5m by end 2025
  • Reawaken Returners of 5.5m by end 2025

Planning: The tactical level is more involved in the planning stage as it takes on the accountability of the project teams to plan with ambition and realism. Also, program leadership needs to ensure that cross-dependencies between project teams are managed and program resources are appropriately distributed, which can lead to shifts in timelines, team configuration, or work prioritization. The program can also issue entirely new work packages or deliverables for the project teams to fulfill.

Operational level – Project Teams

Navigation: The operational level is composed of the project managers and their teams, who have to deliver the program objectives. While not steering the program, they should be consulted and involved when defining the strategic and tactical goals, as leadership might otherwise encounter resistance from the delivery teams.

Planning: Once the top-down goals are communicated, it is the project manager’s responsibility to plan out the work packages. Ideally, this is done with the entire project team, as the team members can provide the best insights on the complexity and duration of tasks required to deliver a work package. These plans can be quite detailed and should include a list of all deliverables or work packages, milestone dates for completion (e.g., design, development, quality assurance, deployment), resource plans, and risks.

From firefighting to proactive planning

Making a distinction between navigating and planning creates an effective planning framework that allows each level to have an influence in the appropriate areas. This avoids conflicts where the lower levels feel overruled and paralysis where it’s unclear who has the say. Also, because the higher levels get bottom-up reports about blockers and constraints, they have the tools to replan or allocate resources to remove these blockers before they materialize. That’s a healthy move away from constant firefighting to proactive planning and management. A potential way to map out the interchange between navigation and planning is outlined below.

Example of a program planning governance

This is an example of how the planning and navigation could work between all three levels of the program governance, with clear responsibilities on each level. The roles and responsibilities can and should be refined during the first few cycles to ensure a cultural fit within the program. Last, I can’t emphasize enough that while the responsibilities are clear on each level, it is best practice and decency to align throughout all levels to ensure an ideal solution is found.

What about scope control and change requests?

The setup described in this blog post follows a possible setup for a startup or a scaleup that is bringing products to market that need regular refinement. A program is usually a not-time-defined endeavor with multiple projects within it that are time-limited and thus need to be controlled from a scope perspective. Nonetheless, I worked in programs where the budget and timelines were defined. In these cases, the process of replanning, as outlined in this blog, was transferred to regular refinement of planning. Even the best multi-year programs cannot be planned out day-by-day over several years. Thus, having refinement sessions helps to monitor progress and make potential adjustments. If scope or substantial timeline changes occur in these refinements of planning, then they would have to go through a change control process, which is not a topic in this blog series.