To the program managers, chief systems engineers, project managers, systems engineers, and reformers in academia, corporations, government, professional societies, and research institutions who are helping to advance integrated approaches to successfully deliver value through well‐executed complex programs.

Eric S. Rebentisch

Marvin R. Nelson

Stephen A. Townsend

Edivandro Carlos Conforto

Virginia A. Greiman

Eric S. Norman

Elizabeth “Betsy” K. Clark

Tina P. Srivastava

Kenneth M. Zemrowski

Akio Mitsufuji

Alan S. Harding

Bohdan Oppenheim

Brian Maddocks

Bryan Moser

David Pearson

Deborah Nightingale

Dennis Van Gemert

Eric Nicole

Guruprasad C. Vasudeva

Josef Oehmen

Kambiz Moghaddam

Mark A. Langley

Michael O'Brochta

Stanley I. Weiss

Thomas Paider

Timothy Wiseley

Documented knowledge and associated practices exist as far back as the earliest civilizations. Some of the first written documents are speculations about what is known and what isn't. However, because of the way the English language works, the word “knowledge” stands for a fairly large variety of “things.” We talk about mathematical theorems and computer algorithms as being knowledge essential to math and computer science. But we also talk about the knowledge of a skilled surgeon or carpenter—a type of knowledge that is quite a different thing than formulae and completely codified signals.

Philosophers, beginning with Aristotle, marked this distinction by breaking the word knowledge into two distinct categories: know‐what and know‐how. The former focuses on knowledge that is self‐contained, codified, and cheap and easy to transmit from one knower to another. The latter is about the type of knowledge that is much closer related to skills, expertise, talents, and practices. This latter type of knowledge is much more contextual than know‐what, is difficult and sometimes impossible to codify, and is expensive and time‐consuming to transmit, if it can be done at all.

Most of the knowledge we work with in our daily lives is know‐how. It spans such mundane tasks as getting to work to the actual tasks and work we perform as part of our career activities. However abstract it may seem, all these activities are embedded in practices. So what does this actually mean? Simply that know‐how does not stand alone. It becomes embedded in our habitual ways of acting and working, and is embodied in our memories, habits, and psychological pathways. Practices are composed of vocabularies, work habits, accumulated historical stories, interfaces and entanglements with technologies, and our deep understanding as to the best way to do things.

This shared jumble of activities and words, emotions, and tacit memories allows practitioners in the same field to rather quickly understand one another and allows them to work together in ways that would be almost impossible if practices were not to some extent similar. I have seen many examples of this in my work as a consultant focused on knowledge development and transmission. For example, I once worked with oil riggers working in the North Sea who were being temporarily transferred to the Gulf of Mexico in order to teach the workers there some new methods they had developed. Vast distances in culture, language, and physical appearances melted away when it came to discussing and doing the actual rig work. Both groups' oil rig practices were enough alike to allow this transfer to be accomplished with little friction.

On the other hand, people working in different areas of practice probably won't be as fortunate as the oil rig workers in transferring knowledge. Tacit knowledge is “sticky” within its own arena and can be expensive and difficult to share outside of its arena. That is a primary challenge with knowledge work in general, and the particular challenge addressed in this book. How do you successfully bring together two (or more) different ways of knowing and doing to accomplish an important task?

Moreover, practices do not, and should not, stand still. New technologies and new accumulated knowledge of various types are continuously being developed that have the capability to alter and improve practices. Sometimes entirely new practices emerge from the absorption of these new techniques. Other times, older practices evolve into newer ones without any central force acting upon them—not wildly dissimilar to biological evolution. Think of how the field of cybernetics, developed during World War II, has evolved in the past 75 years or so, losing its name and transforming into several different and distinct practices, one or two of which are the focus of this book.

My own field of knowledge management was primarily the synthesis of information management and process management mixed in with the emerging personal computer technology tools in the late 1980s. This was a heady mix leavened with the ideas of Peter Drucker, Alvin Toffler, Daniel Bell, and several other popular prognosticators of the blossoming “knowledge age.” There was a need to develop a new practice to synthesize these tools and ideas, and this new practice, knowledge management, quickly developed. It brought forth eager practitioners who were quick to mix cases from business schools, journalist's stories, and consulting advice. This was melded with various methods and frameworks to help organizations get started, along with metrics, technologies, incentive policies, and all the other tools that make practices applicable and workable. Within a decade of getting underway, the practice was established in over 300 organizations and it is still, as I write, a lively and established activity.

But it, too, will evolve by incorporating new ideas, perspectives, and tools to remain relevant to society and the economy. Practices in the past that failed to evolve, or fought off any attempt at change, almost always disappear eventually, although not without serious costs to those concerned.

