PM 570 Week 3 Program Management Example

Five Projects, One Refrigerant: Structuring a Conversion Program So the Whole Delivers More Than the Parts

[Student Name]

University of Phoenix

PM/570: Projects, Programs, and Portfolios

Week 3 Assignment

[Instructor Name]

[Date]

Red River Air Systems, its program, projects and figures are composites written for a model paper.

Red River Air Systems, the composite Texas rooftop unit maker followed in this course, began with one conversion project: moving its three-to-five-ton line to R-454B. Within months, four more efforts started: converting the six-to-twelve-and-a-half-ton line, converting a split heat pump line, upgrading the plant for safe handling of a mildly flammable refrigerant and training about 1,400 dealer technicians. Each began under a different manager in a different function. By summer the problems were obvious. All three product projects wanted the company's two environmental test chambers in the same quarter; each had a different leak sensor in mind; the plant upgrade did not know which lines to plan for first; and the dealer training team was building three separate courses. This paper argues that these efforts should be managed as a program and designs that program.

What Makes a Program

In the program management standard, a program is a set of related projects, smaller programs and supporting activities run in a coordinated way so that they yield benefits that running them one by one would not (Project Management Institute, 2017). The emphasis is on benefits from coordination. Pellegrinelli (1997) argued that programs are a framework for organizing project-based change and distinguished several kinds, including portfolio programs grouping projects with a common theme and goal-oriented programs that deliver a strategic change. Red River's effort is goal-oriented: the goal is a company fully converted to compliant, safe products before the regulatory deadline, with dealers ready to sell and service them.

Lycett et al. (2004) reviewed program management practice critically and warned that treating programs as large projects, with the same control-oriented approach, often fails; programs need attention to relationships, flexibility and benefits. That warning shapes the design below.

Benefits Only Coordination Can Deliver

Four benefits arise from managing the five efforts together:

One leak detection platform: a single sensor and controls approach across all three product lines, reducing engineering effort, simplifying certification and letting dealers learn one system. Estimated saving: about $1.1 million in engineering and certification costs and a simpler parts inventory.

Better use of scarce test chambers: sequenced use instead of competing claims, avoiding an estimated eight weeks of idle waiting.

One plant safety design: ventilation, leak detection on the assembly line and cylinder storage planned once for all lines, rather than three partial upgrades.

One dealer training curriculum: a common core on handling mildly flammable refrigerants with line-specific modules, reaching all technicians earlier.

Interdependencies

The program manager mapped the dependencies. The common sensor platform, developed in the first product project, is an input to the other two. The plant safety upgrade must be complete on each assembly line before that line builds production units with the new refrigerant. Dealer training depends on final service procedures from each product project, but its common core can be built as soon as the sensor platform is fixed. The larger rooftop line shares a compressor supplier with the first project, so supplier capacity commitments must be negotiated together.

A dependency nobody owns is a delay waiting to be discovered.

Shared Resources

The scarcest resources are the two environmental test chambers, the independent certification laboratory's slots and the controls engineering team of five. The program office holds a single calendar for chambers and laboratory slots, allocated by the roadmap's sequence, and the controls team works first on the common platform, then on line-specific integration in order. Conflicts that the program manager cannot settle go to the program board.

Governance

Once a month a program board sits down: the chief operating officer in the chair, plus the heads of engineering, operations, sales and quality. The program manager, Ellen Castillo, reports to the board, coordinates the five project managers and owns the program's benefits plan and roadmap. Each benefit has an owner who will be responsible after delivery: the engineering vice president for the common platform, the operations vice president for plant safety and the sales vice president for dealer readiness. Thiry (2004) described program life cycles as cycles of formulation, organization, deployment, appraisal and dissolution, in which benefits are reassessed throughout rather than only at the end; the board's monthly reviews include a short benefits appraisal.

The Roadmap

The program runs in three waves over about 22 months.

Wave 1: the three-to-five-ton conversion, which also develops the common sensor platform; the plant safety upgrade on that assembly line; and the common core of dealer training.

Wave 2: the larger rooftop line conversion and plant upgrade on its line, reusing the platform; line-specific training modules.

Wave 3: the split heat pump conversion, its plant upgrade and final training modules.

Each wave ends with a program review that confirms benefits achieved so far and adjusts the next wave.

How the Program Changes the Projects

For the five project managers, the program changes daily work in specific ways. Each project still has its own plan, budget and team, but three decisions move upward. Choices about the sensor platform now belong to the program, so the larger rooftop project cannot select a different sensor even if its engineers prefer one. Test chamber time is booked through the program calendar rather than by whoever asks first. And supplier negotiations for compressors and sensors are led jointly with the program office, so that Red River speaks to each supplier with one voice and one forecast. In return, project managers gain a place to settle conflicts quickly and a shared risk register for interface problems that no single project could see.

What the Program Office Does Each Month

Castillo's office is deliberately small: the program manager, a scheduler and a benefits analyst. Each month it updates the interdependency map, reconciles the chamber and laboratory calendar with each project's schedule, consolidates the five project risk registers into a program view and reports benefits progress to the board. It does not approve project-level changes or manage project budgets.

Costs and Risks of a Program

Program management adds a program manager, a small office and more meetings, about $420,000 a year. It also concentrates risk: if the common sensor platform has a flaw, all three lines are affected. The program mitigates this with extra testing of the platform in Wave 1 and a fallback sensor qualified as a second source. There is a risk that project managers feel their authority reduced; Castillo leaves daily project decisions with them and intervenes only on cross-project issues. Against these costs, the estimated savings from the common platform and chamber sequencing alone exceed the program's overhead within the first year.

Conclusion

Red River's five conversion efforts are related by a common goal, shared technology, shared resources and a shared audience of dealers. Managing them as a program produces benefits that separate projects could not: one sensor platform, sequenced test resources, a single plant safety design and one training curriculum. A program board, a program manager focused on benefits and interdependencies, benefit owners and a three-wave roadmap make those benefits likely, while research on program management reminds the company that the program must remain flexible rather than becoming one very large project.

References

Lycett, M., Rassau, A., & Danson, J. (2004). Programme management: A critical review. International Journal of Project Management, 22(4), 289-299. https://doi.org/10.1016/j.ijproman.2003.06.001

Pellegrinelli, S. (1997). Programme management: Organising project-based change. International Journal of Project Management, 15(3), 141-149. https://doi.org/10.1016/S0263-7863(96)00063-4

Project Management Institute. (2017). The standard for program management (4th ed.). Project Management Institute.

Thiry, M. (2004). "For DAD": A programme management life-cycle process. International Journal of Project Management, 22(3), 245-252. https://doi.org/10.1016/S0263-7863(03)00065-6