Setting Boundaries

What organizational design is in place to help a program leader understand the boundaries of their decision authority? Start with questions like:

• What are the boundaries between this program and specific businesses?
• What is the relationship of this program to any strategic business capabilities?
• What is the relationship of this specific program to any products, product lines, or solution offers?

‍

‍

Identify Context

We will begin by describing a context, dedicated to the project. We will also assume that these programs aim to enhance or improve some aspect of business capability. The first context-to-context relationship we’ll cover is the parent-child relationship.

The Parent Context for this program context is a portfolio context, where the portfolio is created on behalf of the business units. This program context is sponsored (and funded) by the parent solely to drive a specific outcome by a specific date. The parent portfolio’s strategy is visible through the Parent Goals and specific Parent Results, which define the needs for change across one or more business units - that is, the changes the businesses feel they must make to achieve their goals and commitments. These portfolio goals are in turn driven by the businesses’ choices on “where-to-play” and “how-to-win”. The program context will then refine their own “Where to Play” and “How To Win” to clarify how they will drive the outcome by the given date.

Define Context Scope

The Mission of a program is to deliver a specific outcome by a specific date. Use the discussion of mission to establish the value that is offered to others outside the context. This can be expressed as a service catalog, if desired, to help these other contexts understand how to engage with this program context.

Its Responsibilities include:

1. Program Planning and Strategy - developing goals, scope, and deliverables that align with the organization's strategic objectives, with strategies to achieve program outcomes, identifying interdependencies between projects, and establishing a roadmap for execution.
2. Program Governance and Stakeholder Management - establish effective governance structures to ensure proper oversight and decision-making, plus managing relationships with senior management, project managers, team members, and external partners, by communicating program updates, managing stakeholder expectations, and addressing concerns.
3. Resource Allocation and Management - allocating and managing resources across multiple projects within the program by assessing resource requirements, coordinating resource allocation, and optimizing resource utilization to ensure projects within the program are adequately staffed and supported.
4. Program Monitoring and Reporting - monitoring the progress of projects within the program to ensure they are aligned with program objectives, and tracking key performance indicators, project milestones, and budgets to assess program performance.
5. Program Leadership and Team Management - Providing leadership and guidance to project teams and stakeholders involved in the program by establishing a collaborative and motivated work environment, setting expectations for project managers, and facilitating effective communication and collaboration across projects.

Assets owned and maintained by a program context include the program documentation, but more importantly, the context might receive (temporary) ownership of specific assets to change to drive the outcome.

The leader(s) of a program context have the complete Decision Authority to decide:

• What projects to create
• What goals to set for the projects

Decision Rights

Leaders delegate decision making by creating boundaries of authority. Decision rights enables the speed and effectiveness of decentralized decision making.

Learn more ->

Define Context Behaviors

The program context builds and maintains a set of Capabilities related to driving the program. Performance and success for the context are governed by KPIs that show how effectively the  capabilities are executing, for example:

• Program planning (cycle time)
• Budget tracking (plan, forecast, actual)
• Scope tracking (plan, forecast, actual)
• Date tracking (plan, forecast, actual)

Program leaders oversee a Workflow that produces outputs (the improved business capabilities) consumed by their customers (the business):

1. Create plan
2. Kick-off program
3. Make changes
4. Deliver changes
5. Monitor outcome

Depending on the nature of the program, a workflow like this Needs Value from other Peer Contexts. For example, the program context might need help to make changes in certain assets.

Program leaders drive several key Rituals to help communication and alignment across their stakeholders, and support cross-context collaboration:

• Program Planning
• Program Kickoff
• Program Status Review
• One-on-ones (between context leader and related child and parent context leaders)

If the program context consumes value from other functional contexts (that support steps in their workflow), they might pay a monthly Rate for this service, making them an internal customer (as well as a consumer). These rates are generally proportional to the run rate (or costs incurred) by the peer context itself (i.e. staffing needed to execute a service).

‍