Many practices, like the more formal disciplines found in universities, do not exactly embrace substantive change to the core assumptions. Every professor knows the perils of doing cross‐disciplinary work, and students pay the price by not being taught what could best help them to understand the world and its ways. Economics is a good field to look at in this regard. The field was very slow to bring the insights of psychology and sociology into its models, to say nothing of considering knowledge as a factor of production. Even now the standard textbooks shy away from these types of insights even though two Nobel prizes in economics have gone to non‐economists (Herbert Simon and Daniel Kahneman) who have forced the field, through the power of their ideas, to adapt somewhat to them.

So, with these challenges, this book has taken on the task of helping two important practice areas work together in a more seamless fashion. Program management and systems engineering have each existed as formal disciplines for less than a century. Each has extensive bodies of know‐what in their standards, publications, and tools with structured certification processes that take practitioners years to demonstrate mastery. But even more importantly, they are critically dependent upon deep reserves of know‐how that is embodied within their most experienced and skilled practitioners. The difference in capabilities between the experienced “A” team and the less experienced “B” team or even whether a few high‐performing individuals are available to contribute can quickly determine whether a complex program will be a success or a failure. Transferring this know‐how from one generation to the next within each practice area can take the substantial part of a career—despite the fact that they are in the best cases using the same practices, speaking in the same terms, and working on the same problems. Imagine the challenge of transferring know‐how when the know‐what is still fuzzy and perceived differently across the discipline. The merging of know‐how between the two disciplines around a common challenge is even more imposing—but ultimately necessary to success.

“Nothing comes from nothing” the philosophers proclaim. All new ideas build upon other, older ideas. New knowledge emerges from orderly processes such as science or more typically from the fusion, merging, fighting, or embracing of older knowledge. It eventually becomes codified into know‐what and new practices are then built upon it. It has always been so and will likely continue this way as long as this remains an inherently social process.

This book is a wonderful attempt to see what two established and valuable disciplines have to offer to one another, to their customers, and to society. What may come out of it has the potential of bringing a harmonious understanding of how to deliver better solutions more successfully. This could be a great blessing to all concerned so let us congratulate the authors of this first attempt and hope for its success.

In 2011, International Council on Systems Engineering (INCOSE) and Project Management Institute (PMI) allied to enhance, foster, and enable collaboration between program managers and systems engineers. Our organizations believed that the two disciplines had developed silos between them that inhibited collaboration and that we needed to change mindsets to remove such barriers. We issued a call to action through a joint whitepaper, Toward a New Mindset: Bridging the Gap Between Program Management and Systems Engineering (Langley, Robitaille, & Thomas, 2011), that identified the following challenge:

While program management has overall program accountability and systems engineering has accountability for the technical and systems elements of the program, some systems engineers and program managers have developed the mindset that their work activities are separate from each other rather than part of the organic whole (p. 24).

Regardless of who was in authority, whose inputs were more respected and accepted, or who better understood the path forward, the whitepaper put forward the proposition that silos focused each discipline on advancing its own approach toward delivering solutions to meet customer needs. The whitepaper went on to say:

Historically, program managers and systems engineers have viewed the stakeholder problem entirely from within their own disciplinary perspectives…. As a result, the two groups have applied distinctly different approaches to the key work—managing the planning and implementation, defining the components and their interactions, building the components, and integrating the components (Langley et al., p. 25).

Since the whitepaper's publication, our subsequent engagements with stakeholders have anecdotally confirmed the existence of the issues we identified to varying degrees. That led our organizations to formally evaluate the level of integration and collaboration between program managers and chief systems engineers. Partnering with MIT's Consortium for Engineering Program Excellence (MIT CEPE), our organizations conducted a series of studies over three years exploring the following questions:

• How integrated were the practices, tools, and approaches used by chief systems engineers and program managers? Did critical links exist where they were needed? Were common practices, such as risk management, managed in intersecting or parallel paths? Were practices, tools, and approaches evaluated and benchmarked to identify opportunities for improvement?
• How formalized were the roles, responsibilities, and competencies of each discipline? Did each discipline perform unique functions or were there functions that both disciplines performed?
• How well did the chief systems engineer and program manager collaborate with each other? Did any tension exist in their relationship and, if so, how did that tension affect their ability to work together?
• In organizations with strongly integrated practices and low levels of interdisciplinary tension, what distinguishing characteristics could be identified? How did the disciplines achieve integration and collaboration?
• In organizations with weakly integrated practices and high levels of tension that affected collaboration, what distinguishing characteristics could be identified? What were the barriers to achieving integration and collaboration?
• Does integration and collaboration demonstrably impact program performance?

The research helped to validate the need to move toward a new mindset:

This new mindset recognizes that there cannot be two separate views of the stakeholder problem, but rather a single one that incorporates all elements of the program…. What emerges is an understanding that all of the work is relevant to both groups, and that the delivery of stakeholder value requires an appropriate contribution from both areas of professional expertise (Langley et al., 2011, p. 26).

