This month we provide a summary of Chapter 14, Successful Change Programs that Improved Integration, in Integrating Program Management and Systems Engineering (IPMSE), a collaboration of the International Council on Systems Engineering (INCOSE), the Project Management Institute (PMI), and the Consortium for Engineering Program Excellence (CEPE) at the Massachusetts (USA) Institute of Technology (MIT). This is our fifteenth article in this series. Our objective in providing this series is to encourage subscribers to leverage the research base of this book that has provided new knowledge and valuable insights that will serve to strengthen the performance of complex programs. “The Book” is highly recommended as professional development for all systems engineers and is available to members of INCOSE at a discount.

Chapter 14 is the second of three chapters in Part III of The Book, labelled Developing Integration Competencies in Your Organization (Chapter 13 is titled Integration Means Change; Chapter 15 is titled Leading an Integration Change Program).

Chapter 14 provides five case studies describing change efforts to develop or strengthen integration capabilities in engineering programs and organizations. They illustrate different approaches taken to create the changes needed to increase the level of integration between program management and systems engineering. The case studies illustrate the elements of the Integration Framework developed in Chapter 6 and provide examples of ways to implement them. It was found that each organization and engineering challenge is different, and that meaningful change in processes, practices, and mindsets comes from active and sustained efforts by the organization and its leaders.

In the first case study, involving integration of program management and systems engineering at Lockheed Missiles & Space Company (LMSC) in 1957, an integrated management approach was developed in the years when the systems engineering discipline was still in its early stages. The challenge in this example was the repeated technical failure of complex systems in a new and challenging technology area. The need for change was clear and urgent with each successive and costly mission failure and the inability of the program to deliver any tangible benefits. The implementation of a rigorous technical process by defining and integrating the chief systems engineer into the program organization structure provided essential information to the program management to improve the quality of decisions and coordination across the entire program. The program manager was therefore better able to understand and influence technical issues, including those at the subcontractor level. Mission success rates improved dramatically, and the organization demonstrated sustained change by continued use of the practices by diffusing them into follow-on programs and through their impact on the development of the work force. Progression from chief systems engineer to program manager became the norm for the LMSC Space Systems Division organization and several presidents of that Division were appointed through such a chain of assignments. Systems engineering provided the “layer” necessary to connect the highly complex engineering reality with the requirements of managing a large program.

The actions taken in this example to increase integration included:

• Integrating planning and resource allocation for engineering efforts into the program manager’s responsibilities;
• Restructuring roles of managers and functional leads in the program and in the division;
• Developing policies to manage staffing to ensure an appropriate and equitable balance of the right technical people across the organization;
• Developing leadership transition paths from chief systems engineer through program manager and above;
• Adapting to challenges by testing new integration approaches over time to see what works; and
• Pilot testing new ideas on one program, and then diffusing best practices to others.

CIA employees increasingly appreciated the relevance of systems engineering in their projects; indeed, 89% of them reported that it was applicable to their jobs, a full 30 points higher than they reported prior to their certification program.

During the late 2000s, the Federal Acquisition Institute developed and implemented the Federal Acquisition Certification for Program and Project Managers (FAC-P/PM). That certification was created to extend the integration of project management and systems engineering from the U.S. Department of Defense (DoD) to all civilian federal employees, especially those involved with limited scope and lower complexity projects. The approach called for creating a competency-based program and included structuring the program in three levels; some systems engineering was included in all levels. The competencies that underpinned this program were developed based on surveys of subject matter experts at many of the federal agencies. These surveys, which were based on DoD Directive 5000 (“The Defense Acquisition System”), identified how often and how important particular project management and systems engineering activities were. The competencies resulting from these surveys were mandated by the Office of Federal Procurement Policy in 2007.

The Department of Veterans Affairs (VA) was one of the agencies that was out in front with the implementation of FAC-P/PM discussed above. In 2008, the VA formed an Acquisition Academy to address the growing acquisition workforce challenges they were facing; a program management school was created within that academy that tailored the FAC-P/PM to the VA mission and work force. It too integrated project management and systems engineering into a competency-based program, was targeted at those involved with the smaller and less complex projects, and was structured in three levels with some systems engineering at each level. Post-training metrics indicated that students returned to their jobs able to successfully complete projects they otherwise would have struggled with or failed.

The actions taken in this example to increase integration included:

