As a large program effort mobilizes, there are components and work results that should become part of the foundation supporting the program's forward progress. This solid foundation can then provide "traction" for the program's forward movement, serving as a reference framework. This "body of certainty" guides further work, provides a basis for understanding the context required for decisions, and allows participants to easily locate parties responsible for specific work areas. These components and work results may include published practices for program staff to follow, role definitions, specifications for allowable decisions, and so forth. They also encompass the creation of organizational structures, such as an organizational model and a governing body. This article will focus on the latter, examining how to define an effective program governance structure.
Definitions: Program and governance
Before we launch into a more detailed discussion of program governance, let us define two basic terms we will use in this article.
A program is a major enterprise initiative -- an element in the overall business strategy and direction. Here's a formal definition:
A collection of projects with a common goal or success "vision" under integrated management. These projects consist of people, technology, and processes aimed at implementing significant business and technology change.
As programs progress, they require a linkage mechanism that ensures alignment between business strategy and direction, and the path to needed outcomes over the life of the program. In other words, this mechanism must help the program sustain its potential to deliver its promised value. Moreover, other mechanisms must provide oversight and control during program execution. They must help managers assess the program's current state and adjust content and direction if necessary. They should also allow management to refine the definition of success to maintain alignment with evolving business strategy.
The simple diagram in Figure 1 provides a view of the overall context in which programs are enabled and executed.
Figure 1: Overall work context for programs
As the simple diagram in Figure 1 shows, the overall business and IT strategy and direction are first defined for the enterprise. Next, some enterprises create portfolios of programs and projects as part of the execution mechanism for business and IT strategies / direction. Therefore, we can think of programs as elements -- among others -- that an enterprise enables to execute its business and IT strategies / direction.
To achieve the necessary linkage, oversight, and control we described above, programs must institute effective governance, which for program management is defined as follows:
Governance, for a program, is a combination of individuals filling executive and management roles, program oversight functions organized into structures, and policies that define management principles and decision making.
This combination is focused upon providing direction and oversight, which guide the achievement of the needed business outcome from the execution of the program effort, and providing data and feedback, which measure the ongoing contribution by the program to needed results within the overall business strategy and direction.
The concept of governance has multiple dimensions: people, roles, structures, and policies. Overseeing and actively managing program work is a more complex undertaking than project management. Furthermore, programs are dynamic, not static. They must respond to external events and changing conditions. Therefore, an effective governance structure and set of governance functions must provide the means to identify, assess, and respond to internal and external events and changes by adjusting program components or features. A poor (or nonexistent) governance structure will leave the program in a continuously reactive state, constantly struggling to catch up with changing conditions.
In this article we will take up a number of elements in governance, including:
- Organizational structures. These may include a program steering committee, a Program Management Office (PMO), the program organizational model, and the project organizational model.
- Roles. These may include the executive sponsor(s), a steering committee member, the program director / manager, the PMO manager, and project managers.
- Mechanisms. Designed to provide guidance and direction, these may include policies, governance principles, and decision or authority specifications.
Goals of program governance
Program governance addresses a number of goals:
- Define and implement a structure within which to execute program management and administration
- Provide active direction, periodically review interim results, and identify and execute adjustments to ensure achievement of the planned outcome (which contributes to success of the overall business strategy)
To achieve these goals, organizations define, agree upon, and implement structures within the program effort. There is no single "best" structure; rather, the structure should "fit" the enterprise's organizational dynamics and practices. For example, within a consensus-oriented business culture, the program structure should provide for achieving, and continuously refining, consensus around major program outcomes. A program organizational structure that runs counter to components of the business culture will struggle to achieve momentum and forward motion.
Active direction for the program is achieved through a combination of the right individuals, an effective structure for management and oversight, and a "set" of program roles and responsibilities. Roles and responsibilities should be defined and structured, with the needed outcomes of the program in mind, and to "fit" within the management philosophy and enterprise approach.
Program governance structure and roles
To be effective, the individuals who direct the program and those who oversee its work activities must be organized, and their contributions must be modeled to ensure that authority and decision-making has a clear source, the work of management and oversight is efficient, and the needs for direction and decisions are all addressed.
An organizational model should decompose all management and oversight functions, and describe the relationships among them. Figure 2 is a fairly typical model; and variations are possible.
Figure 2: Sample program governance structure
Below, we will look at three roles shown in Figure 2:
- Executive sponsor(s)
- Steering committee
- Program director / manager
Executive sponsor(s): Direction and oversight
A program needs one or more executive sponsors to ensure that it will make an appropriate and necessary contribution to the overall enterprise business strategy.
Typically, this executive (Gwen Hunt, in our example) "owns" the major business segment that will be both the program's principal beneficiary and accountable for achieving the program's defined outcome(s) specified in the overall business strategy. For a major initiative that will impact and benefit multiple enterprise segments, multiple executives typically share this accountability. This might be structured in one of two ways:
- Multiple executive sponsors share responsibility for the program's success and achievement of defined outcomes.
- One senior executive sponsor is designated as the final decision maker, and other executive sponsors serve as members of a steering committee. In addition to providing advice and impact assessments, these committee members are jointly responsible -- with the senior executive sponsor -- for a successful program outcome as well as desired outcomes in their respective business segments.
Steering committee: Directing / advising
Large initiatives typically impact more than one business segment, and multiple segments often own different (but dependent or integrated) outcomes and results within the context of the overall business strategy and direction.
Such initiatives require a governance mechanism through which all segment representatives can reach agreement on a direction that will result in desired outcomes for everyone. These programs also need a forum in which the representatives can raise issues and adjust direction, resources, or timing by consensus, as required. This mechanism is often a steering committee.
Steering committees can follow different models. For example, a committee might consist of:
- Executive-level sponsors who must reach consensus on issues, changes, and adjustments in order to proceed (consensus model)
- Executives and senior managers who are stakeholders for some aspect of the defined outcomes. Their role is to understand issues and needed changes, provide advice and assessment of potential impact, and make needed adjustments within their own responsibility area (consultative model)
- Representatives for the major business segments who are responsible for outcomes, or portions of outcomes, within the business strategy and direction. Their role is to monitor program progress, understand issues raised and adjustments made, assess potential impact within their own business segments, and carry back information about committee decisions to their respective business segments (advisory model)
Consultative and advisory models have a number of similarities. A key difference, however, is that in a consultative model, each business segment has significant ownership of the work effort and its results within that segment. In the advisory model, that ownership is diminished. Information is carried back to the business segment, and any decisions, adjustments, and issue resolutions are expected to conform to the direction provided by the program governance body or structure.
The program director / manager: Management and integration
It would be simple -- and wrong -- to assume that a program director / manager (to keep it simple, let's use program manager) has nearly the same functions and responsibilities as those of a classic project manager.
A program, as we know, consists of multiple projects, each with its own project manager. Does this, then, make the program manager a "super project manager?" Table 1 compares the two roles.
|Program manager||Project manager|
|Integrates efforts, continuously assesses and refines approaches and plans, ensures good communication.||Plans, organizes, directs, and controls the project effort.|
|Directs managers to achieve defined outcomes aligned with business strategy.||Manages for on-time delivery of specific products.|
|Acts as the implementation arm of the program sponsor(s) and / or steering committee.||Manages work within the project plan framework.|
|Manages managers.||Manages technical staff.|
As Table 1 shows, the program manager and project manager roles are quite different from one another. Whereas project managers typically focus on delivering a specific component, program managers typically focus on one or more outcomes that are business strategy components.
Maintaining links to business strategy
Throughout program planning and execution, managers must ensure that the program sustains a connection to the business strategy. As we have noted, this strategy is dynamic, not static. Both internal and external events affect the enterprise's initiatives, so programs need mechanisms that will maintain a link between the initiative and the business strategy, and provide for effective data exchange and necessary adjustments.
We can divide such mechanisms into two categories: those active during mobilization and planning, and those active during execution.
Mobilization strategic review
A number of work products specifically related to an individual program effort should be developed, and agreed upon, during the definition of the business strategy. These products describe the results of strategic work efforts to define the program, and justify proceeding with it. They provide initial links to the business strategy and help to frame the mobilization effort. These products should include:
- IT goals and strategy
- Program capital and expenses budget
- Program benefits definition
- Program outline
- Candidate projects identification
- Program mobilization plan
- Consulting and staffing agreements
A business strategy review should be part of the overall mobilization process for both the program and its constituent projects, to check the quality of the business strategy input and to determine readiness to proceed.
Planning strategic review
Both the overall planning process for the program and the planning process for its constituent projects should require a review of the current "state" of the program business strategy. This will ensure that the input for plans and schedules includes the business strategy elements in their most current form.
Program execution strategy reviews
As the program proceeds, the program plan and schedule should provide for periodic strategy reviews by the program sponsor(s) and / or steering committee.
The schedule for these reviews can be aligned with the program's phase structure, which cuts across all of the constituent projects. As a phase-end approaches, reviewers can compare the program's current state and results against the then-current business strategy, and propose needed adjustments.
Decisions and authority
An important aspect of program governance is assigning specific decision-making authority to each executive and management role. Program managers can hold special group work sessions for this purpose and then create and distribute a matrix for major decision areas and roles. Figure 3 shows a sample decision authority matrix that has proven useful in past program efforts:
Figure 3: Sample program decision rights by role matrix
In Figure 3, the "decision qualifiers" indicate the scope of the role's decision-making powers. These qualifiers should be as specific as possible, preferably using some metric to indicate the role's upper limit in a decision situation.
A simple mechanism like this, posted on the program intranet site, will be a good starting point for team members who require a decision or need authorization to proceed with some action.
From an organizational perspective, a program is not a single structure, but rather a set of integrated (and interacting) structures. There is no "best" way to organize program resources into a set of structures, but we can look at typical organizational components and their functions, and comment on their value.
The components we will examine in this portion of the article are:
- The program "core" organization
- The Program Management Office (PMO)
- Organization of constituent program projects
The program core organization
An organizational structure is required to support and enable all of the program's day-to-day oversight and integration efforts. At the heart of this structure is the program manager, whose role we have already discussed. The program manager will typically be supported by Program Management Office (PMO) staff, but will likely have a small group of individuals who either report directly to him / her or are identified as part of the PMO staff, but work for him / her.
These individuals help the program manager to identify and understand departures from plan in terms of progress and expenditures, and to coordinate communications.
Table 2 describes possible roles for these core staff members.
|Program planner||A management role, responsible for construction and maintenance of all planning strategies, plans, and schedules for the program and constituent projects.|
|Budget administrator||A PMO role that administers and reports all program finances; the budget administrator also serves as a liaison to internal financial management, which supplies controls and interprets corporate financial policy for the program.|
|Communications coordinator||A PMO role that coordinates and disseminates all program information to both program staff and the broader enterprise. This person also serves as a liaison to corporate communications, which interprets communication policies and handles external communication for the program.|
This role list is not exhaustive; some programs define a significant number of other staff and management roles for their core organization. To some degree, the roles you select should reflect specific program needs and the program manager's style, as the following example illustrates.
The program planner role
The program planner is responsible for all planning within the program. This is a management role that addresses the development of planning strategies and approaches, the definition and fulfillment of other planning roles, and the development of work plans for the program, its constituent projects, and other parallel efforts, such as quality assurance and testing.
A number of roles report to the program planner, including a planner for each project that may vary from a full-time to a one-third full-time-equivalent (FTE) commitment, depending upon the program's planning stage.
A program estimator may also report to the program planner. This individual is responsible for sizing the work effort and estimating resource requirements.
In addition, certain other staff roles will have a matrix reporting relationship to the program planner in order to construct and validate work approaches, plans, and estimates. For example, the manager responsible for testing code assets has a matrix reporting relationship to the program planner for developing test strategies, plans, and estimates, and then integrating these into the overall program plan.
A Program Management Office model
The Program Management Office (PMO) provides support along administrative, financial, process, and staff dimensions associated with successful program execution. The PMO's administrative support includes plan conformance tracking, management of work products, resources administration, and physical and technical environment support.
The PMO also provides review and tracking of financial expenditures, generation of required reports and financial documents, and liaison with the enterprise financial organization to ensure compliance with policies and practices.
Finally, the PMO provides and administers policies, procedures, and practices that provide an operational framework for program staff. This encompasses issues such as time reporting, contracting for outside resources, allowable expenses, training, communications about the program, and internal reporting practices.
Figure 4 shows one possible organizational model for a Program Management Office (PMO).
Figure 4: Example Program Management Office organization
The roles shown in Figure 4 are fairly typical for a large program effort. Depending upon the program execution stage, some roles may become either more or less active. In this model, in at least one instance the same person fills two roles: status and tracking as well as issues management.
Also, in some enterprises, a role may be delegated to an individual working within an existing function to provide program support. For example, many enterprises have a function that will deal with outside consulting and contracting firms to obtain external staff resources. An individual from that function can fill a role in the PMO, while being assigned part-time to the program.
Also notice that some of the roles we identified above as part of the program "core" organization are shown here: program planner, communications coordinator, and budget administrator. In this instance, for administrative and resource approval purposes, these roles report to the PMO manager.
Project structure within a program model
The organization structure for individual projects within a program effort is usually straightforward: The program organization -- most typically the PMO -- simply supplies administrative support and technical resources for such concerns as facilities, training, budget, and so forth.
Figure 5 shows a sample organizational structure for a project within a program.
Figure 5: Sample organizational structure for a project within a program
For the most part, projects within a program effort can be thought of as primarily delivery organizations. These projects are organized and function to deliver elements that will be integrated together into a larger whole -- in software projects, for example -- that would be code assets. However, a program may also have projects and teams with different purposes and/or structures. For example, a team might focus solely upon product testing, quality assurance, or systems architecture. These special-purpose teams may also provide services to multiple projects or be responsible for work conducted in parallel to program delivery efforts.
Establishing a governance framework is one of the most significant efforts required for program mobilization. The success of this effort has a direct correlation with the program's potential for long-term success because governance enables the program work, addressing such needs as:
- Continuous linkage to enterprise business strategy and direction
- Clear and well-understood decision-making authority
- Effective oversight of (and insight into) program progress and direction, including the capability to identify and execute necessary adjustments in the face of internal / external events and changes
- Executive control over program evolution and outcomes
To operate, programs and program functions typically require multiple organizations that must integrate and interact effectively. Program staff must understand each organization's value as well as the integration and interaction among different organizations -- so that they can navigate these organizations to best advantage and accomplish their work. To be truly effective, the organizational structure of each project or other venture within a program must conform with the enterprise's overall management philosophy and approach.
- Explore the Rational software area on developerWorks for technical resources, best practices, and information about Rational collaborative and integrated solutions for software and systems delivery.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools, as well as IT industry trends.
- Watch developerWorks on-demand demos, ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
Get products and technologies
- Try building and deploying your next project on the IBM Bluemix cloud platform, where you can take advantage of pre-built services, runtimes, frameworks, application lifecycle management, and continuous integration.
- Download a free trial version of Rational software.
- Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment.
- Check the Rational software forums to ask questions and participate in discussions.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
- Join the Rational community to share your Rational software expertise and get connected with your peers.