Copyright © 2019 by Randall C. Iliff. All rights reserved.

Abstract

This is the first article in a five-part series devoted to the integration of Program Management (PM) and Systems Engineering (SE) conduct. In this series we share why PM and SE are both necessary on any development effort; make a case for integration as a very attractive investment opportunity; and propose an Integration Competency Index derived from the multiplicative product of skills in three primary dimensions of integration.

This installment sets up the discussion and introduces three dimensions we’ll call Hands, Head, and Heart. We also introduce the concept of an Integration Competency Index that can be used to assess program performance and identify opportunity for improvement.

The next three articles in the series discuss the Hands, Head, and Heart integration dimensions respectively, the final installment wraps it all up with information about the Integration Competency Index and a call to action.

Introduction

Engineering programs have created wealth, power, and societal consequences – good and bad – for thousands of years. Every region of the world can point to spectacular accomplishments throughout history. Civilization as we know it today can be attributed in large part to the cumulative history of those engineering programs.

Ironically, our collective survival has now become dependent upon the ability to successfully conduct engineering programs in response to increasingly complex societal needs brought on by prior engineering programs. The impact of failure is measured in lives as well as cost and schedule. Even when people are not directly harmed, wasting scarce resources imposes an inevitable penalty somewhere else.

When engineering and execution align effectively, great things can happen. When they don’t, the consequences can be catastrophic.

You may not think of Pixar as being in the engineering program business but consider this quote from Co-Founder and President Ed Catmull: “Most of our people have learned that it isn’t helpful to ask for absolute clarity. They know absolute clarity is damaging because it means that we aren’t responding to problems and that we will stop short of excellence. They also don’t want chaos; if it gets too messy, they can’t do their jobs.”1

Any System Engineer or Program Manager will immediately recognize the delicate balance involved in moving ideas towards reality. At first the idea exists by itself. To go anywhere, that idea needs execution. Execution requires direction, which in turn requires reduction of the original idea in some way towards specific practice.

Catmull’s comment nicely highlights the balance required for success – enough creative room to address genuine development needs and respond to issues, and enough structure that efficient progress can be made towards an intended outcome. By tying both to the single objective of delivering an excellent result, not the narrow and occasionally conflicting objectives of each area, the effectiveness of the overall program remains the measure of success.

What happens though when unproductive tension is present, or when these two critical functions are not operating in ways that match the actual needs of the task? Perhaps the most vivid example is that of the NASA Challenger and Columbia accidents.

Diane Vaughan writes in her book concerning the 1986 Challenger disaster: “According to the research of Romzek and Dubnick, during Apollo the space agency relied on professional accountability: control over organizational activity rested with the employees with technical expertise.”2 “During the Apollo era, according to space analyst Howard McCurdy, NASA had a “pure” technical culture appropriate for the engineering of unruly technical systems.”3 In the 1970s that culture began to shift, partly in response to declining budgets and changes in the view of government/contractor relationships, to a much more structured and bureaucratic one.

“Top NASA managers were absorbed with “myth managing”: attaining legitimacy (and thus resources) by projecting and living up to a cultural image of routine, economical spaceflight.”4 “And at the bottom of the launch decision chain, working engineers were making risk assessments in a transformed NASA culture in which bureaucratic rules and procedures were a major preoccupation; and cost, efficiency, and production deadlines were a taken-for-granted aspect of work.”5 “Project Managers and engineers alike were burdened with the procedural and paperwork demands of central clearance as they responded to the organization’s burgeoning nontechnical administrative apparatus.”6

The Challenger accident, and later the loss of Columbia, arose from a complex set of technical, social, and political circumstances, but an unmistakable sub-context to both is that the methods in use no longer were aligned to task reality. Two inexorably tied roles, project management and engineering, had been driven further and further apart by the movement towards bureaucracy.

Despite enormous success during the Apollo era, the NASA culture was gradually changed into one where cost and schedule were no longer subordinated to safety. That such a loss can occur in one of history’s preeminent intellectual bodies is clear warning that no company, market, or body should feel safe. It is far easier to disrupt an effective model like NASA or Pixar than it is to establish and protect one.

Integration as Investment

Clearly there is enormous untapped opportunity to improve the outcome, efficiency, and predictability of engineering programs. Further, this opportunity can be found anywhere development is required as part of the effort, regardless of market, region, or scale. Most of the insight needed to capitalize on this opportunity already exists, there are emerging pockets of excellence that demonstrate what is possible, yet most engineering programs struggle with avoidable issues.

That represents a stunning level of untapped opportunity, given that the ability to consistently deliver engineering program success has never been more vital. As a result, the integration of Program Management (PM) and Systems Engineering (SE) effort may well be the most attractive investment available to your organization.

When the definition (SE) and execution (PM) roles are aligned, the results can be orders of magnitude more effective than when the groups are in tension with each other. Even seemingly minor improvements to cost and cycle time during development are a good thing, particularly when that result is coupled with improved technical quality and reduced risk.

Let’s be honest here – this attractive opportunity isn’t free money, or something created as a result of integration.