• Create integrated certification for program managers that drew on both program management and systems engineering standards to raise program manager awareness of systems engineering.
• Provide training to project and program managers on a widespread basis, regardless of the size of their projects or programs.
• Provide multi-tiered certification system to help increase the depth of understanding about the integration issues between program management and systems engineering.
• Capture successful practices and insights and disseminate them across multiple locations.

Editor’s note: It seems that many complex projects and programs could implement the above actions effectively and efficiently at low cost. Given the research base and results of this book, it seems that serious consideration should be given to doing this.

The third case study involved integrated software and program management at the Nationwide Mutual Insurance Company, one of the largest and most diversified financial services companies in the United States. The company provides products such as retirement planning, auto and home insurance, farm owner insurance, and commercial lines insurance to end consumers and intermediaries. Insight at Nationwide was strongly driven by the adoption within senior IT executives of a “growth” versus a “fixed” mindset, inspired by Carol Dweck’s (2006) book, Mindset: The New Psychology of Success. Traditional program management focuses on planning, change control, and periodic status reporting. Agile software development focuses on discovery, short learning cycles, visual management, and daily huddles. These two perspectives are set up to be in conflict with each other. To correct these differences, the company undertook a transformation in how software was developed, and the roles and expectations of all those involved with the process. A new organization was created, the Application Development Center (ADC), with a focus on technical excellence and process discipline.

The ADC built upon the successes of the original agile teams, while incorporating the supporting roles, including the program manager, directly into the model. Standardized role definitions and behaviors, referred to as “standard work” were defined for everyone. Accountability and reinforcement systems were put in place. All of these things were put in place. The deliberate intention was to put in place a program that learns and adapts, continuously improving process and practices.

A specific software development method, Agile, was utilized, but with outcomes that ranged from significant success to disappointment. The cause of the variation in success was determined to be a misalignment between the program management organization and the technical functions. The company embarked on a number of change initiatives managed through an existing Lean Six Sigma improvement program infrastructure in the organization to transform how software was developed, including the roles and expectations of all those involved in the process, a focus on technical excellence and process discipline including definition of “standard work”, the development of a new mindset concerning collaboration and interaction, and the application of new metrics to evaluate performance. Not only did quality and productivity improve significantly, but also the engagement of the employees and the atmosphere of collaboration between program management and technical functions was markedly improved and sustained as a result.

The actions taken in this example to increase integration included:

• A change program to improve management integration with developers, leveraging existing change agents and infrastructure to roll out change initiatives across the company.
• Tracking down the root cause of inconsistent execution of agile across the organization: a lack of process discipline and an attitude of exclusion between program and project management and the software developers.
• Redefining the program management orientation to better align with the agile development approach.
• Creating the Application Development Center with a focus on technical excellence and process discipline.
• Creating standard work for managers explaining how they should interact with the development teams, including reporting and priorities.
• Developing a new set of performance metrics for program managers to track development progress.

The fourth case study involved boosting productivity in BMW’s engineering department. A division-wide formal change program was implemented that involved a number of change projects. Top-down, large scale transformation projects tackled strategic, central themes. Bottom-up initiatives provided processes and method for enhancing value creation by individuals and teams. An outreach program encouraged participation by each member of the organization to achieve a new mindset focused on collaboration. Engineering productivity improved dramatically, and importantly the company avoided disruption during the global economic crisis, expanded its product line with no additional resources required, and was able to achieve its strategic objectives.

This case study describes a change program that unfolded over the period from 2007 to 2012. It was managed by a program management office and involved a large number of individual projects to bring about the overall vision of the BMW Group. The integration of the many projects, most of them technical, resulted in a more integrated program management and engineering environment. The Engineering Division created an engineering transformation program titled the E3 Program that had five major aspects. The E3 Program was put into place to transform the engineering organization to a state in which it would be able to support the very ambitious corporate strategy including an expansion of the model range, increase in vehicle quality, and reduction of engineering cost per vehicle, given a stable number of employees. The transformation activities addressed three top-level Challenges, expressed in the name “E3”:

• Exhilarating products. How could the engineering division be closer to the customers’ needs? How could engineering activities better focus on what really creates value for the customer, and ultimately increase customer satisfaction and grow the customer base? How could the company change some fundamental attitudes concerning “what the customer wants”, and how could the company technically deliver through its products?
• Efficient processes and structures. How could the company develop better products, in less time, and for less money? How could the company develop more products, and more exciting products, and improve productivity and innovation without driving up cost and lead time?
• Emotions and team spirit. How could the company develop openness and willingness for change? How could the company assure that employees take ownership of and responsibility for change? How could the company enable managers to be effective leaders of change? How could the company maintain an attractive and inspiring work environment, as well as keep everyone employed while at the same time drastically improving productivity?