Our research and our stakeholder engagements have uncovered active efforts to move toward this mindset. Efforts are starting at the program level as individual program managers and chief systems engineers join forces to improve their program outcomes. These efforts are often not deliberate though. As two colleagues—one a program manager and one a chief systems engineer in the same company—shared at the 2015 INCOSE International Symposium, “dumb luck” helped them uncover that each had a piece of the solution that the other needed. The relationship they forged brought about change that established better alignment, integration, and collaboration. But as one of them left the organization, they feared that the change they started did not have sufficient roots beyond their relationship to be sustained. In other words, alignment, integration, and collaboration had not become embedded in the organizational culture, processes, and systems as critical components. Alignment, integration, and collaboration were not measured or reported to senior leadership, and thus their value to the organization was hidden from top leadership.

So beyond the premise and beyond the abilities of the two disciplines to change on their own, senior executives within corporations and government also must change their mindsets. They must see the connections between strategy, benefits, performance, and capabilities, and work within their organizations to remove gaps and improve performance. They must recognize the value their organizations could gain from even incremental efforts to reduce wasted investments due to poor program execution. They must ensure their organizations learn from examples of success and failure, such as those presented in this book, and utilize that learning to continuously improve their own practices. Most importantly, they must stand with their program managers and chief systems engineers and lead the change toward a new mindset—the focus of this book.

Reference

1. Langley, M., Robitaille, S., & Thomas, J. (2011). Toward a new mindset: Bridging the gap between program management and systems engineering. PM Network, 25(9), 24–26.

This book results from a significant collaborative effort involving many individuals and institutions during the course of the last five years. The comparison of this collaborative effort to a program is appropriate. It has defined objectives, many stakeholders, and a stream of benefits generated over time. This book is but one project producing benefits for the overall effort.

Like any program, multiple stakeholders operate in a number of different functions to produce the overall benefit. Each plays a unique role that collectively produces something that they individually could not produce. Some of the contributions are managerial, some are technical, and others are enabling. Upon reflection, over the course of the last 16 months during which this book has been in various stages of development, many have contributed. This is an attempt to acknowledge their efforts in what has become a fairly dynamic project. Some of those who started the project were unable to complete it or completed their parts early and went on to other things. Others joined partway through, or even close to the completion. Others have been part of the project from start to finish. They represent participation from a broad spectrum, and truly exemplify the spirit of this book: bringing together multiple perspectives to create something unique and noteworthy. It is not intentional that anyone who contributed to this effort would not be recognized, and all contributions and involvement have been deeply appreciated whether acknowledged here or not.

The overall effort was directed through the PMI/INCOSE/MIT Alliance team, which included Randall Iliff (INCOSE lead), Stephen Townsend (PMI lead), and Eric Rebentisch (MIT lead), with Tina Srivastava, Kenneth M. Zemrowski, Jack Stein, Ashok Jain, Richard Gryzbowski, and Eileen Arnold, all from INCOSE, and Keith Rosenbaum from PMI. This group helped to define the vision for the book, helped organize and enable the research activities that supported the knowledge base for the book, organized the dissemination of the findings at conferences and other venues, and assisted with the development and publication. They also helped to identify and recruit the numerous contributors to the book from within their respective professional communities. Both PMI and INCOSE mobilized their network of chapters and chapter leads to solicit subject matter expert and practitioner participation and contributions to this book. Notably, Jean‐Claude Roussel, the INCOSE EMEA Sector Director, Claes Bengtsson from the INCOSE Swedish chapter, and Jack Stein from the INCOSE Michigan chapter helped to recruit contributors to this effort.

Playing central roles in creating the knowledge foundation for this book were Maria Pacenza from PMI Market Research, who conducted the first integration survey and presented the initial findings. Edivandro Conforto and Monica Rossi performed in‐depth analysis of the first integration survey data, and followed up with additional interviews and synthesis of findings to clarify what is meant by integration between program management and systems engineering. Thomas Reiner and Lucia Beceril conducted follow‐on confirmatory research as part of their graduate studies to further refine and validate the concept of integration. Additional perspective in shaping and directing the book content came from Randall Iliff, Jeffrey Thompson, Ann Bachelor, Claude Baron, Samuel Boutin, and Tomoichi Sato. PMI and INCOSE members Heinz Stoewer, James Armstrong, Brian Maddocks, Jeffrey Thompson, Randall Iliff, and Tina Srivastava helped to build awareness of program management and systems engineering integration's potential through their conference presentations, as did presentations by MIT researchers Josef Oehmen, Edivandro Conforto, and Eric Rebentisch.

