 | Level: Introductory Michael F. Hanford, Chief Methodologist, SUMMIT Ascendant Methodologies
15 Nov 2004 from the Rational Edge: This installment in an ongoing series of articles on program management discusses a new plug-in, targeted at current IBM RUP users, that provides basic process components and methods for mobilizing large program efforts.
IBM Rational SUMMIT Ascendant offers a complete methodology for mobilizing and planning large program efforts. Now, IBM is about to release, in plug-in form, a refined and reengineered portion of this methodology that conforms to the architecture and practices of the IBM® Rational Unified Process,® or RUP,® framework. This article discusses how the new plug-in relates to the full program management methodology, who can and should use it, and how to get started.
As we noted in earlier articles in this series1, we can define a program as: "a collection of projects with a common goal or "vision," under integrated management, consisting of people, technology, and processes, and aimed at implementing significant business / technology change."
A program is, first of all, about achieving significant business or technology change. The term significant indicates that program efforts are large in both scale and impact. This makes it necessary to divide the program effort into a collection of projects, each with its own project manager. Each project "owns" some portion of the overall vision for success or achievement and must also interact and cooperate with others who own different portions of the vision. Earlier articles in this series explain the nature of this interaction, the distinctions between project and program management, and the importance of strong program management and governance.
It is worth repeating that program management refers to the discipline and process concerned with identifying, justifying, mobilizing, planning, and executing large program efforts. It is primarily concerned with outcomes and results rather than development and delivery. It is tightly coupled with the enterpris's overall strategic direction, and encompasses techniques and practices that support, and promote success for, a portion of that direction.
Program management and RUP
IBM Rational SUMMIT Ascendant is a family of business process methodologies that were originally developed and maintained by Price
WaterhouseCoopers Consulting and are now part of IBM's Rational brand. Developed two years ago, SUMMIT Ascendant's Program Management Method, or PMM, grew out of consulting experience on two very large program efforts. It provides processes, practices, and guidance on all aspects of program management.
The PMM provides processes, practices, and guidance in the following areas:
- Development of business vision/business strategies.
- Identification of new programs to enable business strategies.
- Justification of potential programs along multiple business and technical dimensions.
- Development of high-level strategies, milestones, and approaches for a specific program effort.
- Mobilization of the program and development of governance, organizational structure, and resources.
- Implementation of a program management office (PMO).
- Creation of physical and technical infrastructure.
- Development and refinement of program plans and multiple project plans.
- Development and implementation of management and financial controls.
RUP is a process framework that provides a set of processes, practices, guidance, and techniques for software application development. RUP and the PMM are complementary. On a large program effort, the PMM can provide the management framework necessary to create infrastructure elements that promote effective use of resources. RUP can provide process components that enable and guide the work effort associated with projects to define, develop, and deliver software components.
The IBM RUP Program Management Plug-In
The new RUP Program Management Plug-In is part of an ongoing effort to integrate the contents of RUP with the contents of SUMMIT Ascendant. It will allow current RUP users to take immediate advantage of a portion of SUMMIT Ascendant's proven methodology for large-scale programs.
The content of the complete PMM divides logically into three components, as shown in Table 1.
Table 1: Components of the IBM Rational SUMMIT Ascendant PMM
|
Component
|
Description
|
|
| | Vision & Strategy | Create or refine a business vision and set of enabling strategies. Identify enabling programs, define them in multiple dimensions, quantify their potential value, and justify related costs. |
|
| | Mobilization | Establish a governing structure and roles for the program and its projects. This includes developing /implementing a resourcing plan, ramping up staff, and establishing a Program Management Office (PMO). It also includes defining / implementing the necessary physical and technical infrastructure to support the program staff's work. |
|
| | Planning | Define a strategy to develop and deliver a project plan, calculate overall and detailed sizing, define a work schedule, and establish milestones for major checkpoints. Then, establish program practices for oversight, risk control, quality, and financial management. |
The RUP plug-in will contain the mobilization component. IBM's experience in the program management arena has shown that part of the program lifecycle is quite challenging. And if its activities are not implemented properly, the adverse effect on the program can be significant.
Table 2 details the major work activities of the mobilization component.
Table 2: Work within the mobilization component of the IBM Rational SUMMIT PMM
|
Major area
|
Work activities
|
|
| | Mobilization |
- Define governance.
- Establish Program Management Office (PMO).
- Define organizational structure.
- Refine scope and boundaries.
- Prepare resources plan and budget.
- Initiate financial management.
|
|
| | Implement the PMO |
- Identify PMO needs.
- Define implementation strategy.
- Prepare implementation plan.
- Complete resources plan and budget.
- Complete PMO infrastructure.
- Define PMO services and practices.
- Implement PMO services and practices.
|
|
| | Implement the program infrastructure and environment |
- Identify requirements.
- Define components and costs.
- Complete initial acquisition(s).
- Complete infrastructure.
- Implement technical environment.
- Initiate impact and risk assessment.
- Plan and deliver training.
|
A different way of working
The methodology and process culture from which the PMM was developed is different from those that spawned RUP. In addition, because the PMM focuses on business management rather than software development, there are inherent differences in the approach and guidance that the two methodologies provide. We will explore some of these differences below.
Linear, not iterative
As a management methodology, PMM processes are essentially linear rather than iterative. In mobilizing a program, some work is done early, some a bit later, and some last. The early work establishes readiness to perform later work and make decisions. A corollary is that if the early work is not done, or is partially or poorly done, this will compromise the ability to complete work successfully later on.
For example, establishing a governance structure and a set of program practices is part of the early work effort. A program effort needs effective governance to provide a framework for all subsequent oversight, control, and decision-making. A governance structure provides answers to many questions that project managers and team members will have: Who will make decisions? What is my management role? What am I (or others) empowered to direct or authorize? The answers to these questions must be clear at the outset; everyone must know who authorizes expenditures, hires / contracts resources, and is responsible for the physical and technical infrastructure. Otherwise, the program will quickly sink into chaos.
Explicit dependencies
For all of the activities that describe the work effort in the methodology, there is a defined set of precedence and dependency relationships. These relationships explicitly identify work that must be completed as a pre-requisite for starting other activities. As a corollary, you can clearly evaluate a team's or individual's readiness to start an activity by determining whether they have completed the pre-requisite work.
The PMM also describes relationships among artifacts and defines a set of input / output relationships. These relationships explicitly identify artifacts that must be in either a draft or final state so that they can be used as input for the work effort required to complete other artifacts.
Level of detail
The PMM describes workflows and activities in the form of concise outlines with spare detail. The outlines typically include an introduction and explanation, and a set of work steps phrased as imperative sentences. Most begin with an instruction such as "Complete this" or "Gather that."
The guidance is aimed at providing an understanding of what is to be done or achieved; it does not explain at length how to go about doing the work, what tools to use, or what techniques to employ. The instructions assume that an experienced manager will be leading the effort.
Activity orientation
Artifacts and other items associated with an activity are linked to that activity as either inputs (pre-requisites for work) or outputs (results from work).
Artifacts, descriptions, samples, and templates
The PMM identifies artifacts and briefly describes their purpose and contents. Many artifacts are additive; that is, you assemble them from individual work papers you produce through activities. Templates are provided for most of these work papers and artifacts, and many (not all) artifacts are further described in sample deliverables. The contents of these sample deliverables are derived from a single case study, so all are fully integrated.
Estimation guidelines
The methodology also provides estimation guidelines for all activities that enable managers to size the work effort. These guidelines include sizing metrics that require data collection, and may provide guidance for their use. For example, the size of the work effort associated with developing the program's structure will be driven by the number of functions the program has to perform. Assembling an organizational structure for a program with a large number of functions will require greater effort than assembling a structure for a program with a small number of functions. Therefore, it is necessary to identify and count the anticipated number of program functions.
Who should use the IBM RUP Program Management Plug-In?
Before you decide to use this plug-in, you should carefully consider whether it will add value to your enterprise. In some industries, there will be little question that the answer is "yes." Enterprises in the defense sector, for example, have been planning and executing program efforts for years, often with home-grown practices. For these enterprises, the plug-in's mobilization guidelines offer a chance to validate those practices. Managers can compare these guidelines with those they have been using and then perhaps develop a strategy to substitute all or part of the plug-in practices for their own.
Other enterprises may discover that they have been engaged in program management without using the term or realizing that they have moved into another management discipline that they do not fully understand -- and in which they may have a poor track record.
We have observed organizations whose business practices and IT structure needed to undergo transformation, including the identification and enablement of enormous "projects." As they moved forward with such efforts, these organizations encountered difficulties on many fronts. Their business vision and strategy lacked clarity; their governance and administration were not well defined; they lacked financial controls, and so forth. They couldn't clearly see the cause of these problems, and the "project" found itself thrashing. That is, there was a good deal of activity, but there was little real accomplishment or forward motion.
As you can see in Table 3, determining whether your organization is in such a situation is not always easy or obvious.
Table 3: Criteria for distinguishing projects from programs
|
Major area or focus
|
Dimensions or attributes
|
Project or program?
|
|
| | Direction and oversight |
- Multiple business segments involved
- Multiple responsible executives
- Frequent executive decision-making meetings
|
Either
Projects may cross boundaries.
Programs typically involve multiple business segments that share accountability for implementation of the business vision.
|
|
| | Top-level project management |
- Spend most of their time integrating the efforts of others
- Interact with multiple management levels
- Focus on change, not on delivery
|
Program
In a program, the most senior hands-on manager must spend most of his or her time integrating and refining multiple efforts, and maintaining a focus on business strategy and goals.
|
|
| | Finances |
- Significant capital expenditures
- Exceeds the organization's typical project budget by 4 times or more
- Requires a special cost center
- Requires executive-level cost reviews
|
Program
Programs have significantly larger budgets than projects, and their finances are typically reviewed at the most senior executive level.
| | Infrastructure / standards |
- Involves major technical components
- Involves refining/setting new enterprise IT standards
- Involves retirement / replacement of major applications
|
Either
Some projects involve a major application and related standards. Programs typically encompass multiple components, standards, and applications.
| | Planning and plans |
- Single project plan seems unworkable
- Diverse work effort
- Many plan "owners"
- Large/very large number of resources
- Review of project plan is insufficient to understand current "œstate" of work.
|
Either
Failure to produce a single workable plan might indicate that the effort is either a program or a large project. It may also result from poor planning skills.
Programs have a separate plan for each project, and an overview plan -- or program plan -- that coordinates the project plans.
| | Size and complexity |
- Multiple types of efforts, some unrelated to software delivery
- Large team(s) with multiple sources for resources
- Technical components related to multiple areas: software, infrastructure, communications, Web services
- Large or very large number of work hours and large expenditures
|
Program
Large, or very large, efforts that address multiple technical areas and involve multiple components are typically best managed as programs rather than projects.
|
If your assessments of at least three of the six areas in Table 3 seem to indicate that you might be working on a program, it makes sense for you to analyze your current practices against those in the RUP Program Management Plug-In and determine whether they can help you.
Getting started and getting help
Teams typically begin adopting new practices by reviewing the work they've planned and identifying one effort to use as a "pilot," or a proving ground, for the new practices. This strategy works well with the practices in the RUP Program Management Plug-In: You may decide to begin with a single focus area before applying the entire set of practices. The logical place to begin is program initiation, which allows some transfer of skills and capabilities from project management and involves a relatively small group of individuals.
A pilot effort has two goals: to plan and perform work that is of value to the enterprise, and to provide a learning/validation experience for new practices. Whatever place you choose to begin, your pilot must not be so time critical or mission critical that you cannot afford to include learning and review tasks -- or that you will be tempted to skip them in a "crunch." Also, everyone involved must accept the notion that some work effort will be nonproductive in relation to delivering program results. Managers at all levels must understand and agree upon the value of spending time on discussion, learning, and determining good -- and bad -- choices.
Ideally, organizations should engage an outside mentor to oversee the planning effort, someone who provides guidance during program initiation and conducts a review and assessment when the initiation is complete. This allows the individuals engaged in the initiation to stay focused, receive experienced guidance, and have a "sounding board" for problem-solving. The outside mentor should have proven capability in the program management space, including application of PMM practices. This provides a firm foundation for judgments about necessary adjustments to the practices during both planning and execution of the work effort.
Training is also critical for team members who will work with the PMM practices. IBM Rational has developed separate training materials for high-level executives and those who will actually use and apply the practices. Any organization adopting the PMM should provide formal training, in the form of briefings or training courses, on a "just-in-time" basis, shortly before the work begins. In addition, managers should schedule periodic roundtable discussions during execution to review, dissect, and validate the new practices.
Conclusion
By delivering the initial phase of the IBM Rational SUMMIT Ascendant Program Management Method (PMM) in the form of a RUP plug-in, IBM will be providing the RUP user community with valuable practices and techniques in a new management space. The program management discipline is concerned with strategic efforts that typically impact a major enterprise business segment or direction. Often these efforts directly affect the bottom line, and/or the viability of portions of the enterprise. They offer significant challenges along multiple dimensions, including governance, administration, and finance. Well-worn project management practices are insufficient to meet these challenges.
The practices in this new plug-in are based on real work performed during large consulting engagements. They focus on activities that add value, reduce risk, and improve the program's overall chances for success. For enterprises that have attempted large initiatives in the past with poor results, these practices may offer the answers and guidance they need to succeed with similar efforts.
This article discusses just a sample of the guidance available through IBM Rational Unified Process and IBM Rational SUMMIT Ascendant, which includes support for both pre- and post-mobilization program phases. For more information, please either visit http://www-306.ibm.com/software/rational/howtobuy/index.html or call 1-800-728-1212.
Notes
1See "Strategic components for identifying and justifying a program," The Rational Edge, August 2004.
About the author | 
| Michael F. Hanford is the chief methodologist for the IBM SUMMIT Ascendant methodologies and a member of the IBM Rational commercial methods content team. He has also worked as a methodology author, a manager for large consulting engagements, and a leader of enterprise process assessment and transformation efforts for IBM Rational and PriceWaterhouseCoopers Consulting (PWCC). Prior to joining PWCC, he was director of software engineering practices for Fidelity Investments Systems Company. |
Rate this page
| |