The actions taken in this example to increase integration included:

• Senior leaders provided the vision and resources for the change and were personally involved in supporting it.
• The company and division strategy were communicated to all employees in special meetings and used to define the change projects.
• A PMO managed the change program and provided resources to enable local leaders and employees to implement the change. An internal professional change management group with change agents, toolsets, and a model for change assisted the PMO.
• Projects included both top-down and bottom-up change initiatives to engage the entire workforce.
• The scope of changes addressed product, processes, tools, communications, leadership, and culture.

TRAINING

Systems Engineering 5-day course

Reduce time and cost, delight stakeholders, and reduce risk in technical projects using sound principles and the best practices.

Learn more

Editor’s note: Dealing with change is a constant requirement in today’s business environment. Business processes must incorporate strategies to deal with change successfully. To that end, the actions noted above might be considered by leaders involved in all complex projects and programs. It is apparent from this example (among others) that change management is a critical driver in obtaining successful business results. (Note that the previous issue of PPI SyEN (PPI SyEN 68, August 2018) included summaries of several change management resources in the SE Publications section.)

The final case study presented in Chapter 14 of The Book involves delivering the world’s most complex inner-city infrastructure program, Boston’s “Big Dig”. Almost 30 years in the making, the front-end planning phase began in the 1970’s, the first shovels went into the ground in the early 1990’s, and the program was substantially completed in 2007. The program was complicated by the fact that it was staged as a fast-track program where initiation was beginning on some projects while closure had been achieved on other parts of the program.

The Big Dig, like most large-scale infrastructure programs, grew from a vision of a small group of people who saw a city in need of revitalization. The program had numerous challenges, including working in one of the most congested urban areas in the country, and coordinating more than 132 major work projects, 54 major design packages, thousands of subcontractors, more than 9,000 processes and procedures, and organizing more than 5,000 workers during its peak years of construction. The Big Dig was not always on schedule and budget; however, it did eventually deliver one of the most complex, inter-city tunneling efforts in the world.

Systems engineering was used at the Big Dig to integrate the various components of the 135 major projects in the program and provide a holistic view to the complex engineering systems and requirements. One of the important roles of systems engineering was analysis of the safety failure modes for all critical infrastructure projects.

One of the most important mechanisms for problem solving, conflict resolution, and the reduction of tension among participants on the Big Dig Program was through the Partnering Process.[1] The concept of partnering was first utilized by DuPont Engineering on a large-scale construction project in the mid-1980’s, and the U.S. Army Corps of Engineers was the first public agency to use partnering in its construction projects. Partnering is now widely used by numerous government and construction entities around the world.[2] It involves an agreement in principle to share risk and to establish and promote partnership relationships. On the Big Dig Program, partnerships were used to improve schedule adherence, quality, safety, and performance, as well as to reduce risk, costs, claims, disputes, and litigation. Partnering on the Big Dig Program was initially implemented in 1992, primarily on construction projects, but its success in construction later led to its use in design contracts, community groups, and the development of internal and interagency partnerships. Almost 100 partnerships existed on the Big Dig Program, based on contract values ranging from US$4 million to a half billion.

The actions taken in this example to increase integration included:

• Giving leaders shared roles (for example, the engineering manager/deputy program manager) to encourage an integrated perspective.
• Directing project managers and engineers to work toward shared goals with specific direction taking into account the perspectives of other disciplines in making decisions.
• Introducing an IPO and integrated team structures.
• Establishing comprehensive risk management and quality assurance integrated into the component projects.
• Integrating performance reviews that included overall technical compliance with scope and schedule specifications, start-up, testing and test data, and approval activities at several levels prior to the acceptance of and payment for any contract.
• Providing rewards for innovation to the team rather than to individuals.
• Creating partnering provisions in contracts and having periodic partnering sessions to provide common awareness and commitment across the program.

Summary of Chapter 14: Successful Change Programs that Improved Integration

Five case studies of successful change programs that improved integration were reviewed. They were selected from others reviewed during the five-year research phase of development of the book because they demonstrate a diverse set of challenges and approaches to improving integration and collaboration across management and technical functions. One observes significant differences in the degree of urgency to accomplish the change, the scope of the change effort, and the approach taken. Each case study illustrates deliberate, systemic approach to improving elements of integration in the organization. Some elements of the Integration Framework developed in Chapter 6 of The Book were observed in all five of the case studies. They demonstrate how these elements were applied successfully across a range of organizational and program settings.