The editors and contributors have been acknowledged in lists in the front of the book. They had formally designated roles in creating the content of this book. The editors created chapter drafts that form the basic structure of the book. The contributors provided significant and important content for those chapters. Their roles are in fact not so easily defined, as many of them filled in and took on the work that needed to be done to produce the book. While all their contributions provide the substance of this book and are greatly appreciated, two individuals played an outsized role and deserve additional mention for their contributions. Marvin Nelson filled the role of principal co‐editor of this book. In addition to writing chapters in the book, he also edited and integrated the entire manuscript of the book and did much of the detailed technical work that is necessary when publishing a book. Stephen Townsend wrote or played a significant role in writing a number of chapters in the book. Additionally, he provided essential leadership in shepherding the manuscript through the many steps and around potential pitfalls in the process to getting a completed manuscript. Both were critical to the completion of this process, and whose contributions are not adequately captured by their appearance in the lists above.

As the manuscript was taking shape, many subject matter expert reviewers from both PMI and INCOSE helped to review an early draft of the manuscript and provide feedback on its strengths, weaknesses, and omissions. Over one thousand comments were provided by these experts from North America, Europe and Asia, who provided good ideas, important insights, and in some cases the awareness of the need to change course or redo some sections. They were Bryan Pflug, Brigitte Daniel‐Alle, Alain Roussel, Jean‐Claude Roussel, Gary Smith, J. Robert Wirthlin, Med Ahmadoun, Laurie Wiggins, Liew PakSan, Linda Agyapong, Clement Yeung, Kambiz Moghaddam, Claes Bengtsson, Magnus Cangard, Timothy H. Wiseley, Dennis Van Gemert, Jörg Lalk, Cecilia Haskins, Timothy Ferris, Arie Wessels, Kenneth Zemrowski, Virginia Lentz, Joseph Dyer, Eduardo Flores, Heather Ramsey, Michael Morgan, and Garry Roedler.

Others provided essential support for this effort by enabling connections to people, content, or in the form of knowledge of how to write a book. Donn Greenberg (PMI Publications Manager) helped to facilitate initial contacts with Wiley and offered valuable advice on structuring agreements between the parties. Barbara Walsh (PMI Publications Department) facilitated the graphics design work for the book. Holly Witte and Bob Kenley from the INCOSE Publications Office provided assistance in enabling access to INCOSE content and in the formal INCOSE review process. Paul Schreinemakers (Technical Director), Mike Celentano (Deputy Technical Director), and Kenneth Zemrowski from the INCOSE Technical Operations Team helped with the review and approval of the final manuscript by INCOSE. Margaret Cummings (Executive Editor at John Wiley & Sons) was an invaluable source of guidance and support throughout this project and was able to effortlessly identify a path forward through all potential challenges.

Because of the multistakeholder nature of this project, legal expertise proved to be essential. Elizabeth Levy (MIT Office of General Counsel), Marjorie Gordon (PMI Counsel), and Gita Srivastava, Stephanie Tso, and Laura Kalesnik (from Norton Rose Fulbright, INCOSE's Counsel) played key roles in structuring the legal frameworks for the book project and related collaborative agreements needed to allow the collaborative work to proceed. Peter Bebergal (MIT Technology Licensing Office) and Catherine Viega (from PMI) helped in making the intellectual property from their respective organizations available to the team to produce the final manuscript. Thanks also to Benjamin Lindorf, General Counsel, Institute for Defense Analysis, for his help in making the content of Chapter 7 readily available for this book.

Others provided essential enabling support to the project. Craig Killough (PMI Vice President, Organization Markets) supported the participation of Stephen Townsend and Marvin Nelson in the production of the book, which proved critical to its completion. Cindy Anderson (PMI Vice President, Brand) signed off on the co‐brand license with Wiley. David Long (Past INCOSE President) did the same for INCOSE. Jordon Sims (PMI Organization Relations Director) helped with engaging Larry Prusak to write the Foreword. Thanks also go to David Long (Past INCOSE President) and John A. Thomas (Past INCOSE President) for their enthusiastic support of the PMI/INCOSE Alliance and the origins of this particular project. Seemingly simple things can often make a big difference in the progress of a project. In this case, being able to meet as a team periodically to discuss, take stock, and make plans was very important to being able to maintain progress toward the end goal. Thanks to Jillian Moriera and the Sociotechnical Systems Research Center at MIT, Stephen Townsend at PMI, and Randall Iliff at BB7 each for hosting these important meetings of the team.

Last, but far from least, not a few families and those close to the authors and contributors were inconvenienced by “the book project” as writing was underway, and particularly around key deadlines. A special thank you goes to them for their patience and support during this project.

This is the product of many hands. As the saying goes, many hands make light work. In a complex project involving the coordination and reconciliation of a diverse set of inputs, that doesn't always seem to be the case. However, in the case of this book, it is correct to say that many hands make superior work—that is the message (and the experience) of this effort. Any errors or omissions, however unintentional, are the sole responsibility of the editor in chief.