The benefit arises instead from the simple act of repairing a fundamental defect in the development approach. When PM and SE are not operating as a single “system of systems” team, the cognitive disorder that results will inevitably harm the effort, and in some cases rises to a level that causes the effort to fail outright. PM-SE Integration savings result from the money and time that are no longer thrown away fighting self-inflicted issues.

That’s an important realization, since it means that unless you already have a well-integrated PM and SE team, you are currently paying a hidden penalty on all of your development effort. Once you realize that you are already paying, over and over again, the wisdom of investing in a solution becomes self-evident.

Three Domains

For this discussion we’ll slice the overall PM-SE integration task into three dimensions, each of which has a different set of needs and characteristics to manage. The terms “Hands, Head, and Heart” offer an easy way to remember the nature of, and distinctions between, these dimensions.

First, all development effort has at least some subset of “just do it” tasks that are well understood and simply a matter of executing efficiently. There is no upside to everyone reporting travel expenses in a different way, just pick something, standardize it, and refine it over time. Likewise, stressing over a standard 12-volt power supply has little upside value. These tasks require only supervision, and integrate the “Hands” of the organization.

Second, by definition all development effort has at least some subset of “figure out what to do” tasks. These tasks engage the “Head” and require management. For effort in this domain people aren’t told what to do and how to do it, instead they must be given an objective and the resources needed to reach that objective.

Our final dimension, “Heart” speaks to the alignment of motivations. It’s not enough to simply agree on tasks, there must be a common passion if your development effort is going to achieve great things. Since all of these dimensions interact as a single system, it is the multiplicative product of skill in each of these (not the sum!) that determines the organization’s degree of integration excellence.

It’s Time to Demand Better Development Results

We don’t think properly of the true potential that development excellence offers. It’s hard to imagine what development excellence looks like if you haven’t really seen it before. An excellent development project isn’t necessarily one with the lowest cost design cycle, nor the fastest one, nor the one that spins off the most intellectual property.

Like most systems, there is a composite figure of merit involving many competing dimensions of “success” that must be considered if comparisons are to have meaning. For this discussion excellence is defined as a function of Hands, Head, and Heart. For lack of a better term, I’ve called the resulting figure of merit for PM-SE integration an Integration Competency Index.

The Innovation Index doesn’t run from zero to thirty. Instead, when each of the three task dimensions we’ve mentioned is scored on a zero to ten basis and multiplied the best possible Integration Index score is 1,000. Using the multiplicative product scoring approach, a low score in even one category will immediately be seen as causing major damage to the entire development system. As an example, a ten on hands and head combined with only a two on heart gives a score of 200, implying that 80% of the value has been lost. (Adding the scores would result in 22 out of 30, implying a much less critical 25% loss.)

This balancing act among dependent variables explains why simple start-up companies appear to operate so efficiently at first and then fade. They bring strength in Heart and Mind that overcomes inefficiency of Hands (for a while), then fall prey to the increasing scale of effort that is required. This also explains why large, well-funded operations fail to deliver against potential. No amount of efficiency makes up for consistently doing the wrong things for the wrong reasons.

What is less obvious, however, is why such enormous opportunity has gone untapped for such an extended period of time. Regardless of the reasons, the resulting potential energy has built up to a point where industry change will propagate rapidly once benefit has been compellingly demonstrated.

The world of production has matured to the point where we expect perfection and come very close to achieving that level in practice. Who today would accept 5% rework on a production line?

The world of development is also maturing, but that maturity profile lags production by decades. Perfection in development cannot arise from absolute repeatability of output, instead it arises from the ability to repeatably identify an ideal solution to any problem set. No one ever quite reaches perfection, but it’s clear that there is a lot more room for improvement in the development arena!

Who tomorrow will be willing to burden their organization with only a 200 out of 1,000 Integration Competency Index?

What’s Next?

In the next installment we’ll focus on the Hands dimension. This is the simplest of the three domains, and each of these actions have a specific “ideal outcome” from which variance can be assessed and managed. Once rules are established – and known to all – independent supervision within each group is usually sufficient to ensure consistency. This dimension offers a good place to start making improvements, and we’ll share some ideas in the next installment that you may find useful.

Following that installment, we’ll address Head, then Heart. In the final segment, we’ll provide more information concerning how the Integration Competency Index is determined and how that information can help your organization optimize the return on integration investments!

List of Acronyms Used in this Paper

PM	Program Management
SE	Systems Engineering

Acknowledgements

The idea of “hands, head, and heart” originated in classroom conversations about the distinction between supervision, management, and leadership. During a course in Hong Kong many years ago, a student commented that her supervisors just talk to her hands, whereas a leader talks to her heart. That struck me as a profound observation worth sharing, and the idea of managers focusing on the mind arose as a natural extension of that evolving conversation.

Reference

McKinsey Quarterly Interview, March 2016, Staying one step ahead at Pixar: An interview with Ed Catmull

2 Vaughan, Challenger Launch Decision, p. 211
3 Vaughan, Challenger Launch Decision, p. 209
4 Vaughan, Challenger Launch Decision, p. 212
5 Vaughan, Challenger Launch Decision, p. 215
6 Vaughan, Challenger Launch Decision, p. 212

[The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA Author: Diane Vaughan Publisher: University of Chicago Press, Chicago and London Publication Year: 1996]