In summary, in consideration of the knowledge and insights made available in Chapter 14 of The Book, it is both amazing and terribly unfortunate that many complex projects are not more successful and effective in achieving the results anticipated by stakeholders. It’s not that we don’t have the information required to be successful and effective; it’s that we don’t find and apply the information and knowledge that is available as well as we could. This concern also (not surprisingly) involves people – how can we get people to work together and support one another? Much knowledge and many insights concerning that which we might do have been provided in this chapter. Some ideas that seem relatively easy to implement and apply have been highlighted above. How many complex projects will take advantage of this information and make investments to further strengthen and improve the application of systems engineering? What do you plan to do as a result of taking the time and effort to read this review of Chapter 14 of Integrating Program Management and Systems Engineering? What can we do as the systems engineering community to take a giant step forward in our practice of systems engineering? Who are the leaders who will provide the vision, direction, and motivation to make it happen? How do we garner their attention, commitment, and support for our desperate situation?

Food for Thought

1. Which of the five case studies relates the challenges to integration that you have experienced in your own workplace? What specific elements of the case study are most relevant to your situation?
2. Suppose that you have been requested to consider options for improving the integration of program management and systems engineering in your organization. Select one of the case studies as a model for the challenges that your organization faces. Identify the following:
3. What is the general situation of the organization and the particular integration challenge you face?
4. What principle(s) of integration would you propose applying to resolve the challenge? What aspects of The Book, Integrating Program Management and Systems Engineering, can be used and how might they be deployed?
5. How would you approach the implementation of these integration principles into your organization?
6. What challenges to implementation would you expect to encounter, in the near term and in the longer term?

References

Dweck, Carol. Mindset: The New Psychology of Success. New York: Random House, 2006. Available at https://www.amazon.com/Mindset-Psychology-Carol-S-Dweck/dp/0345472322/ref=sr_1_5?s=books&ie=UTF8&qid=1532290660&sr=1-5&keywords=Mindset%3A+The+New+Psychology+of+Success&smid=ATVPDKIKX0DER

Fosberg, Kevin, Mooz, Hal, and Cotterman, Howard. Visualizing Project Management. Hoboken, New Jersey USA: John Wiley & Sons, 1996. Available at https://www.amazon.com/Visualizing-Project-Management-Frameworks-Mastering/dp/0471648485/ref=sr_1_1?s=books&ie=UTF8&qid=1532290736&sr=1-1&keywords=Visualizing+Project+Management

Markert, Charles. The Partnering Facilitator. See http://www.thepartneringfacilitator.com/ 

Tobin, James. Great Projects: The Epic Story of the /Building of America, from the Taming of the Mississippi to the Invention of the Internet. New York: Free Press, 2001. Available at https://www.amazon.com/Great-Projects-Building-Mississippi-Invention/dp/0743210646/ref=sr_1_1?s=books&ie=UTF8&qid=1532290793&sr=1-1&keywords=Great+Projects%3A+The+Epic+Story+of+the+%2FBuilding+of+America%2C+from+the+Taming+of+the+Mississippi+to+the+Invention+of+the+Internet

Young, Ralph R. Project Requirements: A Guide to Best Practices. Vienna, Virginia USA: Management Concepts, 2006. Available at https://www.amazon.com/Project-Requirements-Guide-Best-Practices/dp/1567261698/ref=sr_1_1?s=books&ie=UTF8&qid=1532290592&sr=1-1&keywords=Project+Requirements%3A+A+Guide+to+Best+Practices

[1] See Partnering in the Construction Industry: A Code of Practice for Strategic Collaborative Working, for an in-depth presentation concerning how to utilize the Partnering Process. Available at https://www.amazon.com/Partnering-Construction-Industry-strategic-collaborative/dp/0750664983/ref=sr_1_2?ie=UTF8&qid=1532203157&sr=8-2&keywords=partnering+in+construction

[2] The author recommended use of the Partnering Process when employed by Northrop Grumman Information Technology Defense Systems Group for a program at the U.S. State Department. The facilitator selected to assist with implementing the Partnering Process was Charles Markert. The implementation was highly effective. See www.thepartneringfacilitator.com

Author

Ralph Rowland Young