Project Interface Management: Reducing Risk on Major Projects 1604271302, 9781604271300

Citation preview

PROJECT INTERFACE MANAGEMENT Reducing Risk on Major Projects

Michael J. Bible and Susan S. Bivins

Copyright © 2019 by Michael Bible and Susan Bivins ISBN-13: 978-1-60427-130-0 Printed and bound in the U.S.A. Printed on acid-free paper. 10 9 8 7 6 5 4 3 2 1 Library of Congress Cataloging-in-Publication Data Names: Bible, Michael J., 1966- author. | Bivins, Susan S., 1941- author. Title: Project interface management : reducing risk on major projects / by Michael J. Bible and Susan S. Bivins. Description: Plantation, FL : J. Ross Publishing, Inc., [2018] | Includes index. Identifiers: LCCN 2018025761| ISBN 9781604271300 (hardcover : alk. paper) | ISBN 9781604278026 (e-book) Subjects: LCSH: Portfolio management. | Risk management. Classification: LCC HG4529.5 .B533 2018 | DDC 658.4/04—dc23 LC record available at https://lccn.loc.gov/2018025761 This publication contains information obtained from authentic and highly regarded sources. Reprinted material is used with permission, and sources are indicated. Reasonable effort has been made to publish reliable data and information, but the author and the publisher cannot assume responsibility for the validity of all materials or for the consequences of their use. All rights reserved. Neither this publication nor any part thereof may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior written permission of the publisher. The copyright owner’s consent does not extend to copying for general distribution for promotion, for creating new works, or for resale. Specific permission must be obtained from J. Ross Publishing for such purposes. Direct all inquiries to J. Ross Publishing, Inc., 300 S. Pine Island Rd., Suite 305, Plantation, FL 33324. Phone: (954) 727-9333 Fax: (561) 892-0700 Web: www.jrosspub.com

Contents Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii About the Authors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Web Added Value (WAV)TM Materials. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii 1 Accelerating Change and the Context for Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 ​Brief History of Societal Evolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 ​Implications of Accelerating Societal Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 ​Developing the Strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 ​Introduction to Project Portfolio Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5 ​Introduction to Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6 ​Introduction to Large-Scale Capital Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.7 ​Infrastructure Examples of Large-Scale Complex Projects . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.8 ​Overview of Project Development Stage-Gate Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.9 ​Introduction to Systems Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.10 ​Designing and Developing Complex Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.11 ​Commercial Contracting Decisions and Factors Influencing Projects. . . . . . . . . . . . . . . . . 20 1.12 ​Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.13 ​References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2 Understanding Project Complexity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.1 ​Defining Complexity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2 ​Influence of Complexity on Project and Technical Management. . . . . . . . . . . . . . . . . . . . . 28 2.3 ​Project Complexity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.4 ​Interfaces, Interdependencies, and Interactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.5 ​Managing Stakeholder Complexity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.6 ​Setting the Stage for Stakeholder and Interface Management. . . . . . . . . . . . . . . . . . . . . . . . 45 2.7 ​Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.8 ​References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3 Interface Management Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.1 ​The Basics of Interface Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.2 ​Interface Concepts, Definitions, and Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.3 ​Interface Categories and Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.4 ​Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3.5 ​References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4 Basic Interface Management Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.1 ​Interface Process—Project Phases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.2 ​Determine Interface Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.3 ​Identify Interface Parties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 iii

iv

Project Interface Management

4.4 ​Identify Interface Areas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.5 ​Determine Interface Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.6 ​Identify and Plan Interface Items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.7 ​Monitor and Control Interface Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.8 ​Resolve Interface Issues and Items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.9 ​Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 4.10 ​References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5 Interface Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.1 ​Notional Project Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.2 ​Project Diamond Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.3 ​Interface Analysis Preparation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.4 ​Interface Analysis Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.5 ​Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.6 ​References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 6 Interface Management Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 6.1 ​The Project Management Plan Governs the Interface Management Plan. . . . . . . . . . . . . 125 6.2 ​Interface Management Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 6.3 ​Establishing the Interface Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 6.4 ​Interface Training. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 6.5 ​Integration with Other Project Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 6.6 ​Reporting Requirements and Key Performance Indicators (KPIs). . . . . . . . . . . . . . . . . . . 145 6.7 ​Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 6.8 ​References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 7 Interface Management Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 7.1 ​Driving Interface Management Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 7.2 ​Challenges to Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 7.3 ​Client/Contractor Interface Kick-off Meeting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 7.4 ​Interface Party KoM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 7.5 ​Interface Group KoM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 7.6 ​Transition from Establishing the Interface Management System to Identifying and Managing Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 7.7 ​Interface Control Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 7.8 ​Interface Control Working Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 7.9 ​Project Diamond ICD and ICWG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 7.10 ​Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 7.11 ​References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 8 Managing Interface Activity During Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 8.1 ​Basis for Interaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 8.2 ​Interface Group Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 8.3 ​Managing Interface Control Working Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 8.4 ​Interface Control Document (ICD) and Interface Register. . . . . . . . . . . . . . . . . . . . . . . . . 184 8.5 ​Interface Performance Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 8.6 ​Managing Interface Design and Agreement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 8.7 ​Project Plan Offsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 8.8 ​Interface Priority Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Contents

v

8.9 ​Interface Management Forums. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 8.10 ​Interface Design Reviews. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 8.11 ​Relationship Between Interface Forums and Design Reviews. . . . . . . . . . . . . . . . . . . . . . . 205 8.12 ​Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 8.13 ​References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9 Interface Management Verification and Closeout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 9.1 ​Project Assurance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 9.2 ​Interface Verification and Technical Compliance/Integrity Relationship . . . . . . . . . . . . . 212 9.3 ​Why the Need for Interface Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 9.4 ​Interface Verification and Quality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 9.5 ​Technical Compliance and Integrity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 9.6 ​Understanding Technical Compliance and Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 9.7 ​Technical Compliance and Integrity Model—Project Diamond. . . . . . . . . . . . . . . . . . . . . 226 9.8 ​Interface Closeout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 9.9 ​Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 9.10 ​References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Appendix A Interface Management Definitions and Terminology . . . . . . . . . . . . . . . . . . . . . . 235 Appendix B Coreworx, Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Coreworx Interface Management Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 B.1 ​Interface Data Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 B.2 ​Key Roles and Responsibilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 B.3 ​Managing Interfacing Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 B.4 ​Managing Interface Meetings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 B.5 ​Web-Based Interface Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 B.6 ​Interface Agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 B.7 ​Owner (Project Management Team) Involvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 B.8 ​Interface Agreement Closeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 B.9 ​Action Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 B.10 ​Responsibility Matrix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 B.11 ​Monitoring and Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Appendix C ABC Management of Project Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 C.1 ​Objective, Application, and Provision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 C.2 ​Project Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 C.3 ​Project Organization and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 C.4 ​Project Phases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 C.5 ​Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Appendix D Project Diamond Mandate for Execution Phase. . . . . . . . . . . . . . . . . . . . . . . . . . . 267 D.1 ​Project Owners. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 D.2 ​Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 D.3 ​Objectives and Success Factors for Project Diamond. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 D.4 ​Governing Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 D.5 ​Project Execution Framing Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 D.6 ​Project Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

vi

Project Interface Management

D.7 ​Stakeholder Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 D.8 ​Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Appendix E Project Diamond Execution Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 E.1 ​Introduction to the Diamond Project Execution Plan for DG3 to DG4 . . . . . . . . . . . . . . 273 E.2 ​Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 E.3 ​Project Development Plan and Contract Strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 E.4 ​Project Execution Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 E.5 ​Project Organization and Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 E.6 ​Project Strategy, Management, and Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Appendix F Project Diamond DG3 Interface Control Document. . . . . . . . . . . . . . . . . . . . . . . 285 F.1 ​Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 F.2 ​Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 F.3 ​Project Development Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 F.4 ​Project Diamond/Project Sapphire Interface Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 F.5 ​Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Appendix G Example Interface Management Closeout Report . . . . . . . . . . . . . . . . . . . . . . . . . 297 G.1 ​Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 G.2 ​Project A: Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 G.3  Project A: Interface Management Organization/Structure . . . . . . . . . . . . . . . . . . . . . . . . . 301 G.4  Interface Management Approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 G.5 ​Interface Lessons Learned. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 G.6 ​Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Preface

BACKGROUND As an interesting and dynamic supersystem, the modern world continues to evolve and change to meet the demands, needs, and desires of its people while dealing with the ever-increasing challenges of sustaining our planet and minimizing our impact on the global environment. Technological advancements are permeating all facets of modern life, feeding an insatiable appetite for better, faster, cheaper. Safe and comfortable automobiles are no longer adequate. Rather, we need automobiles that are safe, comfortable, and drive themselves. Safe and fast air travel is no longer the standard. Rather, it is our ability to stay connected continuously while traveling. Coupled with increasing demands from an ever-growing and changing population, it is natural to expect this complexity to seep into projects. Projects exist to create a result. Often, this result takes the form of a system to be used directly or indirectly to meet the needs, demands, or wants of the population. Whether the system is a new phone, automobile, airplane, space capsule, or online service, the projects undertaken to deliver these systems are becoming increasingly complex. The reasons are simple. First, systems created by these projects are becoming more complex as a result of technology and materials used to develop them; people want products that are lighter, more durable, and last longer. Often this requires the use of specialized equipment to develop the product. Second, requirements for what the system or product should deliver to the user are becoming more complicated. For example, we don’t just want a phone, but a phone that takes photos and video, can connect to the internet anywhere in the world, function as a recording device, and even one that creates a virtual reality environment; in essence, a simple phone is no longer the standard; rather it must function more like a small personal computer with many times the power and capacity of yesteryear’s supercomputers, yet with miniaturization unimaginable just a few decades ago. Such demands result in more complicated system architectures and project development approaches that require collaboration by myriad specialized entities; all of these factors contribute to geometrically increasing complexity in the project environment. Many of the projects undertaken today are large-scale undertakings, and many are megaprojects, commonly defined as complex projects that cost $1 billion (U.S.) or more, take years to design and build, and involve multiple public and private stakeholders. They are deployed in the areas of infrastructure, oil and gas, mining, aerospace, defense, major events such as the Olympic Games, or massive information technology projects. It is not uncommon to hear the term gigaproject or even beyond, the teraproject, as we begin to comprehend giant projects costing $1 trillion (U.S.). According to Bent Flyvbjerg, a professor at the University of Oxford’s Saïd Business School, megaprojects have grown explosively and now constitute eight percent of the global gross domestic product, and most are poorly executed. The “iron law of megaprojects,” he wrote in a 2014 paper in the Project Management Journal, is that they are “over budget, over time, over and over again,” (Flyvbjerg, 2014). Nine out of ten megaprojects experience cost overruns, and most take much longer to build than expected. What results, Flyvbjerg says, is the “survival of the un-fittest”: the least deserving projects get built precisely because their cost-benefit estimates are so misleadingly optimistic (Flyvbjerg, 2014). vii

viii

Project Interface Management

Edward Merrow states that in 2010, 65% of projects with budgets over one billion in U.S. dollars do not meet their business objectives, and most are unprofitable (Merrow, 2011). Whether they are megaprojects or simply large-scale complex projects, their long planning horizons defy the common project management concepts of deterministic schedules, costs, risks, and assumptions. Cost overruns are large and benefit shortfalls are common. Virtually all major capital projects involve complex interfaces among diverse stakeholders and various contractors. The multiple stakeholders often have conflicting objectives; system interfaces are often complex and fall between or among stakeholder organizations without sufficient definition or management. In addition, many of these stakeholders have no direct contractual relationships, yet they share critical system interfaces that may mean the difference between great success and exceptional failure. Interface management is an emerging discipline that aligns critical interactions among project management, systems engineering, and the organization’s operations management to reduce risk and enhance the chances of successful system design and development, completion, and transition to the operation of major capital projects. As projects increase in scale and become more technically and contractually complex, there is a growing need to systematically identify, document, and manage technical, project, organizational, and industry interfaces to ensure effective system integration and adherence to project constraints (e.g., cost; schedule; scope; quality; and health, safety, environment, and security (HSES) requirements; etc.) while meeting stakeholder expectations and industry regulations. The successful completion of complex projects requires synergy between technical and management personnel to complete the project scope of work and deliver a system that meets the need of the project sponsor. The multiple stakeholders often have conflicting objectives—system interfaces are often complex and fall between or among stakeholder organizations without sufficient definition or management. According to Merrow, the task of managing large complex projects “is a task centered around the effective management of the interfaces. The interfaces are opportunities for conflicts and misunderstandings to occur. They are the places where things tend to ‘fall between the cracks,’ ” (Merrow, 2011). Interface management performs a critical function by providing a systematic process for facilitating and managing information flow across shared boundaries by independent project and organizational entities without a contractual or functional relationship. Interface management is the mechanism by which these entities reach agreements associated with system interfaces and establish a common understanding along shared boundaries—preventing unexpected system integration problems late in project development.

ABOUT THIS BOOK The purpose of this book is to assist organizations that are undertaking complex projects by helping project personnel and interface management professionals understand, implement, and effectively manage interfaces for large complex capital projects. It provides a holistic view of interface management that includes people, processes, tools, and techniques that work together to allow teams from multiple organizations to reduce project risk that is endemic to such large complex capital projects; much of this risk arises from the need to effectively manage and deliver numerous interfaces between and among multiple entities that may or may not have contractual obligations to one another. The book is offered as a practical reference guide to be used to: • Familiarize project and organizational personnel with the scope of interface management to ensure a consistent and shared understanding of roles and responsibilities,

Preface

ix

• Provide practical guidance for the implementation of a project interface management program that incorporates proven practices in a variety of domains, and • Describe ways to effectively and efficiently manage interfaces during project execution that minimize the risk of rework during integration.

CONTENT AND ORGANIZATION The book contains nine chapters and is structured sequentially with each chapter designed to build upon the previous one. Chapters 1 and 2 establish the foundation for understanding organizational strategy, the need for projects, and how complexity impacts project development. Chapters 3, 4, 5, and 6 describe the basics of interface management and the concepts underlying the interface management function. Chapters 7, 8, and 9 focus on the practical application of interface management during the project life cycle with an emphasis on sharing best practices. Chapter 1 provides an introduction to organizational strategy and establishes the basis for why organizations undertake projects. Chapter 1 also prepares the context for interface management by providing a brief review of human history. This brief examination helps us to fully appreciate the incredible rate of change over recent history. The chapter also briefly describes portfolio management, project management, and systems engineering, including an overview of types of project development approaches. These project approaches often set the stage for the necessary interfaces because of the acquisition and contracting strategies employed. Understanding how projects are structured plays an important role in understanding how to apply interface management in a project environment. Chapter 2 presents a discussion of complexity and how complexity affects project development. Understanding the factors contributing to complexity can help in comprehending the need for interface management as an important means of reducing risk and enhancing the probability of project success. Chapters 3 and 4 introduce interface management and the processes used to manage interfaces. Chapter 3 provides an introduction to interface management and describes key terms, definitions, and concepts. As expected in an emerging field, there are many alternative definitions, terminology, and meanings that sometimes conflict with one another. This chapter establishes a basis of common understanding of the concepts used throughout the book. Chapter 4 describes the interface management process and the interface life cycle. This description is not peculiar to a specific project environment, but rather is a generic process that can be tailored to any project environment. Chapters 5 through 9 collectively address how to plan, implement, manage (execute), and close out interface management and the interfaces themselves. Chapter 5 discusses the interface analysis process and describes how to begin to decompose the necessary interfaces, forming the basis for interface planning. In Chapter 6, the authors discuss the interface planning process and describe how to develop a project interface management system (i.e., plans, procedures, personnel structure, tools, training, etc.). In essence, this chapter describes how to establish an interface management system appropriate to the project’s interface complexity. Chapter 7 builds upon Chapter 6 and focuses on how to implement the interface management system as actual project execution, or construction, commences. Implementing any management system in a large-scale complex project can be a challenge. Chapter 7 offers guidance and best practices suggested to implement interface management effectively and efficiently and to ensure a fast start. Chapter 8 describes how to manage interfaces during project execution and discusses interface activity as project execution work gets under way and proceeds. This chapter takes a pragmatic approach to typical situations that might occur during project execution and describes how to address these situations. Finally, Chapter 9 describes how interface management supports technical

x

Project Interface Management

compliance and interface integrity, including the interface verification process and interface closeout. This chapter completes the interface management cycle and illustrates how the intense interface activity during project execution concludes as various parts of the system are integrated and verified, and helps to ensure that the project result is delivered to expectations.

AUDIENCE This book is not intended to replace existing project management processes or international systems engineering practices. Rather, it is aligned with and supports both the Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK) and the International Council on Systems Engineering (INCOSE) Systems Engineering Handbook while focusing on the processes, roles and responsibilities, and activities associated with effective management of system interfaces during project development. More important, this book demonstrates how interface management not only simplifies system interface complexity between independent parties, but also aligns project management and systems engineering domains to break down barriers that might otherwise create delays, excessive cost overruns, and unnecessary integration risk. This book provides a road map to effectively design, develop, implement, and manage a tailored project interface management process in a relatively short period of time. In addition to decomposing the process into easily understandable and logical steps, the book also identifies specific tools, techniques, and resources needed to support the process, together with examples throughout. With the guidance, engagement, and support of upper management, and reasonably effective project and program management infrastructure, any organization can implement its own interface management process, make better decisions, and increase its chances of achieving effective development and integration of complex interfaces. People whose organizations are already using interface management might think about how to use the concepts in this book to supplement or improve existing processes. The book is also intended for use as a textbook in an interface management course within graduate and upper level undergraduate business and engineering degree programs. It provides a road map for students to understand interface management through the application of tools and techniques, using a defined process. By structuring the text to coincide with the logical progression of the interface management process and illustrating tools and techniques to use along the way, students will obtain a clear understanding of the emerging discipline of interface management.

SOFTWARE TOOLS It is not the intent of the authors to endorse one software product over others. However, we do make it clear that effectively managing project interfaces is difficult or impossible without the right tools. On large-scale complex projects, the sheer volume of interface items and the depth and breadth of inter-entity relationships indicate the need for a specialized software solution for both management and reporting of progress on interfaces. In relevant chapters throughout the book, we use illustrations from Kongsberg’s Seaflex Web Interface Register (WIR) (km.kongsberg.com) to illustrate the concepts presented. In Appendix B, we use Coreworx Interface Management (CIM) (coreworx.com) software to illustrate similar concepts. A number of other software products are available on the open market, including, but not limited to, Omega Pims Interface Management (omega.no) and Aconex Interface Management for Construction (aconex.com). Readers are encouraged to explore these and other relevant products to assess their capabilities with respect to specific interface management needs.

Preface

xi

To enhance learning and provide you with hands-on experience in the processes described in the book, we feel that instructors and readers should be able to use a tool to practice the concepts provided in the book. As a result, the authors have entered into an agreement with Kongsberg to allow instructors who are using the book as a textbook along with their students who are also using the book, six-month temporary limited access to Kongsberg Seaflex WIR. In addition, the agreement allows individual readers who purchase new copies of this book from authorized distributors limited access to predefined projects. Instructors and individual book purchasers may contact Kongsberg to sign up by navigating to https://www.interfaceregister.com/imbook.aspx. The terms of use are described and you will be asked to provide contact and login information and to verify that you are eligible to use the software. After registering, instructors will work with Kongsberg to arrange access for their students in accordance with the Instructor Guide that is provided as part of the WAVTM material of this book (found at www.jrosspub.com/wav). Please note that the authors and the publisher have no other commercial arrangement with Kongsberg or any other software offer with respect to this book, do not receive payment for the use of, and provide no express or implied warranty for these software tools. Rather, this agreement was made solely for the purpose of allowing instructors and students the opportunity to use an interface management software tool and individual readers to access predefined projects in order to maximize the learning experience and reinforce the concepts presented in this book.

REFERENCES Flyvbjerg, B. (2014). What You Should Know About Megaprojects and Why: An Overview. Project Management Journal, Vol. 45: pp. 6–19. doi:10.1002/pmj.21409, John Wiley & Sons, Ltd. Retrieved from http://dx.doi. org/10.1002/pmj.21409. Merrow, E. W. (2011). Industrial Megaprojects–Concepts, Strategies, and Practices for Success. John Wiley & Sons, Hoboken, NJ, USA.

Acknowledgments We wish to thank Kongsberg for allowing us to use the Seaflex Web Interface Register software tool to illustrate concepts in this book. The use of this tool enhances our ability to reinforce key principles and concepts. The authors would also like to thank Coreworx Inc. for providing illustrations and descriptions from the Coreworx Interface Management module in Appendix B of the book. These illustrations help to show the reader alternate ways of structuring and managing the interface register. We also wish to express our sincere appreciation to Thomas Rivrud of Kongsberg and Kelly Maloney of Coreworx for reviewing early chapter drafts and providing feedback based on their experiences in numerous real-world projects representing multiple industries. Both Thomas and Kelly have extensive experience in supporting large-scale complex projects, and their input certainly enhanced the content of this book. We are especially grateful to our families; Susan’s husband, Jim Bivins, and Michael’s wife and son, Hege and Ethan Bible. Throughout this project they provided unfaltering support for our efforts and made sacrifices to allow us time to focus on this project. Thank you, Jim, Hege, and Ethan! We could not have accomplished this without all of you.

xiii

About the Authors Michael J. Bible, PMP, CSEP, MSPM, IPMA-A, ESEP, MSSE, has over 30 years of professional and leadership experience supporting major programs and projects in the United States Department of Defense and the Norwegian Oil and Gas industry. Mike is a project management and systems engineering professional with a successful history of applying project portfolio, project management, and systems engineering in large-scale complex project environments. During his career, Mike has worked with several large corporations including URS (AECOM Corporation) and Scientific Application International Corporation (SAIC) on several large defense programs and projects including the Army’s Mine Resistant Ambush Protected (MRAP) program and several Marine Corp Engineering Systems programs and projects. In addition, Mike served as a senior advisor to multiple, large-scale offshore oil and gas projects in the Norwegian Continental Shelf (NCS). Mike is a long-time member of the Project Management Institute (PMI) and the International Council on Systems Engineering (INCOSE) and has been honored to be a guest speaker at numerous PMI events including the Global Congress North America. A retired United States Marine Corp officer, Mike earned a Master of Science in Project Management (MSPM) from George Washington University and a Master of Science in Systems Engineering (MSSE) from Johns Hopkins University. Mike currently lives with his wife and son in Trondheim, Norway, and can be reached at [email protected]. Susan S. Bivins, PMP, MSPM, has more than thirty years of management and leadership experience dedicated to delivering successful information technology, organizational change management, and professional consulting services projects for major global corporations. She specializes in project and portfolio management; international, multicultural, and multi-company initiatives; and business strategy integration in the private and public sectors. During her career with IBM, Sue managed multiple organizations and complex projects, including operations and support for the Olympics, and a strategic transformational change program. Since retiring from IBM, she has led multicompany joint initiatives with Hitachi, Microsoft, and Sun Microsystems (Oracle), and has served as Director of Project Management at Habitat for Humanity International.

xv

xvi

Project Interface Management

She earned her MSPM from the Graduate School of Business at George Washington University, where she received the Dean’s Award for Excellence and was admitted to the Beta Gamma Sigma business honorarium. A member of the Project Management Institute, she served on PMI standards teams, has authored several journal articles, and is a frequent webinar and conference speaker, including multiple presentations for the PMI Global Congress North America. Sue currently lives with her husband in St. Louis, Missouri, USA, and can be reached via e-mail at [email protected].

At J. Ross Publishing we are committed to providing today’s professional with practical, hands-on tools that enhance the learning experience and give readers an opportunity to apply what they have learned. That is why we offer free ancillary materials available for download on this book and all participating Web Added Value™ publications. These online resources may include interactive versions of material that appears in the book or supplemental templates, worksheets, models, plans, case studies, proposals, spreadsheets and assessment tools, among other things. Whenever you see the WAV™ symbol in any of our publications, it means bonus materials accompany the book and are available from the Web Added Value Download Resource Center at www.jrosspub.com. Downloads for Project Interface Management: Reducing Risk on Major Projects consist of:

MATERIALS FOR ALL READERS Figures and Tables

All figures and tables from each chapter are provided to be used in presentations or instructor teaching material with appropriate attribution.

Excel Workbook for Set-Up in Interface Management Software

This Excel workbook contains set-up sheets for the sample project that can be used to establish the sample Project Diamond interface management projects in the interface management tool for which temporary access has been granted to readers.

Project Document Templates

These documents established for the sample company ABC Corporation and sample Project Diamond can be used as templates for project and interface documents on real projects and include: • • • •

ABC Management of Project Development Project Diamond Mandate Project Diamond Execution Plan Project Diamond Interface Control Document

INSTRUCTOR MATERIALS In addition to the materials available for all readers, the following instructor-only materials are available.

xvii

xviii

Project Interface Management

PowerPoint Slide Deck for Each Chapter

A generic PowerPoint slide deck is provided covering the material in each chapter, including overview, content, and summary slides. The slides can be downloaded and tailored by the instructor or included with other lecture materials.

Instructor Guide

An Instructor Guide for a one-semester graduate course is provided. It contains example course objectives, course description, suggested subject/topic and student deliverables for each session, sample mid-term exam questions, sample final exam questions, suggested weekly discussion topics, description of class project, and information about contacting Kongsberg to obtain access to Seaflex WIR interface register tool for instructors and students. Of course, instructors may tailor the outline to reflect different course durations and add additional required or recommended readings, grading policies, meeting times, instructor information, logos, etc.

Other Benefits and Materials

As time permits, the authors and other interface management professionals are available to respond to occasional questions or discussion points from instructors using the book for their classes, for brief guest presentations, and for introductory interface management briefings. From time to time, additional or updated materials may be provided for instructors, readers, or both. Updates will be identified in descriptions of the WAV materials, the Instructor Guide, and on the publisher’s website. At present, we are considering developing a series of short videos to complement the textbook material with the authors’ and other interface management professionals’ realworld experiences. We anticipate making them available starting in late 2019.

1

Accelerating Change and the Context for Projects “Life is really simple, but we insist on making it complicated.” —Confucius “Project management is the science of project planning combined with the art of reacting to surprises during execution.” —Edward W. Merrow

While this book is about interface management, a short detour is taken to provide a historical perspective on the rise of human society, the accelerating pace of change, and the increasing magnitude of people-driven endeavors that will help us understand why the need for interface management in modern projects has evolved and why it will continue to occupy a place of importance in future projects. Modern life has changed rapidly during the information age mainly through technological breakthroughs, leading to advancement in virtually all facets of human life. Project interface management is driven by three main factors: complexity, communication, and people. These factors represent happenings in society. It is natural, then, to realize that projects and how they are developed, will change as society changes. Recognizing accelerating change and its inevitable impact on complexity helps explain the emerging need for new project management disciplines, such as interface management, to increase the likelihood of completing projects successfully. An important aspect of understanding what interface management is and how to apply it on large complex capital projects is that of understanding the context for why and how these projects are undertaken in the first place—meaning we need to know why the project was selected and how it contributes to creating value for the entity undertaking or sponsoring such projects. So, in addition to the historical perspective, this chapter also provides a synopsis of the portfolio management, project management, and systems engineering (SE) milieu in which these projects are conceived and carried out. This chapter also provides an overview of why these projects are undertaken by organizations and the context in which they are performed, describes distinguishing factors of large-scale capital projects, discusses how the contract strategy influences project complexity (and certainly interface management), and provides insight into strategic decisions that will eventually mold the management system that will be used to manage the project. It is often stated that “it is hard to see the forest when you’re standing among the trees.” This book is as much about the future of managing large-scale projects as it is about the present—but we need 1

2

Project Interface Management

some historical background. How did we get here? To understand this basic question, we need to step away from the trees and take a brief look into our (mankind’s) past. So, briefly, we go back to the beginning—a simpler time in human life—and reflect upon how we humans got to the point of requiring such systems and management processes. This brief look into human history provides a perspective on how slowly things changed in earlier times and how rapidly modern society is changing now, thus forming the basis for complexity in modern projects.

1.1 ​BRIEF HISTORY OF SOCIETAL EVOLUTION While anthropologists are divided on when the genus Homo emerged, it is estimated that the first members of the human family (hominids) lived in Africa between six and seven million years ago, and spread to Europe and Asia about two million years ago. Early modern humans of the genus Homo species sapiens (Homo sapiens, or us) evolved in East Africa approximately and arguably 200,000 years ago, based on evidence from fossils found in Kenya and Ethiopia. Life for our early ancestors was nomadic, undoubtedly difficult, and focused on foraging, hunting, and surviving threats. Other earlier species of hominids such as Neanderthals (Homo neanderthalensis) lived alongside Homo sapiens, developing crude tools and harnessing fire, until becoming extinct. Of the six known species of humans (Harari, 2015), we sapiens are the only survivors.

1.1.1 ​Prehistory

Prehistory (the time before human language was developed sufficiently to capture it) is classified today into three discrete periods based on the types of artifacts and materials used—the Stone Age, the Bronze Age, and the Iron Age (Thomsen, 1836). From about 2.5 million years ago to 14,000 years ago, the Stone Age was in full swing, a prehistoric period in which hominids used stone to make tools. The Stone Age is divided by some sources into the Paleolithic and Neolithic periods (Kulper, 2015) with the Paleolithic period humans leading nomadic lives as hunters and gatherers, and with the later Neolithic period humans discovering agriculture and domestication of animals, which allowed them to settle in one place (DifferenceBetween.net, 2011). The Bronze Age ushered in the use of metals in tools and implements and is thought to have begun first with the creation of small precious objects from copper, and subsequently, with the creation of copper tools and weapons. Later in the Bronze Age, the true bronze alloy of tin and copper was used. The Bronze Age also fostered increased specialization of human skills and the invention of both the wheel and the ox-drawn plow (Kulper, 2015). Along with specialization, these inventions contributed to greater urbanization and the creation of social order (Metropolitan Museum of Art, 2017). The Iron Age came later, beginning about 3,000 years ago when humans learned to heat and forge iron, which made way for more permanent settlements (Encyclopedia Britannica, 2015). Weapons forged of iron also armed large battle forces and enabled the migration of peoples that changed Europe and Asia over the next 2,000 years (Encyclopedia Britannica, 2015).

1.1.2 ​Beginning of History—the Cognitive, Agricultural, and Scientific Revolutions

Approximately 70,000 years ago, while Homo sapiens spread from Africa throughout Europe and East Asia, fictive language emerged (Gale, 1971) and history began. Harari identifies three revolutions that have shaped history—the Cognitive Revolution, which began about 70,000 years ago; the Agricultural Revolution, which began about 12,000 years ago; and the Scientific Revolution, which began only about 500 years ago (Harari, 2015).

Accelerating Change and the Context for Projects

3

During the Cognitive Revolution period, humans invented boats, oil lamps, needles for sewing, and bows and arrows (Harari, 2015). The same period shows evidence of art, religion, and social orders thought to be driven by dramatically increased cognitive function. It took a few thousand more years to develop kingdoms, early polytheistic religions, and money. During the Agricultural Revolution, humans domesticated plants and animals, enabling the formation of permanent communities (Harari, 2015). About 5,000 years ago, the two early civilizations of Mesopotamia and Egypt were established (Gascoigne, 2001). Mesopotamia, on the land between the Tigris and Euphrates rivers, had rudimentary civil services and laws to protect people from one another, while ancient Egypt in northeastern Africa stretched along the fertile soils of the Nile river valley. Both civilizations used early forms of writing—cuneiform in Mesopotamia and hieroglyphs in Egypt. The Agricultural Revolution saw the rise of the first kingdoms, money, and religions. Over 2,000 years ago, the Han Empire in China, the Roman Empire around the Mediterranean, and Christianity all rose and flourished. Some other monotheistic religions arose earlier (Judaism) and later (Islam). In just the last 500 years, humans have driven the Scientific Revolution by admitting our ignorance and striving to not just maintain the social order and status quo, but to “discover new medications, invent new weapons, and stimulate economic growth” (Harari, 2015). It also led to the development of weapons “not only to change the course of history, but to end it” with respect to nuclear weapons. Harari points out the astounding growth in human power (not to mention complexity) by pointing out that a peasant who fell asleep in the year 1000 AD could awaken in the year 1500 without missing a beat, but one who fell into a similar sleep in the year 1500 would have a rude awakening by “the ringtone of a twenty-first century iPhone” (Harari, 2015) and would find a world beyond comprehension. This statement by Harari is important as it illustrates an increasing rate of change over these two time periods.

1.1.3 ​The Growth in Human Power During the Scientific Revolution

According to Harari’s research, in the last 500 years the human population has increased 14-fold (from 500 million to about 7 billion), production has increased 240-fold (as measured by the total value of goods and services produced by humankind, which has grown from $250 billion to $60 trillion in today’s U.S. dollars), and energy consumption has increased 115-fold (as measured by calories of energy per day, from 13 trillion per day to 1,500 trillion per day) (Harari, 2015). In his book, Harari cites several examples of the acceleration of the rate of change. One of those examples is that, “Prior to the sixteenth century, no human had circumnavigated the earth. This changed in 1522, when Magellan’s expedition returned to Spain after a journey of 44,000 miles. It took three years and cost the lives of almost all the crew members, Magellan included. In 1873, Jules Verne could imagine that Phileas Fogg . . . might just be able to make it around the world in eighty days” (Harari, 2015). By contrast, he points out, at present an individual can safely and easily travel around the world in 48 hours or less. Of course, rather than having his own ships or balloons, the present-day traveler relies on the infrastructure of airlines and terminals, the technology of aircraft and air traffic control, the educated and highly skilled people who staff them, and the governments, markets, and societies that regulate and support them. In other words, the rate of human growth and societal change is accelerating at an ever-increasing pace, as is the complexity of living with these changes. The simple fact is that humanity has come a long way in a relatively short time, beginning with tens of thousands of years at a relatively languid pace, and continuing with fierce acceleration in more recent times. Progress begets change and it also begets complexity. In many ways, modern humans are struggling to adapt to the rapid rate of change.

4

Project Interface Management

1.2 ​IMPLICATIONS OF ACCELERATING SOCIETAL CHANGE Human civilization has experienced a rate of change unimaginable by ancient humans. This rate of change is driven by advances in technology and science, along with the drivers of modern civilization. As Harari points out, although some may believe that science and technology hold the answers to all of our problems, science and technology must be “. . . shaped by economic, political, and religious interests” (Harari, 2015). It is governments, businesses, and other entities that have funded the scientific breakthroughs and innovations that have extended our life expectancy and perhaps, too, our quality of life.

1.2.1 ​Creating a Complicated Modern Civilization

These governments, businesses, religious, and other organizations, guided by their ideologies, determine what to fund and even what the future will contain; they allocate funds among the conflicting objectives and priorities of communities of life on earth. While continuous invention and innovation have given us modern conveniences and longer lives, they have also yielded massive population growth, ever-shifting demographics, peril for many cohabitant species of our planet, and explosive rates of change. They have also created a complicated or even complex modern civilization. While we humans have, in general, progressed, the complication in modern society is evident in all parts of our lives—from the food we grow, to the way we travel, to how we communicate, etc. As societies, some of us have many choices (and complications) arising from the vast options we have about how to live our lives, even where we choose to live. Others in less developed nations and parts of the world are not as fortunate. It is reasonable to suggest that the world will continue to become even more complex with increasing populations, the development of new products with the advancement of technology, and the desire by governments and organizations to improve the quality of life for its citizens. Undoubtedly, projects will continue to be a part of the evolution of humans, but we need to recognize the rapid change that has occurred in the recent history of humanity and how this change has affected projects—more important, how it will continue to affect projects going forward into the future. Modern society grapples with issues associated with the pace of change, as is evident in global opportunities to increase the application of robotics and artificial intelligence, while at the same time dealing with the basic need to dramatically increase global food production to keep pace with population growth facing environmental phenomena that threaten to reduce the capacity to do so. Projects, which are a major means of achieving positive change, also struggle with the forces of change. They too must adjust to the rapidity of change and how to properly handle complexity resulting from it. As evidenced by the almost universally high rate of large-scale project delays, overruns, and failure to fully achieve the operational results for which they were undertaken, we as project professionals in various industries have not been fully able to adapt to the rate of change and growth of complexity; meaning that often, project organizations are ill-equipped to effectively manage complex projects— often because of things we don’t know that we need to know.

1.2.2 ​Evolving Layers of Complexity in the Systems We Create

The rapid advances in technology, especially over the past 30 years, have afforded humans incredible opportunities to share information through countless media, affecting the way we conduct communication. Face-to-face conversations have often been replaced by social media, and classroom learning by online self-paced and sometimes non-communal education—thereby making us alone

Accelerating Change and the Context for Projects

5

in a crowded place. The ability to conduct real-time dialogue and video with anyone, virtually anywhere, also gives us the wherewithal to conduct business in real time across geospatial and cultural boundaries. In terms of technology, modern society has an insatiable appetite for more—more functionality, more capability, more everything. This affects the products people buy and use in everyday life and how we live. Individuals and organizations create a perpetually escalating demand for new and improved products and services. Often, these products and services interact with other products and services, creating layers of complexity related to integrating new systems with existing or even other new systems. The challenges will be compounded by continued population growth, political conflicts, and environmental impacts—requiring even more advanced solutions. Given that the rate of change and evolution of societies will likely continue to accelerate, organizations will need ever-better management systems to address them and thus remain relevant and competitive. Thoughts of stand-alone systems operating independently are becoming the modern unicorn in an increasingly connected world where one system operates as part of an interconnected supersystem.

1.3 ​DEVELOPING THE STRATEGY The modern global marketplace will continue to evolve to meet the needs, demands, and desires of a growing global population in search of a higher living standard and longer and higher quality of life. Companies and organizations providing those products and services are also subject to change and complexity. As a result, these companies and organizations continually innovate to improve the effectiveness and efficiency of existing products and services in order to remain competitive, and they also invent new products and services in order to meet a growing global demand. This is evident in everyday life products, such as our mobile phones, for example, where a single device is used for numerous functions: telephone, camera, voice and video recorder, texting, etc. (even tracking the steps we take in a day), that only 20 years ago required several devices in order to perform the same functionality and tasks, or that we couldn’t perform at all. In recent decades, especially since the 1980s, we have experienced an increase in the global marketplace where companies and organizations can reach across countries and continents to identify suppliers, vendors, and manufacturers to aid in developing new products and services, creating product and system development possibilities that were not available only a few short decades ago. Every organization exists for a purpose, which typically includes providing services and products to support customers and clients. Whether government agencies or multinational corporations, organizations undertake strategies to identify a long-term plan that hopefully leads to the achievement of organizational success factors: hiring more people, capturing a greater proportion of a particular market share, higher share price or earnings per share, providing more efficient services, etc. While a strategy does not guarantee a road map to organizational success, developing (and revising) a strategy demonstrates deliberate and careful decisions about what the organization should do in the future to remain successful. The process of establishing an organizational strategy is important in the rapidly changing global marketplace; poor strategic decisions certainly can lead to the demise of the organization, particularly when those decisions are based on faulty assumptions or fail to anticipate future changes in a complicated marketplace. These decisions ultimately and ideally result in the types of projects sanctioned, among other organizational activities. In the book Mastering Project Portfolio Management, Bible and Bivins (2011) provide an appropriate analogy to explain the importance of strategic direction. In Lewis Carroll’s Alice’s Adventures in Wonderland, Alice comes to a crossroads in the Pigs and Pepper scene and is uncertain as to which direction she should go. In a nearby tree, she notices the Cheshire cat and asks the cat which way she should go. The cat responds, “That depends a good deal on where you want to get to.” Alice replied that it really didn’t matter. The cat replied, “Then it doesn’t matter which way you go.”

6

Project Interface Management

“Unlike Alice in Wonderland, an organization must have a destination in mind that leads to success and a proper road map to get there. In today’s competitive environment, an organization must take the best road that leads to continued relevance, prosperity, and success. No easy task given the rapid rate of societal change. This is the purpose of strategic planning” (Bible and Bivins, 2011). An organization’s strategy is driven by its mission, values, goals, and objectives. Its mission answers the questions “why are we here?” and “what is our purpose?” or “what do we do?” The vision is a fast-forward to some stated future time frame of how the world (or at least the portion of it affected by the organization’s mission) will be if they succeed in the execution of the mission. An organization’s values are shared beliefs that drive its people’s behaviors; that is, they describe how employees or other stakeholders are to conduct themselves with respect to each other and other stakeholders. Values are often accompanied by a set of behaviors that describe each of the values. Goals and objectives state what is to be accomplished. When they are decomposed, they become more specific and time bound. The objectives are to be achieved within the mission, to be delivered in keeping with the organization’s values, and to move the organization toward achieving its vision. With amazing rates of change all around us, of course, strategy must not remain static—it must be as agile as the environment in which it is developed. A strategic plan allows an organization to (1) identify its aspirations and how it will attain them in order to stay relevant in the marketplace; (2) communicate, clarify, and align its commitments around the long- and short-term goals, and (3) provide consistent guidance for decision making, resource allocation, budget planning, and training (Urbanick, 2008). The essence of the strategic plan is to attain an organizational state in which everyone shares a common vision of what the organization wants to achieve in the future, understands what is required to achieve that vision, and is motivated to contribute to the organization’s success. In many large organizations, strategic planning is conducted at the corporate level and based on the corporate plan each group or division in the organization’s hierarchy may perform its own strategic planning process, albeit at a more tactical level appropriate for the subset of corporate goals it supports. Ideally, these plans will roll up to form an integrated whole, and roll down so that the goals and objectives at the lower level and the initiatives undertaken all support the corporate strategy. The organization’s objectives are accomplished (or should be) by selecting and managing the optimal combination of projects that drive the organization’s achievement of its strategy—that is the meaning of project portfolio management (PPM). We included this brief description of strategic planning to reinforce the importance of strategy to the PPM process and ultimately to the reasons why we perform projects. Projects, and more specifically, portfolios of projects and programs, are central to the achievement of organizational goals and objectives. The goals and objectives are the strategy, which, in turn, is key to the continued relevance and success of the organization.

1.4 ​INTRODUCTION TO PROJECT PORTFOLIO MANAGEMENT PPM is an iterative process linking the strategic objectives of the organization to selecting and managing the right project portfolios. The less a project contributes to accomplishing an organization’s goals and objectives, the less value it creates and the more resources are wasted or at least inefficiently utilized. To better utilize resources and achieve desired outcomes, organizations are becoming more concerned about which projects to undertake in the first place, which has led to a more formal process called PPM. Harvey Levine (2005) defines PPM as “. . . a set of business practices that brings the world of projects into tight integration with other business operations. It brings projects into harmony with the strategies, resources, and executive oversight of the enterprise and

Accelerating Change and the Context for Projects

7

provides the structure and processes for project portfolio governance.” The Project Management Institute (PMI) more broadly defines PPM as “. . . the coordinated management of portfolio components to achieve specific organizational objectives” (PMI, 2008). Bible and Bivins (2011) also suggest that PPM is a flexible, responsive, and iterative process to select and execute the right projects that maximize achievement of the organization’s strategic goals and objectives subject to physical, political, financial, and other resource constraints. The PPM process can be thought of as the actionable management process necessary to achieve the organization’s strategic objectives through project portfolio selection, implementation, monitoring and control, and evaluation. PPM is not the same as enterprise project management or management of multiple related projects as the name might imply. A project portfolio is a group of projects selected and executed specifically because together they best help an organization to achieve its objectives. The objectives are the lowest level output of the strategic planning process, which produces the organization’s mission, vision, goals, and the objectives that support each goal. The fundamental task of PPM is selecting a portfolio of projects that maximizes the achievement of those objectives while achieving balance among, and coverage of, the objectives. Although effective PPM contributes to the achievement of organizational objectives, it is not the only source of achievement. The organization’s ongoing business operations also contribute to the achievement of objectives as we will discuss later in this section. Every organization is resource constrained. An effective PPM process provides the structure to make reasoned trade-offs about how the resources should be allocated to maximize potential benefits. Thus, sound decision making through a disciplined and methodical process is a crucial attribute of an effective PPM process. Through such a process, the organization can make rational decisions as to how best to employ constrained resources across objectives to maximize the benefits of its project portfolios. The foundation of the organization’s PPM process is laid during the development of the strategic plan, which identifies the organization’s destination and a road map to achieve desired future outcomes. The result of the PPM process is the selection and implementation of a group of projects, which are intended to achieve specific strategic objectives. Modern projects require management systems and processes to increase the likelihood of success; resulting in the rapid rise of project management and the adoption of formal project management tools, techniques, processes, and systems.

1.5 ​INTRODUCTION TO PROJECT MANAGEMENT Project management is at least as old as the Great Pyramids so it predates the Scientific Revolution that began only 500 years ago. While the roots of project management extend to ancient times, only within the last half century has formal project management gained wide acceptance and traction in many organizations. Business and government agencies have become more aware of the need to manage projects using formal practices and processes to ensure greater project success, i.e., “doing the work right” (PMI, 2008). Meredith and Mantel provide three primary reasons to explain the emergence of project management “.  .  .  (1) the exponential growth of human knowledge, (2) the growing demand for a broad range of complex, sophisticated, customized goods and services, and (3) the evolution of worldwide competitive markets for the production and consumption of goods and services” (Meredith and Mantel, 2006). These reasons have not gone unnoticed. In 2016, U.S. President Barack Obama signed the Program Management Improvement and Accountability Act aimed at enhancing accountability and best practices in project and program management across the U.S. federal government. Throughout the United States’ Department of Defense (DoD), there is an ever-growing emphasis on program and project management as acquisition personnel design, develop, and procure hundreds of billions of dollars of advanced military equipment. The DoD’s Defense Acquisition University (DAU)

8

Project Interface Management

is dedicated to formally training and educating personnel in defense acquisition program and project management and establishing standards for program management career field certification (DAU, 2010). Expanding beyond the DoD, the U.S. National Aeronautics and Space Administration established the Academy for Program/Project and Engineering Leadership and many leading corporations have established project management training programs and project, program, or portfolio management offices (PMOs) to develop project, program, and portfolio management methodologies tailored to organizational needs. Similar advances have occurred in other parts of the world, in, for example, the United Kingdom’s Cabinet Office, which supports the British Prime Minister and Cabinet. The ever-growing emphasis on project management can also be illustrated through the expansion of project management professional certification from PMI. Founded in 1969, PMI has grown to several hundred thousand members internationally with a “primary goal to advance the practice, science, and profession of project management throughout the world in a conscientious and proactive manner so that organizations everywhere will embrace, value, and utilize project management and then attribute their successes to it” (PMI, 2010). APMG International also provides certification training and examinations and accredits professionals in multiple disciplines, including project, program, and portfolio management. Not only do organizations want to complete projects successfully by doing the work right, they also want to successfully complete the right projects. Completing projects on time and within budget has little to no value if projects fail to contribute to the successful achievement of the organization’s strategic objectives.

1.5.1 ​Defining Project Management

As defined by Harold Kerzner, “Successful project management can then be defined as achieving a continuous stream of project objectives within time, within cost, at the desired performance/ technology level, while utilizing the assigned resources effectively and efficiently, and having the results accepted by the customer and/or stakeholders” (Kerzner, 2017). In essence, a project is a temporary endeavor to create a unique product, service, or result (a system for example) (PMI, 2008). The temporary nature of projects indicates that a project has a beginning and an end. Although considered temporary, project durations may equate to several years in some large-scale complex project developments, such as military weapon systems, enterprise information systems, offshore oil and gas processing facilities, etc. The part that occurs between the beginning and the end of a project, in this book, is called the project development process. The project development process is defined by various project development phases such as: conceptual design, detailed engineering, procurement, fabrication and construction, transportation, installation, mechanical completion, and commissioning. In some organizations, procurement, fabrication, construction, transportation, installation, etc., may be grouped together and called execution. Different organizations and industries may call them by slightly different names, and different sets of contractors and ultimate end users may sometimes cause the names of the phases to be different, but the example should suffice to present the concept of development phases. As the project progresses through each development phase, various project management processes are used to initiate, plan, execute, monitor, and control, and close the related project work. Every industry, organization, and project is different, and the method used to develop the project will vary accordingly. Regardless, each project will follow a general development approach consisting of some form of engineering, procurement, and construction (EPC). In essence, we need engineering to design thoroughly the result of the project (engineering design), build or commercially procure (order and receive) material and equipment (procurement), and finally, assemble those items into the final system (construction). It is normal for this cycle to repeat itself through several project phases, or stages, until the final system is completed.

Accelerating Change and the Context for Projects

1.5.2 ​Balancing the Project Constraints

9

Managing projects requires constant focus on the scope of work and completing the work on time (i.e., as scheduled) and within budget while meeting quality and safety expectations. Ideally, the scope of a project is precisely defined early. By knowing the scope of work, the effort required (resources multiplied by time) can be accurately estimated, leading to an approximate cost to complete the project. In addition, knowing the scope of work allows for planners to optimize the work so that the activities are defined and resources are applied to complete the activities in the most efficient sequence, resulting in the schedule to perform the work. The foundation (but, of course, not the only factor) for an effective schedule is the amount of confidence in the scope of work—the greater the confidence in the scope of work, the better. Precise knowledge of the scope of work and what is required generally translates to less risk than a situation in which the scope of work is not well understood or defined. (Of course, in getting from concept through detailed design, such schedule and cost estimates become more definitive and less variable, or less stochastic and more deterministic. However, large-scale complex projects often overrun even those estimates. Reducing those costly overruns and under-delivery experiences are a major purpose of interface management.) This basic principle of scope certainty affects many aspects of managing projects and the system used to monitor and control project work. Ultimately, the goal of project management is to complete all defined project work with high quality according to the schedule, without overspending or getting anyone hurt (i.e., safety). The impact of risk and the ability to manage risk certainly affect the outcome of this goal. This book is not intended to provide the reader a detailed examination of project management— there are many books on that subject. Here, we simply want to state that a central challenge in project management is to have a high degree of certainty about the scope as early as possible in the project. Knowing exactly what the project is to produce increases the chances of delivering the project successfully, assuming good management and safety practices during the project development process. Unfortunately, it is rare to have such certainty early in the project. In fact, changes (expected and unexpected) are common in all types of projects, large and small, which result in more work, extra cost, and increased time. The main point is that a dependent relationship exists among cost, schedule, and scope (also quality and safety). As scope increases, cost will increase and more time will be added to the schedule; requiring more quality and safety management. The simple question then is, why can’t we always be certain about the work that needs to be completed by the project? Several factors affect a project’s success and management’s ability to control scope, schedule, cost, quality, and safety. Naturally, as project complexity increases, the difficulty in managing the project increases. In Chapter 2, we will discuss the topic of complexity in more detail since complexity has a direct impact on project interface management. However, a project to build a single-family home is not the same in terms of complexity as a project to build a 150-story skyscraper. Building a singlefamily home, while still a project, is more like a process than a project, especially when using preconfigured blueprints—millions of homes have been built over the last decades and the technology has remained relatively stable. Comparatively, not many 150-story skyscraper buildings are being built. Such buildings incorporate technology and safety control systems exceedingly more advanced than those in single-family homes, and each one is unique. Thus, a 150-story skyscraper construction project is larger in scale and size, more unique, and more technologically complex than a project to build a traditional single-family home, making a skyscraper much more difficult to manage than a single-family home project. Add to that the fact that the forces of weather and other phenomena have an impact not only on construction schedule, but on the design as well. The uniqueness, scale, size, and complexity of such a project impacts the project team’s ability to manage and control scope, cost, schedule, quality, and safety.

10

Project Interface Management

1.5.3 ​Rapid Change in Projects

While project management is a relatively new management discipline, it is greatly affected by the rapid rate of societal and global change. Here, project management is affected in two ways: (1) by the increasingly complicated project development approaches offered by a relatively new global marketplace and (2) by the complex systems resulting in rapidly changing technologies that projects must produce. The world has become a much more connected (technologically and physically) global society, allowing for greater flexibility for project developments and increased capability and functionality of the systems produced by projects. The opening of the global marketplace through numerous trade agreements has resulted in opportunities for all participants, but while these new markets provide greater access, they have also resulted in complicated project development approaches. Organizations and companies are now able to select vendors, suppliers, fabricators, constructors, engineers, etc., from a global versus local marketplace, creating more opportunities for project sponsors to leverage global technologies, capabilities, and competencies. Essentially, the world is the global supermarket where the best products and services can be acquired for the cheapest price (albeit not always the most safe, the best quality, or morally acceptable). As expected, organizations that are sponsoring projects, especially large-scale projects, have the opportunity to subdivide a project’s scope of work into several parcels and contract to global companies (vendors, suppliers, etc.), reaping the economic and business benefits of such a strategy. In addition, the systems being created by the project continue to increase in complexity as a result of continued rapid technological advances, enabling constant opportunities to improve existing products and services and create new products and services with greater capabilities and functionality. The never-ending consumer requirement for faster, better, cheaper creates a competitive cycle to one-up business competitors in hopes of retaining or expanding market share in a particular market; this means organizations constantly search for a balance between the lowest price and the most product functionality and performance. Later in this chapter, we discuss this topic further; the main point here is to recognize that projects are changing rapidly as the world around us changes. More precisely, projects are becoming more complicated because the systems developed by projects are increasingly more complex and so is the way we develop projects. In this book on project interface management, we provide a systems approach mentality to illustrate strategies for simplifying complexities and complication, such that it can be managed effectively. First, we focus on large-scale capital projects as they tend to fall in categories of higher complication and complexity. With this focus, we are not suggesting that interface management is only applicable to large-scale projects; on the contrary, interface management is applicable to any projects that have explicit or implicit interfaces. However, these large-scale capital projects do provide very good examples to illustrate the concepts in this book to those who may not be familiar with interface management. Clearly, these concepts can also be translated to less complicated and complex projects characterized with a high number of system interfaces and/or a complicated development approach.

1.5.4 ​Just a Few Words on Benefits Management

We mention benefits management here because, although it has always been necessary, it has only been recognized and practiced widely and explicitly during the past decade or two. Managing strategic benefit starts with opportunity identification and then the establishment of the business case. It is managed throughout the project life cycle and beyond. Surprisingly, many organizations stop measuring at just the time that real benefits begin to accrue. The actual benefits accrue to the sponsor or the end user, but the practice of benefits management has often been relegated to the project management level, where it can’t possibly be managed. The likelihood that a project under development

Accelerating Change and the Context for Projects

11

continues to promise the strategic benefit for which it was selected is a strategic issue and should be managed at that level. Once the project begins to deliver those actual benefits, assessing and tracking them against strategic expectations belongs to the sponsor or strategic portfolio or program management office, which will own and manage benefits long after the project ends. Like interface management, benefits management is an emerging discipline. Steve Jenner in Managing Benefits defines a benefit as “The measurable improvement from change, which is perceived as positive by one or more stakeholders, and which contributes to organizational (including strategic) objectives.” He defines benefits management as “the identification, quantification, analysis, planning, tracking, realization, and optimization of benefits” (Jenner, 2014). PMI defines a benefit as “an outcome of actions, behaviors, products, or services that provide utility to the sponsoring organization as well as to the program’s intended beneficiaries (PMI, 2013). Levatec says that “. . . benefits are provided to a sponsoring organization and to intended beneficiaries; both are worthy of mention” (Levatec, 2014). For the first time, the PMI Pulse of the Profession survey in 2017 looked at levels of benefits realization maturity as one of the measures of project success, and stated that “the traditional measures of cost, scope, and time are no longer sufficient” and that it is time for projects to deliver the benefits for which they were selected (PMI, 2017). As large complex projects sometimes overpromise and under deliver, it is worth noting that we need to be wary of obstacles we face in forecasting, particularly cognitive biases. Lovallo and Kahneman in Harvard Business Review argued that forecasters suffer from “delusional optimism: we overemphasize projects’ potential and underestimate likely costs, spinning success scenarios while ignoring the possibility of success.” Stephen Jenner wrote an excellent article on this subject in the PM World Journal (Jenner, 2012). In addition to cognitive bias, it may be wise to be wary of deliberate overstatement of benefits in order to achieve funding for major projects.

1.6 ​INTRODUCTION TO LARGE-SCALE CAPITAL PROJECTS The term large-scale capital projects can be quite misleading and open to interpretation. In this book, the term large-scale capital project is characterized to mean a project requiring several hundred million, or billions, of U.S. dollars, requiring multiple years for project development and characterized by several organizations or entities contributing to project development. The authors’ intention is not to precisely define exactly what does or does not constitute large-scale, but rather to provide a visual context and allow subjectivity to help categorization. Essentially, these projects tend to cost a considerable amount of money, require a small army of people and organizations to help with development (i.e., several hundred or thousands), and extend in duration over a long period of time (i.e., several years). Large-scale projects are highlighted because they tend to perform poorly as factors contributing to complexity are not well understood and/or not managed effectively. Merrow identifies special challenges for megaproject teams that include geographic dispersion, integrating joint venture partners that “beg for no one to be in charge,” and interface management (Merrow, 2011). In more than thirty years of studying megaprojects, Merrow says, “Most of the big mistakes that companies make in developing and executing these projects stem from a basic lack of being able to pursue a common goal with clarity and good behavior” (Merrow, 2011). Some of these mistakes come from greed, failure to understand who has the risk, failure to shape the opportunity and specify the governing principles of the contract or deal, and inappropriate actions to reduce cost—these projects fail at an “alarming and unsustainable rate.” We would add failure to manage interfaces to Merrow’s list. Virginia Greiman, who served on Boston’s Big Dig project as deputy chief counsel and head of risk management, has identified 25 characteristics of megaprojects that go beyond simply long duration and scale, including projects that have a long, complex, and critical front

12

Project Interface Management

end; complicated financing schemes; dynamic governance structures; and are subject to public scrutiny and/or policymaking, among other factors (Greiman, 2013). On a brighter note, as reported by the PMI Pulse of the Profession (2017), project performance has improved, but much work remains. The PMI 9th Global Project Management Survey stated, “For the first time in five years, more projects are meeting original goals and business intent and being completed within budget. There has also been a significant decline in dollars lost. Organizations are wasting an average of $97 million for every $1 billion invested due to poor project performance— that’s a 20% decline from one year ago” (PMI, 2017). Of the industries included in the study, healthcare reported the highest average waste on project spending. A more detailed breakout of several key industries included in the study, ranked from highest to lowest, demonstrates the range of project waste: • • • • • • • •

Healthcare Telecom Energy Manufacturing Government Financial Services Construction IT

$112 million per $1 billion $106 million per $1 billion $101 million per $1 billion $98 million per $1 billion $97 million per $1 billion $97 million per $1 billion $94 million per $1 billion $78 million per $1 billion

Of the geographic regions covered in the study, PMI noted specific markets stood out. India reported the lowest average monetary waste on projects ($73 million per $1 billion), followed by both China and the Middle East ($82 million per $1 billion). Conversely, Europe reported the highest average waste on project spending at $131 million per $1 billion (PMI, 2017). Many infrastructure projects fall into the large-scale project category so we provide some discussion of these in the next section.

1.7 ​INFRASTRUCTURE EXAMPLES OF LARGE-SCALE COMPLEX PROJECTS Infrastructure development is an ongoing concern for cities, states, and nations around the world. From wastewater treatment facilities, transportation systems, and major road systems to national electricity grids and telecommunication systems, infrastructure supports and enables all of the comforts and capabilities of the modern lifestyle. Improving and adding to productive infrastructure represents an investment in the future—supporting economic growth and helping to raise living standards over time. Some examples of modern large-scale infrastructure projects are described in the following paragraphs.

1.7.1 ​California High-Speed Rail

There are numerous ongoing major (large-scale) projects underway around the world. In the United States, the state of California broke ground on the California High-Speed Rail (CHSR) project in 2015 with an expected first stage development cost of $68 billion, which covers 520 miles between San Francisco and Los Angeles. Ultimately, the CHSR project will extend from Sacramento in the north to San Diego in the south. The system is designed for speeds up to 220 mph and a travel time of three hours from San Francisco to Los Angeles, which is less than half the driving time.

Accelerating Change and the Context for Projects

13

1.7.2 ​China-Pakistan Economic Corridor Project

The China-Pakistan Economic Corridor is a transportation and energy infrastructure project designed to link Kashgar in western China with Gwadar, a port city in Pakistan. Project plans include the construction of new roads and railways and the upgrade of existing transportation infrastructure. A substantial improvement of the Karakoram Highway, which travels over a 15,000-foot pass at the China-Pakistan border, is underway as of 2016, as are dozens of other transportation projects. China announced $46 billion in foreign direct investment and low-cost loans to bring the corridor to completion since it would provide faster access to markets in South Asia, the Middle East, and Africa.

1.7.3 ​Riyadh Metro (Rail & Bus) Project

The Riyadh Metro is an urban rail and bus transportation system under construction in Riyadh, Saudi Arabia. Construction began in 2013 and is expected to conclude by the end of 2018. Plans call for six rail lines traveling a combined 109 miles, in addition to a bus line network covering 715 miles. The project is designed to combat rising traffic congestion in a city expected to grow from 5.7 million people in 2014 to 8.2 million by 2030. The system will handle up to 3 million passengers per day. Construction includes 85 air-conditioned stations, 11 bridges, 16 miles of tunnels, and 21 parkand-ride facilities. Three international consortiums are handling the $22.5 billion project’s design and construction. Major international firms participating in the project include the German engineering conglomerate, Siemens; the French rail transportation company, Alstom; and the Canadian transportation company, Bombardier. This does not include the complex network of sub-suppliers, vendors, and subcontractors.

1.7.4 ​Panama Canal Expansion Project

The Panama Canal, one of the most impressive modern infrastructure projects, is a shipping route connecting the Pacific Ocean with the Atlantic Ocean across the Isthmus of Panama. It utilizes a system of locks to raise ships about 85 feet above sea level to the shores of Gatun Lake in the middle of the isthmus. The Panama Canal Authority initiated construction on a $5.25 billion canal expansion project in 2007. The Panama Canal expansion project adds a third traffic lane to the canal and expands some existing canal channels. The new traffic lane and its locks will accommodate larger container ships equipped to carry nearly three times as many containers as the smaller ships, effectively doubling the canal’s shipping capacity. The new traffic lane opened for business in 2017.

1.7.5 ​London Crossrail Project

The London Crossrail project is a capacity enhancement rail project centered on London. It involves the laying of a new 118 km rail track from Maidenhead and Heathrow in the west to Shenfield and Abbey Wood in the east. The project will allow an additional 1.5 million people to travel between London’s key business districts in just 45 minutes. The world’s first underground continues to grow, adding 26 miles of tunnel connecting 40 stations for quicker and more direct travel opportunities for travelers. The estimated cost of construction is $23 billion. The project is scheduled for completion in phases, with the first new track going into service in 2018 and all remaining tracks in service by 2020.

14

Project Interface Management

1.7.6 ​Large-Scale (Major) Infrastructure Project Summary

The aforementioned projects are only a small sampling of large-scale or major projects underway across the planet. Infrastructure projects are an example of how complexity affects large-scale projects in general. It’s not just the sheer volume of equipment, people, materials, tools, regulations, and such, but the way these elements must interact over a long timeline to ensure various work activities are finished correctly and completely (and, of course, safely). The Big Dig project in Boston, formally named the Central Artery Tunnel project that rerouted a formerly elevated interstate highway through a 3.5-mile tunnel, built a bridge over the Charles River, and created a greenway in the space that was left by the former elevated highway, was one of the largest urban infrastructure projects ever undertaken in the United States. It also cost several contractors restitution fees. By its own reckoning, the Big Dig was “originally projected to cost $2.5 billion and was to be completed by 1998. Instead, the project cost $14.8 billion and was not completed until 2006” (Greiman, 2013). Nevertheless, it is not only a technical marvel, it has relieved transportation problems for millions in the Boston area, provided a series of parks and public spaces, and made Boston Logan International Airport much more accessible. Modern railway and other infrastructure projects now incorporate highly advanced safety automation and control systems to ensure safety of operations—such as systems to signal, monitor, and control train operations as well as systems to provide comfort and safety to those using the rail system. These systems include everything from redundant emergency braking systems to efficient air (heat and cooling) systems. Imagine life as a passenger on a train over 100 years ago that was rife with dangers—from the billowing smoke entering train cars from coal burning engines to trains that broke down constantly or failed to show up on time (or at all). Comfort was an option not afforded on early twentieth century trains, but is something taken for granted on modern rail systems. Modern train travel by comparison allows for a relatively inexpensive, safe, and comfortable method of modern travel. As seen from the infrastructure projects previously mentioned, transport projects continue to improve service, safety, and functionality for future passengers, but this example is recurring in all industries from defense to energy to telecommunications.

1.8 ​OVERVIEW OF PROJECT DEVELOPMENT STAGE-GATE PROCESS Large-scale project developments are commonly guided by a deliberate decision-making process that examines the feasibility and progress of the project at specified points through a life cycle from idea to operation and ultimately through disposal. As mentioned, each project moves through a number of phases. For example, a feasibility phase, concept selection phase, evaluation/improve phase, execution phase, operation phase, and decommission and disposal phase. The aim of project development phases is to provide a structured road map to guide the project along its development. At the conclusion of each phase, a decision acts as the mechanism to enter the follow-on (or next) phase. In this way, the organization or project sponsor can evaluate progress, maturity, and continued relevance of a project. Project development processes, characterized by phases and decision points, provide a valuable mechanism to increase the likelihood of success and/or terminate project developments at the earliest point. Projects, especially large-scale developments, require extensive capital investments. Project development processes act as protection for capital investments by ensuring a process to make good decisions at predefined points in the project’s development. Early phases may focus on the feasibility of a particular project idea. During this phase, several concepts may be evaluated to ascertain if undertaking the project would result in value creation

Accelerating Change and the Context for Projects

15

for the project sponsor. At the conclusion of the phase, a decision meeting is conducted to determine if the project should progress to the next phase. If successful, the project advances to the next phase, such as the concept selection phase where at the conclusion another decision meeting is performed. This process repeats itself until the project life cycle reaches an end, which may include termination during development or disposal after operation, for example. There are many different project development approaches, but all follow a similar process to the stage-gate process for new product development. Dr. Scott J. Edgett and Dr. Robert G. Cooper developed the Stage-Gate® model to serve as a road map for effectively managing the process of new product development. The Stage-Gate® model is widely used to manage the idea-to-launch process (Cooper, 2011). Although originally devised for new product development, it has been adapted to project management and systems engineering projects across multiple industries, and is, in some circles, considered de rigueure for major capital projects. Figure 1.1 shows the Stage-Gate® model with sample phases and decision gates. Build Business Case

Scoping GATE 1 Idea Screen

STAGE 1

GATE 2 Second Screen

STAGE 2

Tesng and Validaon

Development GATE 3

Go to Development

STAGE 3

GATE 4 Go to Tesng

STAGE 4

Launch GATE 5

STAGE 5

Go to Launch

Figure 1.1  Stage-Gate Process. Stage-Gate® is a registered trademark of Stage-Gate Inc. (Used with permission from www.stage-gate.com.)

In the Stage-Gate® model, Dr. Edgett and Dr. Cooper describe a number of stages including: discovery (Stage 0), which is not shown; scoping (Stage 1); building the business case (Stage 2); development (Stage 3); test and validation (Stage 4); and launch (Stage 5). Between the stages, management decision points (gates) are established. Stages are where the action occurs and deliverables are developed. These deliverables then act as input to the decision-making process—at the decision gates—where the deliverables are measured against criteria; resulting in a decision output (i.e., go/ no-go, hold, recycle, etc.). The types of project development processes can vary between industries and between organizations within a specific industry. The choice of project development approach and the underlying project development process will affect a project’s development in a good or not-so-good manner. Some development models may impose strict and expansive requirements that need to be met for each gate. Others may view such requirements as overly bureaucratic. Some project development processes may not provide sufficient structure, allowing for excessive free-form activity that could create problems with delayed manifestation later in the development process.

1.8.1 ​U.S. Department of Defense Project Development Example

Arguably, one of the most complex project development processes exists within the U.S. Department of Defense (DoD) to guide the department’s system acquisition process. An overview of the process is illustrated in Figure 1.2, but a more comprehensive view of the process can be found at the DAU website (https://www.dau.mil/tools/t/Department-of-Defense-Acquisition-Life-Cycle-Chart). Granted, the DoD highly encourages tailoring the process for the specific nature of the project, but with such an expansive development framework, even the process of tailoring can be difficult. The

16

Project Interface Management

Figure 1.2  U.S. DoD System Acquisition Framework

DoD’s System Acquisition Framework divides the acquisition process into Pre-System Acquisition, consisting of two phases (Material Solution Analysis and Technology Development), then System Acquisition (consisting of Engineering and Manufacture Development and Production System Deployment) and on to Sustainment (consisting of Operations and Support phases). Milestones A, B, and C act as gates between early phases with specific decision points embedded within the phases. A deeper examination of the System Acquisition Framework reveals a network of stringent guidance requirements within each phase, including mandatory technical activities, major deliverables/ products, inputs and outputs, etc. Many of the systems acquired by the DoD must integrate into an existing mission-oriented architecture, creating a maze of system interfaces between the system being acquired and the existing architecture with which the system is to be integrated.

1.8.2 ​Oil and Gas Industry Project Development Example

In comparison to the U.S. DoD System Acquisition Framework, a typical oil and gas project development process shown in Figure 1.3 seems quite basic and follows a less complicated project development approach. As is the case with the DoD’s acquisition framework model, the oil and gas industry’s project development process follows a prescribed path while providing management decision points before the start of each phase. In a typical oil and gas project development, the appraise phase begins with a hydrocarbon discovery. This phase screens identified options for technical and commercial viability and establishes

DG-1 CONCEPT SELECT DECISION

DG-0 FEASIBILITY DECISION 1

0

APPRAISE • Economic Viability

• Best Concept

IMPROVE • Optimize Concept

Figure 1.3  Oil and gas project development approach example

DG-4 BEGIN OPERATION DECISION 4

3

2

SELECT

DG-3 SANCTION PROJECT DECISION

DG-2 IMPROVE CONCEPT DECISION

EXECUTE • Design & Build

OPERATE • Operate & Maintain

Accelerating Change and the Context for Projects

17

a short list of options to be advanced to the next stage. As the project continues to advance through the development process, the system concept matures. At decision gate DG3, the decision can be made to sanction the project and begin development. This phase can be the most time consuming and expensive, as it entails engineering, procurement, construction, transportation and installation, mechanical completion offshore, and commissioning (i.e., system verification and validation) in preparation for decision gate DG4 to put the system into production. We show these project development phases and frameworks to indicate how the project progresses from an idea toward a stage at which it matures sufficiently that a decision can be made to develop the project (or, in the U.S. DoD’s case, a program). When a project or program is sanctioned at DG3 for oil and gas (Milestone B for the U.S. DoD), this represents the stage at which the project as an idea begins the process of translating into an actual project result or system. After this decision gate, project execution or project development begins. Embedded within the project development process, systems engineering (SE) plays a vital role in structuring how the work will progress throughout the development process. Also throughout the development process, projects require a systematic approach that focuses on how the work is being performed. The SE process is a key resource supporting project management and ensuring that modern systems are designed and developed correctly. By correctly, the authors mean in compliance with the governing regulations, codes, and standards while ensuring technical integrity of the system throughout development and integration of the system into the existing infrastructure, thus delivering a system that is safe to operate while meeting the needs of those who use it.

1.9 ​INTRODUCTION TO SYSTEMS ENGINEERING Whereas project management is about what work needs to be completed, SE focuses on how to accomplish the technical work while maintaining a holistic perspective. SE is a key component of the work and activities that occur between the stage gates. As stated by the International Council on Systems Engineering (INCOSE): “Systems engineering is a discipline that concentrates on the design and application of the whole (system) as distinct from the parts. It involves looking at a problem in its entirety, taking into account all the facets and all the variables and relating the social to the technical aspect. Systems engineering is an iterative process of top-down synthesis, development, and operations of a real-world system that satisfies, in a near optimal manner, the full range of requirements... Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal... Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs... Certain keywords emerge from this definition description including: interdisciplinary, iterative, socio-technical, and wholeness” (INCOSE, 2015). INCOSE describes SE as a process and a perspective as well as a profession. The SE perspective is based on systems thinking, which “occurs through discovery, learning, and dialog; leading to sensing, modeling, and talking about the real-world in order to understand, define, and work with systems” (INCOSE, 2015). Systems thinking is a perspective and an awareness of the whole system and how parts within that system interrelate and the interrelationships between elements within the system as well as between the system and external systems. The SE process has an iterative nature that supports learning and continuous improvement. As the processes unfold, systems engineers uncover the real requirements and “the emergent properties of the system” (INCOSE,

18

Project Interface Management

2015). Complexity can lead to unexpected and unpredictable behavior of systems; hence, one of the objectives is to minimize undesirable consequences. This is accomplished by including and seeking contributions from experts across relevant disciplines coordinated by the systems engineer. Since SE has a horizontal orientation, the discipline (profession) includes both technical and management processes. Both processes depend upon good decision making. Decisions made early in the life cycle of a system, whose consequences are not clearly understood, can have enormous implications later in the life of a system. It is the task of the systems engineer to explore these issues and work to resolve these uncertainties as early as possible in project development.

1.9.1 ​Use of Systems Engineering

The SE discipline, working in unison with project management, has emerged as an effective way to manage project complexity and change. As both complexity and change continue to escalate in our products, services, and society, reducing the risk associated with new systems or modifications to complex systems continues to be a primary goal of SE. Every system life cycle consists of the business aspect (business case), the budget aspect (funding), and the technical aspect (product). SE creates technical solutions that are consistent with the business case and the funding constraints. Yet, system integrity requires that these three aspects be in balance and given equal emphasis at all decision gate reviews. Whenever someone, whether an individual or an organization, desires to achieve a result, they must perform a series of actions and operations—not just randomly; these actions and operations must be performed in a mandatory order (considering their dependencies), who will be performing them, and what tools and techniques will be used. Because they want a specific result, individuals and organizations follow processes, whether predefined or ad hoc. Just as each project is unique from every other project to some degree, so too will the processes that are used to develop the project’s result. Because these process components (activities, tools, sequence, etc.) and their interactions (information flow, artifact flow, communication, timing, and such) can vary, processes will differ even if being performed by organizations with the same goal. In large-scale projects, mistakes made early in project development can ripple through later project phases (e.g., from engineering to procurement and construction) if not detected and corrected. SE, in unison with project management, provides the foundation for understanding what needs to be accomplished in order to deliver the project result and also how it should be accomplished to ensure minimal errors of commission and omission throughout the project development process. In SE, the technical processes enable systems engineers to coordinate the interactions between engineering specialists, project management functions, system stakeholders, operations, and other interested parties. These processes also address conformance with expectations and regulatory requirements of industries, governments, and others. Ultimately, SE technical processes lead to the creation of a full set of requirements (user and regulatory) that address the desired capabilities and functions for a specific system within the bounds of design constraints, performance, external interfaces, and the environment.

1.9.2 ​Project Management and Systems Engineering Combined

The combination of project management and SE provides powerful mechanisms to understand and effectively manage large-scale project developments. Even so, project development results in a web of highly complicated interactions among the parties who are contributing to the project result. As we’ve seen, modern projects rely on many geographically dispersed organizations with specialized knowledge, experience, competencies, technologies, and materials to contribute to highly complex system developments. These organizations are expected to contribute their respective deliveries at

Accelerating Change and the Context for Projects

19

the right time to be integrated with other deliveries and assembled in a predefined sequence. Along the process, thousands or millions of details are coordinated through a variety of interactions across multiple communication channels, from formal to informal. The laws of probability suggest that something will go wrong, resulting in more work, extra time, and more cost than planned. However, project management and SE provide the foundation of structure and organization; they are emplaced together to lead, manage, control, and of course, produce the complex systems that are the purpose of major project development.

1.10 ​DESIGNING AND DEVELOPING COMPLEX SYSTEMS Every project is undertaken to produce a result. The infrastructure projects presented earlier are examples of systems produced by large-scale projects. However, each of these systems created by the infrastructure projects consists of several different subsystems, components, logics (signals), etc. In essence, each of these systems has a hierarchy within the system. It is normal to think of a project as a stand-alone entity with no connection to the outside world. As evidenced by the previous infrastructure project examples, modern projects are typically integrated as part of an existing system architecture, or part of an urban landscape, or part of a transport network. For example, a new offshore oil and gas processing facility off the coast of Norway will be integrated into existing subsea transportation lines or connected to surface transportation systems to move hydrocarbons from the point of recovery to global markets. Large wind farms need to be connected to existing power infrastructure architectures in order to deliver the power they create. New airplane development projects need to be integrated into existing air transportation networks and hubs. These supersystems also undergo routine upgrades and modifications, resulting in a trickledown effect on the systems with which they interact or connect. Project development durations of several years increase the challenges of designing a system and integrating it with an existing architecture, especially one that may have undergone updates and changes during the development of the new project. It is common in some industries to undertake multiple concurrent projects which are to be integrated with one another and need to finish at or near the same time. Parallel projects may or may not have the same sponsor; if they do not, the span of control over integration of the various project systems is more complicated. In the oil and gas industry, it is quite normal for one offshore field development project to integrate into the field development of another company. Naturally, the benefit is the reuse of the existing offshore subsea infrastructure to transport newly discovered hydrocarbons along an existing pipeline network. However, this requires the project team of one project to coordinate closely with the team of the other project to ensure smooth integration, thus increasing project management and SE complexity. Emerging problems within one project can quickly become the problem of the other project; potentially resulting in commercial and legal consequences. In an ever-connected and technologically advanced society with rapidly evolving conveniences, modern project design and development are difficult to manage (and are arguably impossible to control). What then is the fate of future projects given the accelerating pace of change observed over the last fifty years? No one can predict the future, although some suggest otherwise, but it is possible to make reasonable inferences about the future based on trends over the last few decades. If the recent past is any indication, it is reasonable to suggest that, technologically, we will continue to advance in an effort to address existing and expected future challenges for a burgeoning global population. Growing and shifting populations will require more food, energy, infrastructure, health services, and protection. People are likely to further explore opportunities for efficiency, economy, capacity, and capabilities; the projects they spawn will continue the trend to capitalize on open markets and availability of global suppliers and vendors. Technology will continue to be a large part of increasing

20

Project Interface Management

product capability and functionality; the need for sustainability will hopefully minimize the impact on natural resources and the environment. In essence, projects will continue the trend of producing increasingly complex systems through more complicated project developments. Project sponsors will continue to make selecting the most economical development approach a primary consideration. In essence, the intensity of change is likely to persist; continuing to make the delivery of systems created by projects more difficult. Our management processes must keep pace with—and harness—what is technologically possible.

1.11 ​COMMERCIAL CONTRACTING DECISIONS AND FACTORS INFLUENCING PROJECTS At the heart of every sanctioned project are the capital investment costs (CAPEX) that are required in order to develop a project. Obviously, every project sponsor desires to minimize the CAPEX while achieving maximum return on investment (i.e., maximum value creation). Regardless of industry, this results in many creative commercial arrangements and strategies. When sanctioning a major capital project, the project sponsor (owner) must select a basic contracting strategy for developing the project. This strategy has two key components: (1) types of contracts and (2) how the project scope will be delivered. Rarely does a single organization have sufficient resources to undertake a major project and deliver the entire scope itself. Various approaches exist—and for good reason: the choice of contracting approach can and will affect the outcome of the project. The commercial strategy must be selected with careful consideration not only for the potential upside of the approach (i.e., opportunities), but with consideration of the risk and appreciation of the demands that each strategy places on the owner’s organization. Any contracting strategy, of course, can result in undesirable consequences if it is selected without the necessary resources in place and if the assumptions about the strategy are invalid. The appropriate approach to produce optimal results will be different depending on the structure and culture of the owner organization and the specific circumstances of a given project. The approach that produces favorable results for one owner could be problematic for another.

1.11.1 ​Types of Contracts

The type of contracts to be used for developing the project is largely dependent upon the degree of certainty of the scope of work; that is, how well the scope of work is understood, complete, and clear. When the client is certain of the scope of work, the client may shift more risk to the contractor, who may be willing to accept the risk because much of the scope uncertainty is removed. When the scope of work to be performed is more uncertain, the project sponsor is usually more willing to assume risk and the contractor will likely seek protection from that uncertainty. Obviously, this affects the type of contract the project sponsor can reasonably use.

1.11.1.1 ​Fixed Price Contract

A fixed price contract is used when the scope of work is well understood and clearly defined. In essence, prospective contractors submit bids as an all-inclusive fixed price to deliver the scope of work. By requesting and submitting a fixed price, both the client and contractor have high confidence in the work that needs to be completed and the scope is not expected to change. When a scope of work is clearly defined and well-understood, the risk to the contractor is (relatively) low. By submitting a fixed-price bid, the contractor is expressing its relative certainty of ability to deliver the scope of work on time and to quality expectations. Changes can be made to the scope of work, but this results in increased costs. However, in large-scale projects, precisely defining every aspect of the project scope

Accelerating Change and the Context for Projects

21

can be a daunting task and other types of contracts may be used. Although we continue to derive deterministic schedule and cost estimates for large-scale complex projects, in reality, we’d be better served to use stochastic cost and schedule (ranges with probabilities) as many new product organizations do. An unusually naïve client may believe that he is shifting risk to the contractor by using a fixed price, but its use in the wrong circumstance has come back to bite many a client.

1.11.1.2 ​Cost Reimbursable

Cost reimbursable contracts are used when the scope of work is less understood or less precisely defined. In large-scale projects that require significant engineering activity, a cost reimbursable contract is often used. The engineering process by nature is an iterative process. That is, work is performed and checked, which results in input to improve the design. This then results in another engineering iteration until the design matures such that it is compliant with regulatory and user requirements. As expected, this is usually not a preferred contract method for the project sponsor since the sponsor assumes the cost risk. The lack of scope definition can easily result in a never-ending cycle of work, resulting in cost overruns, or at least larger costs than the sponsor had anticipated. In some situations this cannot be avoided, but in nearly all cases it is better to have a fully defined and well understood scope. From a practical matter, reimbursable contracts are more difficult to plan than fixed price contracts.

1.11.1.3 ​Cost Plus Incentive Fee

Since the scope of work may not be well-defined and understood, how can an organization plan and schedule activities when they are not certain what the end result is to be, what the activities will be, or how much effort they will require? Of course, the answer is that they cannot schedule with any certainty. In these cases, the result is often a dynamic schedule that changes routinely. It is normal for project sponsors to add financial incentives to these types of contracts to lessen this risk. These incentives are intended as motivation for the contractor to finish the work as quickly as possible. In principle, the contractor receives a financial incentive payment for completing certain amounts of work. In some cases, without a trusting relationship, the contractor may be more motivated to continue the reimbursable work than to collect the incentive and it is for this reason these types of contracts can be quite costly for the project sponsor if not managed carefully. As we will discuss in upcoming sections, these contracts can also have a ripple effect on other contracts when the project sponsor elects to use a multiple contractor approach to deliver the project scope of work. This is the second aspect of the contract strategy, deciding how the scope of work will be delivered.

1.11.2 ​Multiple Contractors versus Turnkey

Combined with the types of contracts, the project sponsor also needs to decide whether the entire scope will be awarded to a single organization or if the scope will be subdivided and contracted to several parties. A multiple contract approach may divide the scope (i.e., parcels) into a few or many contracts. A client may choose this option when: (1) at least some parts of the project scope are well defined, (2) the client wants to take advantage of specialized capabilities, competencies, and skills, or (3) the client wants to obtain economic benefits afforded by the availability of many vendors and suppliers, or in other words, is looking for the lowest price among many qualified offerers. As mentioned, the opening of the global marketplace has increased the availability of vendors, suppliers, and manufacturers, creating a virtual global supermarket for project sponsors. More contracts increase the owner’s opportunity to save cost but also increases the owner’s risk with respect to project integration. The multiple contractor approach allows the owner to leverage specialty firms

22

Project Interface Management

with rare or critical competencies. It also allows the client to segment out the project scope so that it provides the least risk and best economic opportunities. However, segmenting the scope to many parties creates interdependencies between the scopes that need to be managed proactively to prevent late-stage development problems, which seem to be ever present in modern projects. When segmenting the scope to multiple contractors, the only contractual relationship is with the owner, and not between the contractors in most cases. That means that any implied interfaces usually are not explicitly specified in the scope of work for the contractors. Of course, how to manage that will be discussed in detail later in the book. With a turnkey approach, the entire scope is provided by a single contractor on a turnkey basis and is seemingly straightforward. After award, the contractor develops a complete facility that requires the owner only to metaphorically turn the key and operate it. The contractor’s scope is some form of EPC. In a turnkey approach, the project sponsor limits its options to the capabilities and competencies resident within the turnkey firm and any subcontractors it may obtain. A turnkey approach using a reimbursable contract, where the scope is not well defined, may be less beneficial as subdividing the scope into parcels and contracting some of the better-defined scope as fixed price; limiting the reimbursable to only those areas with uncertain scope. These are the types of trade-off the project sponsor will make in determining the optimal contract strategy.

1.11.3 ​Multiple Contractors, Multiple Contract Types

Regardless of approach, the contract strategy is an important element to project interface management. Certainly, the architecture of the system to be developed by the project is an important consideration (and will be discussed in more depth later in the book), but the parties responsible for the scope and the types of contracts are equally relevant. Arguably, one of the more popular contract strategies is to use multiple contractors and multiple contract types. From a client perspective, this can provide the optimal strategy in terms of minimizing capital investments and risk. As mentioned earlier, it is normal for parts of the project scope to be well understood and defined. It is natural to select a fixed price contract for this scope and advertise to the global marketplace. Typically, this results in a lower price for those segments of the work. For those parts of the scope that are less understood or for which the scope cannot be precisely defined, the client can use a reimbursable contract, but still has the option of opening the competition to global vendors and suppliers. In such cases, the client reaps the economic and risk benefits of both types of contracts. Unfortunately, there is a key aspect of this strategy that is usually not well addressed. When undertaking an approach that uses multiple contractors with both fixed and reimbursable contracts, it is quite normal for the interdependencies among the different contractors to become challenging. On the one hand, the contractors with fixed price contracts understand their work quite well. This leads to a stable schedule and fixed price. On the other hand, the contractors with reimbursable contracts are less certain of the work they need to complete, which leads to a dynamic schedule that tends to change rapidly and to costs that are less well-known. As the work commences, if there are high levels of interdependency between fixed and reimbursable contracts, then it is challenging to align delivery of the interdependencies, resulting in problems for both parties. Even though the contractor with the fixed price understands the work that must be performed, this contractor can be dependent upon inputs from other parties, including those with reimbursable contracts. The contractor with the reimbursable contract may not be able to provide the material or information to other parties when needed. In fact, this contractor may not even be able to say when it can provide the material or information. These types of situations are often, even typically, not considered as part of the contract strategy as the cost associated with the individual contracts tends to be the selection driver. But these challenges may be suboptimizing and will likely add to the complexity of the project and delivery of the scope

Accelerating Change and the Context for Projects

23

of work necessary to complete the system or project result. From an interface management perspective, knowledge of the organization’s strategy, its project development process, and the system to be developed by the project are key inputs to devising not only a contract strategy, but a project interface management system.

1.12 ​CONCLUSION The accelerating pace of societal change has driven demand for increasingly complex products and services, which, in turn, have driven the rise of project-oriented organizations. Over the last 500 years (half a millennium!), mankind has experienced an explosion of change. Growing populations, technological advances, and opening of markets are only a few of the factors contributing to significant and rapid change that is affecting all parts of society. Regardless of individual views for or against the changes experienced in modern society, it has occurred, and there are no indications that this trend will subside. In fact, it is reasonable to expect the rate of change to continue to increase if the past 500 years or even the past 50 years are any indication. Projects are becoming increasingly more difficult as development approaches become more complicated by the availability of globally dispersed vendors and suppliers and ever-increasing regulatory demands. In addition, systems created by projects are characterized by increasing complexity resulting from advancing technology to improve system efficiency, capabilities, and functionality. Whereas society is struggling with the rate of change, project environments are becoming increasingly complex and project professionals are struggling to adapt to how this change is affecting the systems developed by projects. As technology becomes geometrically more capable, we need to address how our management systems can keep pace. One of those critical emerging management systems to address complexity is interface management. In Chapter 2, we set the stage for stakeholder and interface management by defining complexity and discussing how it affects project and technical management. This is one of the most important factors when considering project interface management. Since most large-scale projects involve multiple entities within and beyond the project scope early in project planning, the next chapter also addresses managing stakeholder complexity and using stakeholder analysis as a means of aligning the actors who are associated either directly or indirectly with the project, along with their needs and requirements. The result of this analysis will directly feed the interface management processes addressed in later chapters.

1.13 ​REFERENCES Bible, M. J. and S. S. Bivins. (2011). Mastering Project Portfolio Management. J. Ross Publishing, Inc., Fort Lauderdale, FL. Cooper, R. G. (2011). Winning at New Products: Creating Value through Innovation, Fourth Edition. Basic Books of Perseus Books Group, Philadelphia, PA. Cooper, R. G., S. J. Edgett, and E. J. Kleinschmidt (2001). Portfolio Management for New Products, Second Edition. Basic Books of Perseus Books Group, Philadelphia, PA. Defense Acquisition University (DAU) website. Retrieved 01/23/2010 from http://www.dau.mil/default.aspx. DifferenceBetween.net. (2011). “Difference between Paleolithic and Neolithic.” Retrieved from http://www .diffen.com/difference/Neolithic_vs_Paleolithic. Editors of Encyclopedia Britannica. “Iron Age.” Encyclopedia Britannica. (2015). Retrieved from https://www .britannica.com/event/Iron-Age. Gale, R. M. (1971). ‘The Fictive Use of Language.’ Philosophy, 46(178), pp. 324–340. doi: 10.1017/ S003181910001696X. Gascoigne, Bamber. History World. From 2001, ongoing. http://www.historyworld.net.

24

Project Interface Management

Greiman, V. A. (2013). Megaproject Management—Lessons on Risk and Project Management from the Big Dig. John Wiley & Sons, Inc., Hoboken, NJ. Harari, N. H. (2015). Sapiens, U.S. Edition. Harper Collins, New York, NY. INCOSE. 2015. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 4.0. John Wiley & Sons, Inc., Hoboken, NJ. Jenner, S. (2014). Managing Benefits, Second Edition. APMG International, High Wycombe, UK. Jenner, S. (2012). “Benefits realization—building on (un)safe foundations or planning for success?” PM World Journal, Vol. 1, Issue 1, July, 2012. Kerzner, H. (2017). Project Management: A Systems Approach to Planning, Scheduling and Controlling, Twelfth Edition. John Wiley & Sons, Inc., Hoboken, NJ. Kulper, Kathleen. “Bronze Age.” Encyclopedia Britannica. (2015). Retrieved from https://www.britannica.com/ event/Bronze-Age. Levatec, C. J. (2014). Strategic Benefits Realization. J. Ross Publishing, Inc., Plantation, FL. Levine, Harvey A. (2005). Project Portfolio Management: A Practical Guide to Selecting Projects, Managing Portfolios, and Maximizing Benefits. Jossey-Bass Business and Management Series, San Francisco, CA. Lovallo, D. and D. Kahneman. (2003). “Delusions of Success: How Optimism Undermines Executives’ Decisions,” Harvard Business Review, July, 2003. Meredith, J. R. and S. J. Mantel. (2006). Project Management—A Managerial Approach, Sixth Edition. John Wiley & Sons, Inc., Hoboken, NJ. Merrow, E. W. (2011). Industrial Megaprojects—Concepts, Strategies, and Practices for Success. John Wiley & Sons, Inc., Hoboken, NJ. Metropolitan Museum of Art. (2017). Heilbrunn Timeline of Art History, New York, NY. Retrieved from http:// www.metmuseum.org/toah/hd/shzh/hd_shzh.htm. Project Management Institute (PMI). (2008). The Standard for Portfolio Management, Second Edition, ANSI / PMI 08-003-2008. Project Management Institute (PMI). (2013). The Standard for Program Management, Third Edition, PMI, Inc., Newtown Square, PA. Project Management Institute (PMI). (2017). Success Rates Rise. Transforming the High Cost of Low Performance. Pulse of the Profession. 9th Global Project Management Survey. Thomsen, C. J. (1836). Ledetraad til Nordisk Oldkundskab (Guide to Northern Antiquity), published in English in 1848. Urbanick, Janice. (2008). “Strategic Planning Essentials for Construction and Design Firms.” Retrieved from http://www.nawic.org/images/nawic/stratplanningess.pdf.

2

Understanding Project Complexity “The art of simplicity is a puzzle of complexity.” —Douglas Horton

The aim of interface management is to simplify complicated interactions on complex capital projects. Capital projects are becoming larger in size and scale with increasing involvement from external entities, making them more difficult to manage and control. It is then natural to ask, “What is project complexity? How do we define it, and ultimately, how do we simplify it?” In this chapter, we discuss project complexity and the factors driving this complexity. This is an important chapter in the book because it forms the basis for obtaining situational awareness of a respective project and applying the critical thinking necessary to perform the interface analysis and management processes described in later chapters. Project circumstances and characteristics provide the basis for determining the appropriate managerial actions required to complete a project successfully. Complexity is one such critical project dimension (Baccarini, 1996), but we need to understand what complexity is in order to simplify it. “In some ways, complexity is rather like love: Everybody has experiences of it and knows what it is, but ask them to define precisely what they mean by it and you will end up with a broad range of definitions” (Cooke-Davies, 2011). Bennett (1991) observes that practitioners frequently describe their projects as simple or complex when they are discussing management issues, indicating a practical acceptance that complexity makes a difference in managing projects. It is not surprising then that complex projects demand an exceptional level of management. This is especially true when considering the application of conventional management systems developed for ordinary projects were found to be inappropriate for complex projects (Morris and Hough, 1986). The International Council on Systems Engineering’s (INCOSE) Complex Systems Working Group focuses on the challenges and opportunities presented by complex systems with large numbers of components with even greater numbers of interactions distributed in scope across multiple scales and/or across large areas. The working group notes that “complexity is a characteristic of more than just a technical system being developed. The socio-technical ecosystem in which a system under development will be employed exhibits these attributes, as does the environment that gave rise to the challenge or opportunity to which the system was developed in response. Further, the design and development of technical systems is a complex endeavor itself ” (INCOSE Complex Systems Working Group, 2016). These statements begin to express the relationships among the system being developed, which is complex; the project management system emplaced to oversee the work of the project; and the project’s external environment, which is certainly littered with stakeholders of varying power and influence with specific and often conflicting needs and requirements. 25

26

Project Interface Management

We start by defining complexity and then discuss factors contributing to project complexity in order to provide a context for the application of interface analysis and management, which is described later. The underlying rationale for applying interface management is to address complexity resulting from interfaces, interdependencies, and interactions among various entities and systems; it is necessary to discuss these factors and their contribution to project complexity in order to understand the desired outcome of performing interface analysis and management. It will be evident to the reader that project complexity is largely the result of an expansive web of interfaces and interdependencies between system elements (i.e., subsystems, components, etc.). One aspect of complexity is the interaction among various independent entities, including both the entities responsible for delivering parts of the project scope and those entities beyond the project’s discrete scope boundary that can influence the project and the system being developed by the project. In addition to interaction, two other aspects of complexity are interfaces and interdependencies. It is important to differentiate among these three aspects of complexity, and understand how controlling each aspect helps to simplify project complexity, and thus reduces the chances of experiencing problems that can negatively affect project execution and delivery.

2.1 ​DEFINING COMPLEXITY For many people, the term complexity can be difficult to visualize or explain and is open to wide and diverse interpretation. Merriam-Webster’s Learner’s dictionary definition of complexity is described as “the quality or state of not being simple: the quality or state of being complex. A part of something that is complicated or hard to understand.” Evident in this definition is the subjective interpretation. What one person may find complex may be simple to another. Thus, this definition does not allow for a uniform understanding of when something is, or is not, complex. Baccarini (1996) provides two explanations of complexity and the first reinforces this contention. In the first explanation, Baccarini (1996) describes complexity as “complicated, involved, and intricate.” Again, this description of complexity is subjective, open to wide and diverse interpretation. It implies difficulty in understanding and dealing with an object at least in the eyes of some observers. Such a subjective measure of complexity has been found to be an unreliable basis for research analysis (Rowlinson, 1988)—in part because it doesn’t enable a clear and common understanding of factors contributing to complexity. So, although this definition of complexity cannot be considered invalid, it does not provide a firm basis for the formulation of a concise and consistent standard. In the second explanation, Baccarini identifies two types of complexity—organizational complexity and technological complexity—and describes project complexity as the association between the two types in terms of differentiation (the number of varied elements, such as tasks, specialists, or components) and interdependency or connectivity (the degree of interrelatedness between these elements). With this explanation, it becomes possible to classify the kind of complexity to be managed and to begin quantifying complexity in terms of the number of entities, their relationships, the amount of interaction needed between the parties, interfaces, or connection points between systems, subsystems, components, and elements, and so on. In this way, factors contributing to complexity can become measurable and manageable. There is another practical way of thinking about complexity and determining whether a project or system is complicated or complex. One could describe a project or a system as complicated when it has large numbers of interconnections and interdependent parts, whereas complex means something more. Complexity implies that changes in one part of the project or system can impact other parts of the project or system. “A project or system is said to be complex if it contains many interdependent parts, each of which can change in ways that are not predictable, and which can then have unpredictable impacts on other elements that are themselves capable of change” (Cooke-Davies,

Understanding Project Complexity

27

2011). So, this means we can evaluate the existence of complexity by assessing interdependencies within a project or system and the potential for unpredictable change. For example, when comparing the development of a single simple component from a single entity using simple technology to the development of a system comprised of many subsystems that are comprised of thousands of different components from hundreds of entities and new cutting-­edge technology, it is reasonable to assume higher complexity from the latter because we know that there are interfaces between various components, subsystems, and elements resulting in interdependencies among these elements, which require interactions among the various entities providing these elements. In a Harvard Business Review article, Sargut and McGrath (2011) distinguish between complicated systems and complex systems by stating that “complicated systems have many moving parts, but they operate in patterned ways  .  .  .  It’s possible to make accurate predictions about how a complicated system will behave.” In the article, they distinguish the complicated from the complex by stating that “the main difference between complicated and complex systems is that with the former, one can usually predict outcomes by knowing the starting conditions,” while with a complex system, “the same starting conditions can produce different outcomes, depending on interactions of the elements in the system.” They go on to say “it’s possible to understand . . . (simple and) complicated systems by identifying and modeling the relationships between the parts; the relationships can be reduced to clear, predictable interactions” (Sargut and McGrath, 2011). They use flying a commercial aircraft as an example of a complicated system because it involves “complicated, but predictable steps.” What the pilot does with the controls usually has a predictable outcome. On the other hand, Sargut and McGrath state, “complex systems . . . are imbued with features that may operate in patterned ways but whose interactions are continually changing.” Sargut and McGrath further state that with complex systems, “all the elements are interacting continuously and unpredictably.” Sargut and McGrath point to air traffic control as a complex system because it is always changing in reaction to weather, aircraft composition, traffic density, and other factors. What makes an air traffic control system’s behavior predictable at all is that the system was designed to react and change as various conditions and components interact with one another (Sargut and McGrath, 2011). According to John Kamensky of the IBM Center for The Business of Government, “Understanding the difference between a complicated problem and a complex one is important for today’s leaders. They require different strategies and tools that are largely not interchangeable” (Kamensky, 2011). Using Sargut’s and McGrath’s differentiators, Kamensky provides an example of a complicated project: building a highway (predictable outcome when one knows the starting conditions); whereas managing urban traffic congestion is a complex project (different outcomes even with the same starting conditions due to interactions among the elements of the system). He recommends, as do Sargut and McGrath, several mechanisms to help teams and managers cope with the high ambiguity and uncertainty inherent in complex projects, including improved forecasting methods, better risk mitigation strategies, improved ability to weigh alternatives with imperfect information, and diversity of points of view when making decisions (Kamensky, 2011). A major element of all of these, especially better risk mitigation on complex projects is, of course, the effective management of interfaces. Perhaps a very important factor in describing and managing complexity is the concept of emergence. “Emergence is . . . the opposite of reduction. The latter (reduction) tries to move from the whole to the parts. . . . The former (emergence) tries to generate the properties of the whole from an understanding of the parts” (Morowitz, 2002). It seems that reduction, or decomposition, has been a bastion of engineering and project management for a long time—think work breakdown structure: breaking the project down hierarchically and managing and measuring progress on the individual parts to make the whole of the project more manageable. Emergence, on the other hand, is currently a focus of studies of complexity. It is often impossible to predict the behavior of the whole by assessing the sum of its parts—think of the brilliantly beautiful but seemingly unpredictable murmuration

28

Project Interface Management

of a flock of starlings. The behavior is much more than the sum of the individual birds in flight; likewise, how the human brain works is much more than the sum of the cells comprising it. Although a discussion of emergence is beyond the scope of this book, many complex projects have emergent properties. As project managers and systems engineers, we have much to learn in order to lead or design such complex projects to create productive outcomes. From a management perspective, our perception of complexity and the factors driving complexity will affect our decisions and the management systems we choose to employ to control complexity factors. This is the challenge in large-scale complex projects where complexity drivers can take many forms and will vary from one project to another. If a project, or the system under development by the project, contains a substantial amount of complexity, then it is also likely to have aspects that need management in ways that extend beyond the traditional tools and techniques of project management. In such cases, it is necessary to begin identifying and understanding factors that are contributing to complexity and “designing complexity out of the project as far as possible” (Cooke-Davies, 2011). Remember, a project is a “. . . temporary endeavor undertaken to create a unique product, service, or result” (PMI, 2013)—and there are many dimensions and factors driving project complexity.

2.2 ​INFLUENCE OF COMPLEXITY ON PROJECT AND TECHNICAL MANAGEMENT Understanding the factors contributing to complexity plays a vital role in project management and systems engineering (SE) (technical) management. Increased complexity and rapid changes make the governance of projects increasingly challenging. Complexity in this context includes external complexities such as stakeholder relationships, decision-making processes, and internal complexities such as technology and interfaces within and between systems (Williams et al., 2012). For every project, critical thinking and analysis needs to be applied to obtain situational awareness of the project and its context in order to fully understand complexity factors affecting the project and thence to determine appropriate processes, procedures, methods, and systems to manage and control the project. There is widespread agreement among SE and project management practitioners that one factor that makes projects complex is the interaction of human beings who have their own roles, responsibilities, and objectives and are faced with making complex decisions. Thus, complexity occurs when people with different interests, loyalties, cultures, and interactions with one another are put together to deliver a particular project or program. In simple terms, the larger the number of members on a team and the larger the number of teams involved in developing and delivering a project, the greater the likelihood of complexity affecting the project. In large projects that involve many teams, the behavior of individual teams can be hard to predict, especially if there are differences in national, organizational, or professional culture (CookeDavies, 2011). Thus, team size and the number of teams can contribute to complexity in a variety of ways that can inhibit project success. In projects with a high degree of complexity, poor communication can be a significant source or cause of project failure. Although people have been practicing communication since the beginning of humanity (or at least of fictive language), we continue to experience communication challenges that affect everyday life. This may seem surprising since the need to communicate, relate, and interact is a basic human need. However, the processes of relating to one another can be complex because interaction among humans is always unpredictable to some extent (Cooke-Davies, 2011). Add to

Understanding Project Complexity

29

that the fact that stakeholders often have differing objectives and responsibilities and thus differing motivations, it is clear that genuine conflict may arise. Project sponsors and other executives can affect multiple subprojects by delaying important decisions; such delays often result in additional work or rework and affect the project execution team or its resources. These issues are exacerbated in situations in which trust is lacking, resulting in workforce demotivation, poor morale, or exhaustion through the pressure to meet unrealistic schedule demands that may be due to such delayed decisions. Project managers and project leaders can expect to be faced with human behavior and interaction complexity, but their responses can create additional complexity as noted by Cooke-Davies (2011). A common project management response to a schedule interruption might be to attempt recovery to the original planned schedule—for all kinds of reasons—and this can lead to unintended consequences and even failure. Failing to make or delaying a crucial decision can create complexity; for example, taking too long to decide whether to do activity A or B first can easily lead to having to perform activities A and B concurrently without sufficient resources and with concurrent ambiguities of each. Delaying critical project decisions in the hopes of finding a more optimal solution later can result in continued uncertainty, which distracts the project team and results in additional work to prepare for eventual outcomes from likely decision alternatives. A fundamental principle in addressing complexity is to transition uncertainty into certainty as early as possible. Delaying important project decisions only serves to delay transitioning from uncertainty to certainty and increases factors contributing to project complexity. Of course, the chemistry of project teams and between project teams and their management is a significant determinant of project success, even in a complex situation, However, even with perfect communication, by their very nature, large-scale, capital-intensive projects produce complexity.

2.3 ​PROJECT COMPLEXITY Organizations sponsor large-scale capital projects to achieve strategic objectives, which if successful, result in value creation for the organization. Project value can translate to increased market share, higher profits for shareholders, and improved goods and services for consumers. However, value created by large-scale complex projects depends on the success achieved in designing, developing, and delivering the project result (i.e., the system created by the project) subject to project constraints, technical challenges of the system developed by the project, and external forces that can affect project delivery. Combined, these factors create an ever more complex environment with increased difficulty in successfully completing large-scale projects and realizing the project’s full value. Large-scale capital project success is becoming more difficult to achieve for many reasons. A recent study from IPA Inc. showed that “Large Capital Projects (those with capital expenditures larger than U.S. $1 billion) underperform in all industries” (Merrow, 2012). The fact that a project is large-scale does not mean the project is complex. However, adding the word complex to a large-scale project means that many factors and dimensions of the project contribute to complexity including: • Strict regulatory oversight environment from external entities who can influence or intervene in project development or operation • Complicated project development approaches that segment the project into smaller parts, creating multiple paths of interdependencies • Intricate project contract strategies to procure products and services from global vendors and suppliers

30

Project Interface Management

• Concept of operation (for the system to be produced by the project) that requires integration with other projects and existing systems • Use of new cutting-edge technology or manufacturing processes or materials These factors and many others combine to influence and affect the project environment, the entities contributing to direct delivery of the project result, and those external entities outside the project scope boundary that can influence or intervene in the project. To obtain a correct picture of the environment, we must acknowledge and understand potential sources of complexity.

2.3.1 ​Project Environment

Projects are not conducted in a vacuum nor does the environment stop at the boundary of the project’s scope. Rather, projects are executed by sponsoring organizations, governed and regulated by industry agencies, affected by external stakeholders such as regulators, and influenced by the project’s concept of operations and the entities and facilities with which the project must engage, not only during project execution but also after transition into operation. Large-scale complex project environments tend to be dynamic. According to Collyer & Warren (2009), in project management the term dynamic means the extent to which a project is influenced by changes in the environment in which it is conducted, which are often initiated by various groups of stakeholder classes. It is common to group stakeholders into internal and external categories (Aaltonen, 2011). Internal stakeholders are the entities that are formal members of the project and support the project (Morris and Pinto, 2004). These entities are often referred to as primary stakeholders (Cleland, 1998) or business actors (Cova and Salle, 2005) and reside within the discrete project scope boundary. Such stakeholders have a formal, official, or controlling relationship, such as contractual, with the sponsoring organization and are directly contributing to realization of the project result. External stakeholders are not formal members of the project coalition, but may be affected by the project or may intervene in or otherwise influence the project. Such groups are often referred to as nonbusiness stakeholders (Cova and Salle, 2005) or secondary stakeholders (Mitchell et al., 1997) and extend beyond the project’s discrete scope boundary and into its sphere of influence. The term sphere of influence in this book means an imaginary bounded area around the project environment at which entities inside the boundary can exert some level of influence on the design, development, and operations of the system of interest. That is, entities within the sphere of influence may extend beyond the discrete project scope boundary and into sponsoring organization(s), existing facilities, other projects and systems, government oversight agencies, and local or regional community interest agencies or organizations. All potentially relevant stakeholder entities outside the discrete project scope boundary but which are part of the sphere of influence must be identified in order to understand which entities can influence or affect SE activities related to design, development, and operation of the project’s system of interest. The project environment and the potential influences of external stakeholders can be difficult to predict. Every project is conducted within an industry, and most industries are guided by rules and regulations, standards, and government oversight. Industry oversight and governance are ripe sources of unexpected issues that are difficult to forecast precisely—such as changing regulations, stricter environmental laws, the state of economies, and the political landscape. Even recent major accidents within the industry can result in unexpected changes to the project’s development. Thus, it is important to gain an understanding of and an appreciation for the project environment. One way to think about the project environment is to classify each project’s environment in three ways: (1) remote, (2) industry, and (3) competitive (Petit and Hobbs, 2010). While the specific terminology for these environments is not especially important, the concepts and what they describe are; thinking of project environment characterizations as described by Petit and Hobbs in this way can aid in understanding the influencers of complexity for, and obtaining situational awareness of, the project.

Understanding Project Complexity

31

2.3.1.1 ​Remote Environment

A project’s remote environment refers to the broad social, technical, and economic environment in which the project organization is developing the project. The remote environment is seen as changing slowly over time, but is characterized by cultural changes and population evolutions. While slow moving, some changes—such as political changes and political stability—can influence project organizations.

2.3.1.2 ​Industry Environment

The industry environment includes any factor affecting all competitors in a specific industry. This environment includes entry barriers, specific market regulations, common resources, and technologies to produce products or services. The industry environment can be a source for influencing project organizations through changes to industry standards and regulations and through concerns from environmental entities and populations affected by the project.

2.3.1.3 ​Competitive Environment

The competitive environment, while seen as directly impacting sponsoring organizations, has a trickle-down effect on project organizations. This environment includes relationships with direct or indirect competitors and collaborators (such as suppliers and partners), the channel of distribution, and the clients themselves. As will be described in more detail later in the book, in some industries systems developed by projects are often forced to integrate with other projects or the existing systems of competitors; interacting with competitors can create unpredictable behavior even when a cooperative agreement is established between the various competitive parties. While the notion that organizations and their complex projects face changing environments is not new, it is generally acknowledged that project teams have difficulty grappling with sources of complexity beyond their jurisdictions (i.e., outside their discrete scope boundary or area of responsibility). Combined with the inherent complexity within the project’s scope, dealing with influences and changes in the project environment only magnifies the intensity of complexity and unpredictability. Thus, understanding the project environment provides a foundation for creating the project’s development and operations strategy or plan.

2.3.2 ​Complex Project Development Approaches

As a dynamic and complex system in itself, the global marketplace continues to evolve to meet the needs, demands, and desires of a growing and changing global population in search of a higher living standard and longer and better quality of life. As a result, global companies and organizations continually innovate to improve the effectiveness and efficiency of existing products and services to remain competitive and invent new products and services. As expected, companies and organizations develop strategies to anticipate and meet the ever-changing needs and desires of this dynamic and evolving global marketplace, which includes undertaking large capital projects that result in the design, development, and fielding of complex systems. As markets continue to open and trade barriers fall, companies undertaking projects are now better able to take advantage of the global marketplace when developing their projects. In essence, the opening of new markets is providing sponsors of large-scale projects an increasing variety of products and services and competitive pricing from which to select contractors and suppliers for their projects. For example, “Global projects can use time zone differences to increase the number of productive work hours in a day, and secure scarce resources such as knowledge experts and other specialized resources no matter where they reside” (Nidiffer and Dolan, 2005).

32

Project Interface Management

For large-scale projects, the expanding global marketplace often translates to subdividing the project scope into various elements; resulting in more complicated contract structures and more complicated contract award timing as project sponsors segment the project to obtain the best value. While this approach certainly provides many economic benefits to project organizations, it also creates additional project risk by adding to complexity. “Complex procurements involve a large number of actors, they are often associated with a high degree of uncertainty and technological complexity, and will often last for several years” (Olsen et al., 2005). Such a strategy of subdividing the project scope also means there are more entities, or actors, involved in bringing the project to delivery; creating more opportunities for miscommunication between entities within the project or those influencing the project, scope-of-work conflicts, and scope misalignment that result in costly delays. Further, large-scale capital projects typically require several years to complete (3–6 years or longer). Given a project’s development strategy, the timing at which different entities come into and out of the project creates challenges especially when the project schedules of the respective project subparts are not aligned. In addition, complexity of the project environment can influence project success.

2.3.3 ​System Complexity

Every project is undertaken to develop a system, product, or service that will directly or indirectly contribute to meeting the needs of an ever-changing global marketplace and create value for the project sponsor. The desired result of the project influences and acts as a key driver in determining how the project is developed and managed. For example, the project may require specialized products that are only available through a few vendors or suppliers. Further, the system developed by the project may require the services of specialized organizations with critical competencies, such as technical engineering resources, to design the system. From a project management perspective, the system and how the system will be realized during design and development will influence how the project is organized, the management system employed to monitor and control the work, and the processes and procedures to manage complexity and uncertainty. As this is an interface management book with the goal of simplifying complexity, we will describe some key terms here to ensure a consistent understanding of project, system, and some of the factors influencing system complexity.

2.3.3.1 ​What Is a Project?

A project is “a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates that a project has a definite beginning and end. The end is reached when the project’s objectives have been achieved or when the project is terminated because its objectives will not or cannot be met” (PMI, 2013). Key in this definition from the Project Management Institute (PMI) is that the project delivers a result. The project provides the infrastructure, in terms of people, tools, techniques, processes, structures, etc., in order to plan, execute, and deliver the desired result of the project. Every aspect of the project is concerned with delivering the result under specified conditions and constraints.

2.3.3.2 ​What Is a System?

While the definition of system is not precise or uniform, in project management terms it is the result of the project and is achieved by applying systems engineering to design, procure, and develop the system (i.e., the project result). Notable definitions of system are provided in this section to help the reader understand the basis of a system. Not surprisingly, the term system is subject to one’s perception and interpretation. For example, the project manager will view the project’s final result

Understanding Project Complexity

33

as a system while the sub-project manager of a major part of the project will also consider his scope of work a system. Kossiakoff and Sweet (2003) define a system as “a set of interrelated components working together toward some common objective.” While simple and concise, this definition implies a multiplicity of interacting parts that collectively perform a significant function and implies a closed system where all aspects of the system exist within its boundary. Further, this definition is oriented toward the integrated physical system to perform the common objective. As is evident, there is no mention of the infrastructure, such as people or processes, to translate the system from idea to reality. Charles Wasson echoes Kossiakoff and Sweet’s definition of a system by stating that a system is “an integrated set of interoperable elements, each with explicitly specified and bounded capabilities, working synergistically to perform value-added processing to enable a user to satisfy mission-­oriented operational needs in a prescribed operating environment . . .” (Wasson, 2006). This definition expands Kossiakoff and Sweet’s definition in that it acknowledges how the end user intends to operate the system. Finally, the best definition in the view of the authors comes from Buede, who defines a system as a “collection of hardware, software, people, facilities, and procedures organized to accomplish some common objective” (Buede, 2011). The Buede definition takes a broader view of a system as compared to Wasson, Kossiakoff, and Sweet, where the definition is indicative of only the integrated physical system. Buede views a system as not just the physical outcome of the project, but the broader infrastructure necessary to deliver the system while recognizing that the system has an intended purpose. From an interface, interdependency, and interaction perspective described later in this chapter, this more holistic view of a system provides a better basis of understanding for performing interface analysis in Chapter 5 because it is precisely this holistic view of complexity that interface analysis seeks to simplify during project development. The result of the project manifests in a variety of systems, such as: • • • • •

Military system to help defend a country’s citizens Space shuttle to explore and research space Offshore oil and gas platform to recover increasingly hard-to-find hydrocarbons Nuclear power plant for providing electricity Telecommunications system to improve a developing country’s aging or nonexistent communication services.

2.3.3.3 ​Factors Influencing System Complexity

Regardless of industry, a number of factors influence the degree of complexity of the system developed by large-scale projects. Some of the factors that often result in higher complexity include: • • • • •

Rapid technological advances Stricter performance standards Harsher operating environments Increasing environmental regulations and laws Specialized materials and manufacturing techniques needed to fabricate and construct the system • Complicated procurement strategies, especially those needed to obtain specialized products and services • Other approaches or strategies that create significant interdependencies between the subprojects’ scopes of work • Complicated development strategies that create significant interdependencies with other independent or related projects

34

Project Interface Management

As Piciaccia, Faanes, and Lindland noted in 2004 while referring to the oil and gas sector, “At least equally challenging is the set of codes of practice, national and international regulations, and the license specific prescriptions that must be satisfied in order to receive the authorization to first develop the field and then operate it” (Piciaccia et al., 2004). The government approvals required of large-scale project developments are driving project organizations to maximize existing field architectures and existing systems in order to minimize a new project’s physical footprint; this results in additional individual projects that must integrate into an ever-lengthening and sometimes convoluted string of existing project developments and existing system architectures. Increasingly advanced technical solutions of physical components, subsystems, and systems across these integrated architectures is needed to, for example, maximize hydrocarbon extraction, while ensuring complete human and environmental safety across multiple developments and existing system structures. In the information age, these demands are pervasive across many industries and are a reality of modern project environments and systems developed by these projects. As we discuss complexity, we want to bring into focus the relationship and contrast between interfaces, interdependencies, and interactions. This relationship extends not only across independent entities and scopes contributing directly to the development and delivery of the project, but also out to the entities beyond the project’s scope boundary to independent entities that can influence or intervene in the project, such as regulators and government oversight agencies; thus, it involves everyone within the project’s sphere of influence.

2.4 ​INTERFACES, INTERDEPENDENCIES, AND INTERACTIONS The factors discussed previously contribute to project complexity through an elaborate web of interdependencies, interfaces, and interactions to satisfy the informational requirements of each entity or actor (whether within the project scope or external to the project) that can influence the design and development of the system provided by the project. The various entities, and the interactions they need to undertake, can vary and change depending upon the role of each actor and the stage of development as the project moves through the project planning and execution phases. That is who needs to talk to whom about what and when needs to be well understood by the project team and include all actors working to deliver the project or able to influence its design, development, and delivery. This includes both internal and external actors, such as the sponsoring organization, contractors, industry oversight bodies, local civilian areas, and communities, etc. “Wherever independent systems are combined into groups the interaction between the systems adds a further complexity; specifically, by constraining how the resulting system can be changed or controlled. This dimension of complexity affects the management and control aspects of the systems approach” (BKCASE, 2016). This statement begins to acknowledge the impact of relationships between interfacing systems and the entities responsible for delivering the respective system and their impact on complexity. The interface analysis process to be addressed in Chapter 5 is performed to unlock project and system complexity associated with interfaces, interdependencies, and interactions, which is simplified by decomposing complexity into smaller, more manageable and structured parts during the planning process.

2.4.1 ​Interfaces

An interface is a nonhuman thing related to the system under development by the project that is subject to agreement between parties, while interface management relates to the people responsible

Understanding Project Complexity

35

for planning, coordinating, and executing this agreement. Myriad definitions exist to describe an interface and some examples include: • A surface forming a common boundary of two bodies, spaces, or phases (Merriam Webster, 2015) • “The functional/logical relationships and physical characteristics required to exist as a system or entity boundary with its operating environment that enable the entity to provide a mission capability” (Wasson, 2006) • The physical fit is accomplished at inter-component boundaries called interfaces (Kossiakoff and Sweet, 2003) • Connection for hooking to another system (an external interface) or for hooking one system component to another (internal interface); the interface of a system contains both a logical element and a physical element (or link) that are responsible for carrying items (electromagnetic energy or information) from one component or system to another (Buede, 2011) • Common boundaries between people, systems, equipment, or concepts (Nooteboom, 2004) Interfaces can be thought of as interconnections between the systems, subsystems, components, and elements. These connections can be physical, functional, logical (signal or software), or mass (fluids, energy, etc.). At the lowest level, interfaces drive interdependencies between system elements, but also between human groups responsible for designing, developing, and delivering various parts of the system. In this sense, interfaces form one pillar of the symbiotic relationship between interfaces, interdependencies, and interactions. In projects, these interfaces form the basis for interdependencies between objects (systems, subsystems, components, and elements) and the entities (organizations or people that must interact) responsible for delivering those objects.

2.4.2 ​Interdependencies

Interdependencies are dependencies between entities or people. Interdependencies exist when actions in one entity, engaged in its process, affect important outcomes in another unit or process; for example, when one entity affects the quality of deliverables, delivery time, costs, etc., in another entity. Interdependencies can take a number of forms including sequential, pooled, and reciprocal (Thompson, 2003). Sequential interdependencies imply that one interface party is dependent on the completion of information or deliverables from another interface party in order to develop subsequent information or deliverables for its portion of the interface. Thus, each party in the sequence is dependent upon completion of activities or deliverables by a prior party. Interdependencies can also be pooled where multiple entities are dependent upon data and information from other entities, but these entities may not be aware of the dependencies and the parties do not necessarily interact to produce their seemingly independent pieces of the whole. Interdependencies can also be reciprocal, such as between engineering, procurement and construction. Procurement requires specific engineering data and information to progress procurement activities. Construction requires detailed drawings to fabricate and construct the system. Engineering is dependent upon procurement information from suppliers and vendors to finalize detailed design. The interdependent activities may be sequential, but they are iterative or cyclical (Thompson, 2003). In general, interdependencies are thought to be static. However, dependencies between entities can be added, removed, or changed (strengthened and weakened) as the project progresses and the system transitions from idea to reality through the design and development process. Of course,

36

Project Interface Management

the changing and evolving environment beyond the project’s discrete scope boundary complicates interdependencies.

2.4.3 ​Interactions

While there are many types of interactions, the term interaction as defined in this book means communicative action between entities and their people necessary to achieve working interfaces in the project environment and relating to the project’s social, technical, and managerial elements. Interactions are the necessary or desirable human communications among the parties to align their respective scopes, priorities, roles, and responsibilities (Whitty and Maylor, 2009). Interaction complexities are introduced by the dynamic effects of changing each of these elements (social, technical, and managerial) and then interacting as they change, causing further change in other parts of the system. In project environments, especially those defined as large-scale complex project environments, the scale and scope of these relationships can vary in intensity and extend beyond the project’s scope boundary. Interaction intensity (the intensity of the degree of interaction) varies among the specific project actors; interaction intensity describes the level of interaction required to achieve the interface. An intense interaction relationship indicates high frequency interaction between entities, whereas low intensity interaction implies infrequent interaction. Timing is another dimension affecting interaction intensity. The intensity between different entities ebbs and flows at different times in the project and depends upon when in the project the respective actors are needed to deliver or contribute their parts of the project. However, the intensity of the interaction does not indicate the importance of the interaction. Actors within the project may have an interaction with an external actor related to the project that is low intensity, but the importance of that relationship may be very high, such as would be the case with the interaction between the project team and an industry oversight agency. Thus, when beginning to understand interaction relationships among various actors within the project scope and with external entities that can influence or intervene in the project outcome, then both interaction intensity and interaction importance must be factored in determining how to simplify and manage these interactions.

2.4.4 ​Relationship Among Interfaces, Interdependencies, and Interactions

In order to simplify complexity created by interfaces, interdependencies, and interactions, one must understand the relationship among these elements. In virtually all projects resulting in the development of a system, interfaces between system elements need to be aligned for the integrated whole to perform its intended function. These interfaces often result in project management interdependencies between entities where interfaces fall within their scope or area of responsibility. That is, one entity is dependent upon another entity for tangible information, material, equipment, etc., necessary to align interfaces completely. Interactions are the professional social interactions between people representing entities to ensure these interdependencies and interfaces within their areas of responsibility or scope are coordinated, managed, and ultimately aligned. There tends to be a positive correlation between each two of these three elements. The more interfaces between entities, the higher the number of interdependencies, which increases interaction intensity. However, this relationship varies between entities. In some cases, there will be no interfaces between entities because their scopes of work or areas of responsibility do not share a common boundary; thus, there are no interfaces or interdependencies. Clearly, if there are no interfaces and interdependencies, then no interaction is required. On the other end of the spectrum, two or more of the entities may have a large number of interfaces, or a few significant interfaces, resulting in significant interdependencies and high interface intensity. In large-scale complex projects with many

Understanding Project Complexity

37

actors, with many different interfacing system elements, and with different scopes and areas of responsibility, stakeholder analysis processes are important in order to logically decompose complexity associated with stakeholders into smaller, more manageable parts. Decomposing and structuring this complexity is the central purpose of the interface analysis process, which will be introduced in a later chapter.

2.5 ​MANAGING STAKEHOLDER COMPLEXITY Due to the variability of human behavior from those contributing to the development of the system (i.e., the project result) and the perceptions of people outside the system (i.e., the project sphere of influence), the human or people aspect of a system and project is often a contributor to complexity— and that may be a considerable understatement. The rational or irrational behavior of individuals in particular situations is a vital factor with respect to complexity (Kline, 1995). Checkland (1999) argues that a group of stakeholders will each have their own worldviews that lead them to form different but equally valid understandings of the system context and their respective contributions to developing the system within the project environment. Because they cannot be explained away or analyzed out, these differences in perspective must be understood and considered in formulating problems and creating potential solutions. While sources of complexity are varied, it is people representing independent entities (organizations or groups) that are associated with the project and the system under development by the project who must interact to align their roles and responsibilities with people from other independent entities. “At the heart of any complex system is a set of interacting agents. If we track who interacts with whom, we can uncover a network of connections among the agents” (Miller, 2015). In the context of interface management, we begin by identifying entities contributing to the project and the system under development, including those extending beyond the project scope boundary that can affect system design and development. Then we can begin to group these entities by their relationships to define which independent entities need to interact with which other entities for the purpose of aligning interfaces, and the interdependencies related to these interfaces. Stakeholders, and the processes for identifying them, are described later on, along with their application during early project planning.

2.5.1 ​Stakeholder Classes

The spectrum of stakeholder classes ranges from those directly involved in delivering the project and the system of interest to those outside the discrete project scope boundary, but which can exert influence on, intervene in, or be affected by, the project and the design, development, and operation of the system of interest. While classes of stakeholders who are directly involved with the delivery of the project may be more obvious during the stakeholder identification process—such as contractors delivering various elements of the system of interest—those stakeholders extending beyond the discrete boundary can be more difficult to identify and more difficult to group into interface networks (also known as interaction networks). It may also be more difficult to determine their specific needs and requirements. As noted by Aaltonen (2011), by conducting stakeholder analysis, project and technical managers attempt to build a correct picture of their stakeholder environment—a picture upon which appropriate organizational action concerning stakeholders can be determined. Building the correct picture of the stakeholder environment, however, is not as straightforward as current managerial methods and tools of stakeholder analysis would suggest (Aaltonen, 2011). Part of the challenge in building the correct picture is the need to understand those stakeholders that can influence

38

Project Interface Management

or intrude upon project and SE management, assess their potential degree of intrusiveness, and determine when in the project development process these stakeholders are expected to exert their influence. As stated, it is common to divide the stakeholders into internal and external stakeholder groups (Aaltonen, 2011). Internal stakeholders are entities that are formal members of the project and support the project (Morris and Pinto, 2004). These entities are often referred to as primary stakeholders (Cleland, 1998) or business actors (Cova and Salle, 2005); and they reside within the discrete project scope boundary as illustrated in Figure 2.1. Internal stakeholders have a formal, official, or controlling relationship, such as contractual, with the sponsoring organization and are directly contributing to the realization of the project result. Internal stakeholder classes may include, for example, contractors, clients, vendors, subcontractors, and sponsoring organizations. External project stakeholders are not formal members of the project coalition, but may be affected by the project positively or negatively, or may intervene in the project through influence. Such groups are often referred to as non-business stakeholders (Cova and Salle, 2005) or secondary stakeholders (Mitchell et al., 1997), and extend beyond the project’s discrete scope boundary and into its sphere of influence. External classes of stakeholders may include, for example, industry regulators, local communities, environmental groups, etc. The impact of stakeholder entities whose interests and demands need to be considered to ensure the success of the project has been well documented (Cleland, 1986; Diallo and Thuillier, 2005; and Olander and Landin, 2005). It is a widely acknowledged assumption in both project management literature and in guidelines for infrastructure projects (IFC, 2007) that the project preparation phase is a stage during which stakeholders with differing opinions and objectives have the best opportunity to affect the project’s objectives and outcomes (IFC, 2007; PMI, 2013). Lack of understanding of the various external stakeholder entities, the rationale behind their actions, and their potential to

Figure 2.1  Project stakeholder entities

Understanding Project Complexity

39

exert influence during the project life cycle have been identified as major challenges in international projects (IFC, 2007). Both the systems engineering and project management domains prescribe processes related to stakeholder management in order to address both technical and nontechnical complexity from stakeholder sources in the project environment. Both domains’ stakeholder management processes emphasize the importance of identifying stakeholders early during project planning and as part of initial SE activities. In the next section, we summarize the project management and SE management stakeholder management processes used early in the project as described in the Project Management Body of Knowledge (PMBOK ® Guide) (PMI, 2017) and the Guide to the Systems Engineering Body of Knowledge (SEBoK) (BKCASE, 2016), as arguably two of the most popular and representative sources on the subject in use today.

2.5.2 Project Management Stakeholder Analysis Process

PMI in its PMBOK ® Guide defines ten Knowledge Areas by which the processes are classified; one of those Knowledge Areas is Project Stakeholder Management. PMI states, “Project Stakeholder Management includes the processes required to identify the people, groups or organizations that could impact or be impacted by the project, to analyze stakeholder expectations and their impact on the project, and to develop appropriate management strategies for effectively engaging stakeholders in project decisions and execution” (PMI, 2017). The Project Stakeholder Management Knowledge Area consists of four processes: Identify Stakeholders, Plan Stakeholder Engagement, Manage Stakeholder Engagement, and Monitor Stakeholder Engagement. These are iterative and overlapping processes that “support the work of the project team to analyze stakeholder expectations, assess the degree to which they impact or are impacted by the project, and develop strategies to effectively engage stakeholders in support of project decisions” (and work) (PMI, 2017). Stakeholders include customers, contractor companies, vendors, suppliers, and project sponsors or partners; other organizations which are contributing directly to the project; the public which are actively involved in or affected by the project and project partners; and government oversight entities, among others who are indirectly involved with the project’s development process. As PMI notes, project stakeholders should be identified initially as the project charter is developed and then regularly at the start of each phase or when the project changes over time, and also documented to allow the project team to define how to engage each stakeholder or group of stakeholders appropriately (PMI, 2017). In several of its standards documents including the PMBOK ® Guide, PMI describes each process using inputs, tools and techniques, and outputs. It does so for both the Identify Stakeholders and Plan Stakeholder Engagement processes, which in this book are together called stakeholder analysis. PMI describes Identify Stakeholders as “the process of identifying project stakeholders regularly and analyzing and documenting relevant information regarding their interests, involvement, interdependencies, influence, and potential impact on project success” (PMI, 2017). PMI describes Plan Stakeholder Engagement as “the process of developing approaches to involve project stakeholders based on their needs, expectations, interests, and potential impact on the project. The key benefit is that it provides an actionable plan to interact effectively with stakeholders” (PMI, 2017). PMI goes on to suggest that the process be performed periodically as needed, for example, when stakeholders are added or their influence changes.

2.5.2.1 Stakeholder Analysis Inputs

Inputs are project-related documents that help to identify independent entities involved in the design and development of the system developed by the project, or entities that can influence or intervene in the projects. PMI’s Identify Stakeholders process specifies several inputs: the project

40

Project Interface Management

charter, business case and benefits management plan, relevant sections of the project management plan, agreements and contracts, and other related documents (PMI, 2017). In addition to organizational assets and enterprise environmental factors, these documents provide the inputs needed to perform the Identify Stakeholders process. The project charter provides basic information about the project and usually includes the common vision of the key stakeholders; it identifies the internal and external stakeholders affected by the result or the execution of the project. Procurement documents are important inputs as well as they are issued in accordance with the contract strategy to procure project products and services, and often, to segment the project into various elements. These documents can also address company-provided items, such as proprietary software, specialized equipment, black box equipment, etc. In addition to these inputs, the Stakeholder Register produced by the Identify Stakeholders process is an important input to the Plan Stakeholder Engagement process. Enterprise environmental factor information can be useful in understanding the industry, governing regulations and standards, and the organizational culture and structure of the sponsoring organization. Finally, organizational process assets can provide stakeholder registers and templates from previous projects and lessons learned that are relevant to the new project (PMI, 2017). The project management plan or plan for development and operations (or similarly named document) can provide a wealth of knowledge about the intended approach for developing the project— including key milestones, stage gates, entrance and exit criteria, major risks affecting the project, and tentative plans for transitioning the project into operations. Currently, it is typical to undertake an environmental impact study for many major or large-scale projects. These studies can be quite useful in identifying major environmental issues impacted by the project and the various relevant interest groups. Concept of Employment (COE), often used by the U.S. Department of Defense to describe the background, purpose, and uses of a proposed system, provides a high-level description of major operations or missions to be performed by the system under development by the project. Architecture framework products can also be useful in understanding the project environment by helping to develop a clear understanding of other systems the project must integrate with to operate effectively. However, the usefulness of these products depends on the quality and availability of documents and informational assets. In relatively new project organizations or those with little project management maturity, these assets may not provide the necessary information. Further, even if available, the applicability of these assets to the new project may be limited. Many assumptions are built into the stakeholder analysis process that may not reflect reality in a given circumstance and thus may limit its effectiveness. This is not to suggest the stakeholder analysis process is not useful, but users of this process should not limit their inputs only to those suggested in the PMBOK ® Guide or any other specific source. Other artifacts, such as architecture framework views or viewpoints, may be useful for identifying stakeholders. John Zachman, one of the recognized founders of architecture framework concepts, opines, “Seven thousand years of human history would establish that the key to complexity and change is Architecture. If it (whatever it is) gets so complex that you can’t remember everything all at the same time, you have to write it down (Architecture). Then, if you want to change it (whatever it is), you start with what you wrote down (Architecture), the baseline for managing change” (Zachman, 2002). Now that the Information Age has succeeded the Industrial Age, it has become necessary to supplant what has been learned about architecture for increasingly complex products with architecture for the enterprise. Enterprises rely on information and that information must be delivered to the people who need it in an enterprise which is constantly changing and becoming more complex. A key aspect of Zachman’s position is the role architecture plays with respect to understanding and controlling complexity; that is, at some point, an enterprise (or anything else) reaches a degree

Understanding Project Complexity

41

of complexity requiring an architecture to enable it to survive and thrive. In certain industries—such as the defense industry—it is common for programs and projects to use architecture frameworks to aid in understanding the project’s context within the larger enterprise organization. Context is communicated through a number of views and subsequent viewpoints, such as operational views. For interface management purposes, these views can be quite useful in visualizing the project environment as it will be during the operation of the system and in identifying entities with which the project must interact to align interfaces and interdependencies prior to transitioning to operation.

2.5.2.2 Stakeholder Analysis Tools and Techniques

According to PMI, the tools and techniques for identifying and planning engagement of stakeholders include expert judgment, data gathering (e.g., benchmarking), data analysis techniques (e.g., assumption and constraint analysis, root cause analysis, etc.), decision techniques (e.g., prioritization), data representation (e.g., mind mapping and stakeholder engagement assessment matrices), and, of course, meetings to discuss the input and develop first the stakeholder register and then the stakeholder engagement plan (PMI, 2017). Several classification models noted by PMI for stakeholder analysis include: (1) power/influence grid, (2) power/interest grid, (3) influence/impact grid, (4) salience model, and although not specifically named by PMI, (5) organization politics mapping tool (OPMT). The grids group stakeholders based on their power/influence and their active involvement (influence/interest) with respect to project outcomes. The salience model groups stakeholders based on their power, urgency, and legitimacy (Mitchell et al., 1997). The OPMT assesses the relationships among stakeholders, degree of organizational influence, and degree of applied influence at a particular point in time (DeLuca, 1999). Several examples of such grids are widely used and tailored in various ways. A commonly used and simplified example of a power/influence grid is shown in Figure 2.2. Stakeholder influence and power can be plotted on this grid together with recommended actions for addressing each of the major stakeholders, particularly those in the upper right quadrant, but with due attention to those in other quadrants.

HIGH Manage Closely

Monitor

Keep Informed

POWER

Keep Satisfied

LOW LOW

INFLUENCE

Figure 2.2  Power/Influence grid (PMI, 2013 and various similar models)

HIGH

42

Project Interface Management

2.5.2.3 Identify Stakeholder and Plan Stakeholder Engagement Outputs

The main output of the Identify Stakeholders analysis process is the stakeholder register, which contains stakeholder identification information, assessment information, and classification. Identification information includes the name of the stakeholder, their organizational position, location, role in the project or with respect to the project, and contact information. Assessment information may also provide a stakeholder’s significant requirements, expectations, influence level, phase in the project with the most interest, and classification if using the grid models described previously. The main output of the Plan Stakeholder Engagement process is the stakeholder engagement plan, which becomes “a component of the project management plan that identifies the strategies and actions required to promote productive involvement of stakeholders in decision making and execution” (PMI, 2017). PMI goes on to say that this plan “may include but is not limited to specific strategies or approaches for engaging individuals or groups of stakeholders” (PMI, 2017). Of course, other project documents can be affected by the results of stakeholder analysis, such as change requests, project management plan updates, risk registers, issue logs, etc.

2.5.2.4 Identify Stakeholder and Plan Stakeholder Engagement Discussion

Initially, the stakeholder analysis processes are performed by the project’s sponsoring organization during the early project planning phase. Remember, project development can take many forms and often involves the awarding of parts of the project’s scope of work to many different parties, such as contractor companies, often at different times. In these cases, the project sponsor’s organization normally maintains a management team to oversee and govern work by respective contractors and maintains project management systems that integrate the project as a whole. Thus, the project’s sponsoring organization performs project processes and then, as contracts are awarded, contractors perform these processes for their respective scopes of work. Naturally, stakeholders identified from the perspective of the project’s sponsoring organization will differ from those for a prime contractor responsible for a part of the project scope, and they will differ from those of the operator, etc. The outputs of these processes can be key inputs to interface analysis, described later in the book.

2.5.3 ​Systems Engineering Stakeholder Analysis Process

The SE domain has a corresponding technical process that also addresses stakeholders. These stakeholders are directly or indirectly associated with the design and development of the system (i.e., the project result). A project translates an idea or concept into a tangible result. This is accomplished through an SE process to architect, design, procure, and construct a system such that it can be transitioned into operation. To identify stakeholder requirements that can provide the capabilities needed by users and other stakeholders in a defined environment, the SE domain prescribes the use of the stakeholder’s needs and requirements definition technical process (INCOSE, 2015). From the SE viewpoint, a stakeholder is any entity (individual or organization) with a legitimate interest in the system, which can be “. . . users, operators, organizations, decision makers, parties to the agreement, regulatory bodies, developing agencies, supporting organizations, and society at large” (INCOSE, 2015). “Stakeholder requirements play major roles in SE, as they: • Form the basis of system requirements activities • Form the basis of system validation and stakeholder acceptance • Act as a reference for integration and verification activities

Understanding Project Complexity

43

• Serve as a means of communication between the technical staff, management, project organization departments, and the stakeholder community” (INCOSE, 2015) As noted by INCOSE, it is important for SE “. . . to pay close attention to interfaces where two or more systems or system elements work together, and establish an interaction network with stakeholders and other organizational units . . .” INCOSE therefore recognizes that while interfaces exist within and between the elements of the system being developed by the project, these interfaces create interdependencies between the systems and elements during operation that must be designed and aligned by appropriate entities during project development. Thus, various classes of stakeholders, through proactive interaction, must align system interfaces. A full description of SE stakeholder processes can be found in the SEBoK (BKCASE, 2016). The current version of the SEBoK can be downloaded at no charge (at this writing) from http://sebokwiki .org/wiki/Download_SEBoK_PDF. The SEBoK specifies three processes related to stakeholders that are applicable for this book: (1) business or mission analysis, (2) stakeholder needs and analysis and (3) system requirements.

2.5.3.1 ​Business or Mission Analysis

Business or mission analysis (B/MA) focuses on the needs and requirements of the business or enterprise that: • Defines the problem or opportunity that exists (in what is often called the problem space or problem situation) • Understands the constraints on, and boundaries of, the selected system when it is fielded (in what is often called the solution space) B/MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. “During the concept definition stage of a life cycle, as the enterprise identifies new capabilities that are desired, the business or mission analysis develops a high level set of strategies and needs (which may be expressed as mission or business requirements) that reflect the problem space perspective” (INCOSE, 2015). For a military entity, this can mean a program to increase or enhance an existing military capability. For an industry entity, this can mean a project to create value in a new business area or to improve market position. “As the solution space is explored, and solution classes are characterized, stakeholder needs are developed and transformed into stakeholder requirements (from a user perspective)” (INCOSE, 2015). “After the solution class has been determined and the specific solution is sought, during the system definition stage of a life cycle, the stakeholder requirements are transformed into system requirements (from a solution perspective). As the system definition recursively defines the lower level detail of the solution, requirements are defined with lower levels of abstraction. At the highest level, the ideal requirement is implementation-independent, and therefore not specific to a solution, allowing for a range of possible solutions. At their lowest level, requirements statements may become more specific to the selected solution” (INCOSE, 2015). “The starting point of engineering any system-of-interest (SoI) (the project’s result), is understanding the socioeconomic and technological context in which potential problems or opportunities reside. Then, the enterprise strategic goals and stakeholder needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of business or enterprise decision makers while also taking into account the views of users, acquirers, and customers” (BKCASE, 2016). Here, we see involvement of SE early in the consideration of the project or program. This involvement takes the form of assessing the feasibility of the business concept and how the concept can be

44

Project Interface Management

achieved to deliver the most value in terms of business need—at the lowest cost while delivering the highest quality.

2.5.3.2 ​Stakeholder Needs and Requirements

“The stakeholder needs and requirements (SNR) process explores and defines the operational aspects of a potential solution for the stakeholders from their point of view, independent of any specific solution. In these two concept definition activities, business or enterprise decision makers and other stakeholders describe what a solution should accomplish and why it is needed. Both why and what need to be answered before consideration is given to how the problem will be addressed (i.e., what type of solution will be implemented) and how the solution will be defined and developed” (BKCASE, 2016). In describing the main purpose of the SNR activity during concept definition, the Guide to the SEBoK (BKCASE, 2016) states, “The stakeholder needs and requirements activity works with stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives for a desired solution to the problem or opportunity, referred to as “stakeholder needs.” The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements. The SNR activities identify and define the needs and requirements of the stakeholders, in a manner that enables the characterization of the solution alternatives” (BKCASE, 2016). New projects typically begin with an exploratory research phase, which generally includes the process of concept definition, which includes two main activities: analyzing the business or mission and understanding the SNR. These mature as the project goes from the exploratory stage to the concept stage to the development stage. “Mission analysis takes the business and stakeholders’ needs and requirements and carries the analysis down from problem space to solution space, including concept, mission, and boundary or context so that a solution concept (at the black-box level) can be selected from the alternatives” (BKCASE, 2016). 2.5.3.2.1 ​Identifying Stakeholders Since stakeholders of an SoI often vary throughout the life cycle, the Guide to the SEBoK suggests that “. . . in order to get a complete set of needs and subsequent requirements, it is important to consider all stages of the life-cycle model when identifying the stakeholders or classes of stakeholders.” It goes on to say, “For each stage, a list of all stakeholders having an interest in the future system must be identified. The goal is to get every stakeholder’s point of view for every stage of the system life in order to consolidate a complete set of stakeholder needs that can be prioritized and transformed into the set of stakeholder requirements as exhaustively as possible” (BKCASE, 2016). 2.5.3.2.2 ​Identifying Stakeholder Needs After the why and what of the concept definition stage are established, definition of stakeholder needs can begin. “Once business management is satisfied their needs and requirements are reasonably complete, they pass them on to the business operations team. Here, the stakeholder needs and requirements (SNR) definition process uses the Concept of Operations (ConOps) or the strategic business plan (SBP) and life-cycle concepts as guidance. The requirements engineer (RE) or business analyst (BA) leads stakeholders from the business operations layer through a structured process to elicit stakeholder needs—in the form of a refined ConOps or similar document and other life-cycle concepts” and suggests that the requirements engineer or business analyst use “a structured process to elicit specific needs as documented in user stories, use cases, scenarios, system concepts, or operational concepts” (BKCASE, 2016).

Understanding Project Complexity

45

2.5.3.2.3 ​Identifying Stakeholder Requirements Continuing from the Guide to the SEBoK, “Stakeholder needs are transformed into a formal set of stakeholder requirements, which are captured as models or documented as textual requirements in an output typically called a stakeholder requirement specification, stakeholder requirement document, or something similar. That transformation should be guided by a well-defined, repeatable, rigorous, and documented process of requirements analysis. This requirements analysis may involve the use of functional flow diagrams, timeline analysis, N2 diagrams, design reference missions, modeling and simulations, organizational information assets (movies and pictures), states and modes analysis, fault tree analysis, failure modes and effects analysis, and trade studies” (BKCASE, 2016). 2.5.3.2.4 ​Collecting Stakeholder Needs and Requirements Among the many ways to collect SNR, the Guide to the SEBoK recommends that several of the following techniques or approaches be considered while eliciting requirements to appropriately accommodate each of the diverse sets of sources: • • • • • • • • •

Structured brainstorming workshops Interviews and questionnaires Technical, operational, and/or strategy documentation review Simulations and visualizations Prototyping Modeling Feedback from verification and validation processes Review of the outcomes from the system analysis process (ISO/IEC 2015) Quality function deployment—can be used during the needs analysis and is a technique for deploying the voice of the customer. It provides a fast way to translate customer needs into requirements (Hauser and Clausing, 1988) • Use case diagrams (OMG, 2010) • Activity diagrams (OMG, 2010) • Functional flow block diagrams (Oliver et al., 1997) 2.5.3.2.5 ​Classification of Stakeholder Requirements The Guide to the SEBoK states that several classifications of stakeholder requirements are available. It references ISO/IEC 29148, section 9.4.2.3 (ISO 2011) as providing a useful set of elements for classification. “Examples of classification of stakeholder requirements include: service or functional, operational, interface, environmental, human factors, logistical, maintenance, design, production, verification requirements, validation, deployment, training, certification, retirement, regulatory, environmental, reliability, availability, maintainability, design, usability, quality, safety, and security requirements. Stakeholders will also be faced with a number of constraints, including: enterprise, business, project, design, realization, and process constraints” (BKCASE, 2016).

2.6 ​SETTING THE STAGE FOR STAKEHOLDER AND INTERFACE MANAGEMENT What should become apparent is the challenge of aligning all the actors associated with the project, either directly or indirectly, and identifying their needs and requirements clearly and completely early in project planning. From the description of the project management and SE stakeholder

46

Project Interface Management

analysis processes, one can appreciate the considerable effort and attention needed to achieve such elicitation and alignment. During the stakeholder analysis process, we can fully appreciate that a number of different independent actors are associated with the project. Each of these stakeholders has its own motivations and self-interest with differing and often conflicting timelines and requirements. The resulting unpredictability of their actions and responses, occurring over a project life cycle that can span many years, is a great contributor to complexity. Although it may present a major challenge, applying an effective stakeholder analysis process can help to obtain the correct picture, and the frameworks provided by the PMBOK ® Guide and SEBoK can be of great assistance. Perhaps more than any other element of large-scale complex projects, aligning these entities and their needs and requirements is the most important element to prevent or mitigate the impact of surprises rooted in not getting it right during planning; how well this is done will be felt throughout project development and delivery. A close examination of the project management and SE stakeholder processes reveals an interesting dynamic. The project management stakeholder process tends to focus outward toward identifying stakeholders outside the project’s discrete scope boundary, or at least outside the immediate project team. This includes organizational departments supporting the project, project partners, oversight and regulatory agencies, other independent projects, and existing facilities to name a few. Conversely, the SE stakeholder process tends to focus inward within the project’s discrete scope boundary, perhaps because it is focused on engineering. Later in the book, the interface analysis process begins to align these two processes and domains to identify, organize, and simplify interfaces, interdependencies, and interactions, both between independent entities contributing directly to project development and with those independent entities that can influence and intervene in the project.

2.7 ​SUMMARY In this chapter, we discussed complexity and the importance of understanding what complexity is in general and, more specifically, how it applies to the project context. Complexity is not easily understood nor simply defined; the foundation for managing complexity requires considerable thought during early project planning. Project management systems need to recognize elements or factors contributing to project complexity and implement appropriate management systems capable of monitoring and controlling these elements or factors. Of course, one cannot control the unpredictable outcomes or behaviors inherent in complexity; however, anticipating, assessing, and adjusting for them is mandatory. One aspect of complexity relates to interfaces, interdependencies, and interactions among independent entities that are contributing to project development—and between the project and those entities that can influence or intervene in project development. Stakeholder analysis processes from the disciplines of project management and SE provide mechanisms to begin unraveling the complicated web of stakeholders intertwined in the project’s development, but further effort is needed to structure these stakeholders such that the interfaces and interdependencies between them can be managed through a transparent and traceable project management system. The outputs of the stakeholder analysis process provide valuable insight as to the entities within and those outside of the project, including their roles and responsibilities as the project progresses through its life cycle. This information helps to feed the interface management processes that will be described in later chapters. Whereas the stakeholder analysis process discussed in this chapter helps to answer who is involved and what their major needs and requirements are, the interface analysis process introduced in Chapter 5 further establishes the means to structure the project and interface management systems in order to manage these needs and requirements. It will build directly on the

Understanding Project Complexity

47

stakeholder analysis process outputs described in this chapter. In the next few chapters, we begin to structure the project’s interface management system. First, however, in Chapter 3, we want to introduce interface management, then describe the interface management process in Chapter 4 to ensure a common understanding of interface management before taking a deeper dive into each stage in the practice of interface management.

2.8 ​REFERENCES Aaltonen, Kirsi. (2011). “Project stakeholder analysis as an environmental interpretation process.” International Journal of Project Management 29, no. 2: 165–183. Baccarini, D. (1996). “The concept of project complexity—a review.” International Journal of Project Management, Vp;/14. Mp/4/1996: 201–204. Bennett, J. (1991). International Construction Project Management: General Theory and Practice. ButterworthHeinemann, Oxford, UK. BKCASE Editorial Board. (2016). The Guide to the Systems Engineering Body of Knowledge (SEBoK), v. 1.6. R.D. Adcock (EIC). Hoboken, NJ: The Trustees of the Stevens Institute of Technology. Accessed August 07, 2016. www.sebokwiki.org. BKCASE is managed and maintained by the Stevens Institute of Technology Systems Engineering Research Center, the International Council on Systems Engineering, and the Institute of Electrical and Electronics Engineers Computer Society. Buede, Dennis M. (2011). The Engineering Design of Systems: Models and Methods. Vol. 55. John Wiley & Sons, Inc., Hoboken, NJ. Checkland, Page B. (1999). Systems Thinking, Systems Practice. John Wiley & Sons, Inc., Chichester, UK. Cleland, David I. (1986). Project Stakeholder Management. John Wiley & Sons, Inc., Hoboken, NJ. Cleland, David I. (1998). “Stakeholder management.” Project Management Handbook: 55–72. Collyer, Simon and Clive M. J. Warren. (2009). “Project management approaches for dynamic environments.” International Journal of Project Management 27, no. 4: 355–364. Cooke-Davies, T. and L. Crawford. (2011). Aspects of Complexity: Managing Projects in a Complex World. Project Management Institute. Cova, Bernard and Robert Salle. (2005). “Six key points to merge project marketing into project management.” International Journal of Project Management 23, no. 5: 354–359. DeLuca, J. R. (1999). Political Savvy. EBG Publications, Berwyn, PA. Diallo, A. and D. Thuillier. (2005). “The success of international development projects, trust and communication: an African perspective.” International Journal of Project Management 23 (3): 237–252. Hauser, J. and D. Clausing. (1988). “The House of Quality.” Harvard Business Review. (May–June 1988). IFC. (2007). Engagement, Stakeholder. “A good practice handbook for Companies Doing Business in Emerging Markets.” IFC, World Bank Group. INCOSE. (2015). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 4.0. John Wiley & Sons, Inc., Hoboken, NJ. INCOSE. Complex Systems Working Group. (2016). Description of group purpose. Retrieved August 8, 2016 from http://www.incose.org/docs/default-source/default-document-library/complex-systems-wg-info -paper.pdf?sfvrsn=0. INCOSE. (2016). “Complex Systems Working Group Mission and Objectives.” Accessed 15 April 2016. http:// www.incose.org/ChaptersGroups/WorkingGroups/knowledge/complex-systems. ISO/IEC/IEEE. (2011). Systems and Software Engineering—Requirements Engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148. Kamensky, John F. (2012). “Managing the Complicated vs. the Complex.” IBM Center for The Business of Government. Retrieved July 16, 2016 from http://www.businessofgovernment.org/sites/default/files/ JohnKamensky.pdf. Kline, S. 1995. Foundations of Multidisciplinary Thinking. Stanford, CA, USA: Stanford University Press. Kossiakoff, A. and William N. Sweet. (2003). Systems Engineering Principles and Practice–First Edition. John Wiley & Sons, Inc., Hoboken, NJ.

48

Project Interface Management

Merrow, Edward W. (2012). “Oil and gas industry megaprojects: Our recent track record.” Oil and Gas Facilities 1, no. 2: 38–42. Miller, John H. (2015). A Crude Look at the Whole: The Science of Complex Systems in Business, Life, and Society. Basic Books (Perseus Books Group), New York, NY. Mitchell, Ronald K., Bradley R. Agle, and Donna J. Wood. (1997). “Toward a theory of stakeholder identification and salience: Defining the principle of who and what really counts.” Academy of Management Review 22, no. 4: 853–886. Morowitz, Harold J. (2002). The Emergence of Everything: How the World Became Complex. Oxford University Press, Oxford, UK. Morris, Peter W. G., and George H. Hough. (1987). The Anatomy of Major Projects: A Study of the Reality of Project Management. John Wiley & Sons, Inc., Hoboken, NJ. Morris, Peter W. G. and Jeffrey K. Pinto. (2004). The Wiley Guide to Managing Projects. John Wiley & Sons, Inc., Hoboken, NJ. Nidiffer, Kenneth E. and Dana Dolan. (2005). “Evolving distributed project management.” Software, IEEE 22, no. 5: 63–72. Nooteboom, Uri. (2004). “Interface management improves on-time, on-budget delivery of megaprojects.” Journal of Petroleum Technology 56, no. 08: 32–34. Olander, Stefan and Anne Landin. (2005). “Evaluation of stakeholder influence in the implementation of construction projects.” International journal of project management 23, no. 4: 321–328. Oliver, D., T. Kelliher, and J. Keegan. (1997). Engineering Complex Systems with Models and Objects. McGrawHill, New York, NY. Olsen, Bjørn Erik, Sven A. Haugland, Edgar Karlsen, and Geir Johan Husøy. (2005). “Governance of complex procurements in the oil and gas industry.” Journal of Purchasing and Supply Management 11, no. 1: 1–13. OMG. (2010). OMG Systems Modeling Language Specification, version 1.2. Needham, MA: Object Management Groupage, July 2010. Petit, Yvan and Brian Hobbs. (2010). “Project portfolios in dynamic environments: Sources of uncertainty and sensing mechanisms.” Project Management Journal 41, no. 4: 46–58. Piciaccia, L. A., Tore Faanes, and Hans Jørgen Lindland. (2004). “2.2. 2 Complexity and change in the subsea oil production industry.” In INCOSE International Symposium, vol. 14, no. 1: 257–272. Project Management Institute (PMI). (2017). A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 6th Edition. Project Management Institute, Newtown Square, PA. Rowlinson, Stephen M. (1988). “An analysis of factors affecting project performance in industrial buildings with particular reference to design build contracts.” PhD diss., Brunel University School of Engineering and Design PhD Thesis. Sargut, Gökce and Rita Gunther McGrath. (2011). “Learning to Live with Complexity.” Harvard Business Review 89, no. 9: 68–76. Thompson, J. D. (2003). Organizations in Action: Social Science Bases of Administrative Theory (Classics in Organization and Management Series). Transaction Publishers, New Brunswick, CT. Wasson, Charles S. (2006). System Analysis, Design, and Development Concepts, Principles, and Practices. John Wiley & Sons, Inc, Hoboken, NJ. Whitty, Stephen Jonathan and Harvey Maylor. (2009). “And then came complex project management (revised).” International Journal of Project Management 27, no. 3: 304–310. Williams, Terry, Ole Jonny Klakegg, Derek H. T. Walker, Bjørn Andersen, and Ole Morten Magnussen. (2012) “Identifying and acting on early warning signs in complex projects.” Project Management Journal 43, no. 2: 37–53. Zachman, John. (2002). “The Zachman framework for enterprise architecture.” Zachman International 79.

3

Interface Management Introduction “The concept of randomness and coincidence will be obsolete when people can finally define a formulation of patterned interaction between all things within the universe.” —Toba Beta

Modern projects are increasingly difficult to execute as the systems they develop increase in complexity and project execution strategies become more complicated. Whether the project is delivering a new product, service, or supporting recovery of natural resources, system complexity and project complication continues to increase. As project execution strategies evolve to deliver ever more complicated or complex systems, management practices must evolve to reduce risk and ensure successful project completion to achieve business objectives. Major industrial capital projects are inherently risky due to long planning and execution timelines and complex interfaces between the project and its context, and among different parts of the project (Flyvbjerg, 2007). As the number of independent entities contributing to the project increases, more interaction between the entities will be required. Interface management is a project management and systems engineering (SE) management discipline applied to address risk associated with project interfaces and the interactions they require—both internal to the project and between external entities that can influence the project. To increase the chance of project success, complexities among the various systems being delivered by the project and among the stakeholders involved in the project must be managed and the accompanying risk reduced. This can be accomplished by establishing a simple, logical, and transparent management structure among the various independent entities contributing to large-scale complex projects. In this chapter, we introduce interface management, including key concepts, definitions, and terminology to be used throughout the remainder of the book.

3.1 ​THE BASICS OF INTERFACE MANAGEMENT Interface management has become an essential management function as projects continue to increase in size and technical complexity, with stakeholders located across the globe, speaking multiple languages, and sharing significant cultural differences. Global competitiveness and the opening of new markets are providing organizations with opportunities to contract segments of their projects to various entities around the world. While this offers many economic benefits for organizations, it also introduces risk. Without effective and timely communication, and the exchange of vital information among the various parties as the project progresses across the various phases, the likelihood of errors 49

50

Project Interface Management

and misalignment increases, resulting in costly problems during integration when combining various aspects of the technical solution. These problems are a major contributor to cost and schedule overruns that are common, even endemic, to complex projects. We propose that these errors and problems are controllable and preventable by employing the relatively new discipline of interface management. On large complex projects with complicated contract strategies, the awarding of contracts is almost never exact and alignment among the disparate project schedules is rarely attained. Commonly on such projects, the interface stakeholders (delivery teams, contractors, subcontractors, vendors, and suppliers) have neither mutual contractual obligation with each other nor the means to control their implied but often unrecognized relationships. In such cases, the project owner and/or owner’s representatives must facilitate communication and collaboration among these parties to ensure that critical information and material is exchanged and that the various segments of the project can integrate seamlessly later in project execution. Also, the project owner and each party to such relationships must ensure that appropriate information, material, and equipment are given to the other parties in a timely manner in order to prevent negative consequences. The goals of interface management are to: • Reduce or eliminate ambiguity with regard to responsibilities across the explicit and implicit boundaries • Facilitate and encourage open communication among stakeholders • Ensure agreements and common understanding are obtained between nonbinding parties • Maintain transparency of critical project issues between independent entities • Reduce risk by minimizing the possibility of miscommunication Managing the complexity of stakeholder interactions is key to reducing a major risk associated with large-scale complex projects—ensuring alignment among the various parties contributing to design, development, and delivery of the project. The main goal of the project sponsor is to complete the project within project constraints of cost, schedule, and scope (including quality). By proactively and systematically managing these complicated interactions throughout the project life cycle, the project sponsor and relevant parties can better confirm that each party’s scope of work and deliverables align with the scopes and deliverables of other relevant parties; and that when these deliverables are integrated with one another, they are integrated at the right time and connect together seamlessly— physically, logically, and functionally.

3.1.1 ​Recognizing Complexity

Uri Nooteboom, with nearly 40 years of experience in the design and implementation of offshore oil and gas subsea and floating production systems, has identified and stressed the importance of interface management, and calls it a missing link of project management. He further states that “Interface management has been a silent, hidden aspect of project management for a long time, but it was not specifically named or grasped until the rise of mega projects, many of which have suffered significant losses” (Nooteboom, 2004). We argue that interface management is also a missing link between project management and SE. Project management functions and SE processes must work in unison to design and deliver the system produced by the project in accordance with the system requirements while subject to project constraints of cost, schedule, and scope. Often, in large-scale complex projects, project management and SE are conducted in silos with little or no synergy between them. When projects are decomposed into various parts, and contracted out to various entities around the globe, multiple levels of interaction complexity are created among organizations, projects, and technical

Interface Management Introduction

51

disciplines. If not managed properly, these complexities manifest themselves as costly problems during the integration process. We further argue that interface management is also the missing link between organizations and their projects. Management of the entity that is sponsoring the project often assumes that internal organizational procedures are adequate to cover interactions between the organization and the project or among multiple projects within the same sponsoring entity. Inevitably, interface issues arise between the organization and the project; these interface issues require a formal mechanism to reach alignment between the project and the organization or among cooperating projects within the same organization. These interactions must be viewed as external influencers on the project and should therefore be managed accordingly. Modern large-scale projects typically require project parties to follow the organizational procedures and policies of the sponsoring entity. For example, the sponsoring organization may specify project control procedures, change processes, adherence to the protection of proprietary information or intellectual property, procedures for handling inquiries to industry oversight agencies and bodies, SE execution models, etc. Inevitably, these procedures and processes change over time and these changes may affect any projects that are being executed under previous procedures. Such changes represent potential disruptions, and thus, need to be fully communicated to the parties and agreed upon in order to prevent problems. Further, the organization may provide free issue or company provided items (CPIs) in support of parts of the project. For example, a military organization can provide armor protection kits for a system produced by the contractor, or an oil and gas operator may provide drilling well services for offshore projects. The free issue or CPIs are vital to the project and are often delivered as items along the project’s critical path, and by their very definition require interactions between the provider and the receiver. When these items are delayed or do not meet specifications or requirements, the project will be negatively affected.

3.1.2 ​Defining Interface Management

Given its relatively recent acceptance as a management practice, many definitions and descriptions of interface management exist and include: • “The management of common boundaries between people, systems, equipment, or concepts” (Nooteboom, 2004) • “The management of communication, coordination, and responsibility across a common boundary between two organizations, phases, or physical entities which are interdependent” (Wideman, 2002) We define interface management in this book as: the formal management process to identify, document, communicate, coordinate, monitor, control, and resolve issues occurring across common boundaries by independent projects, project phases, systems, contracts, scopes of work, or organizations. The definition implies alignment between project management and SE processes to ensure that consistent, transparent, and clear requirements are communicated among disparate parties contributing to a large-scale complex project, but without formal controlling relationships. This definition also accounts for entities extending beyond the project scope boundary but which have the ability to influence or intervene in the project. As with other project management and SE management practices, interface management must be viewed holistically and requires people, processes, procedures, tools, techniques, and training. In addition, interface management must be linked with existing project management and SE processes to align interfaces horizontally across all project entities and phases and vertically from within the project to the organization and external entities that influence the project.

52

Project Interface Management

3.2 ​INTERFACE CONCEPTS, DEFINITIONS, AND TERMINOLOGY Interface management facilitates open and transparent communication and interaction between interface parties through an interface management program or system. This ensures that project issues between nonbinding parties are coordinated in a manner that minimizes risk and provides appropriate information to help address problems quickly when they do arise. Through oversight of these interactions, interface management affords visibility to the project sponsor as well as giving the sponsor the ability to intervene to defuse potential situations that will negatively affect the project. Interface management cannot be discussed without a clear understanding of what an interface is and how it is distinguished from interface management. An interface is characterized as: • “A boundary where interdependency exists across that boundary and where responsibility for the interdependency changes across that boundary” (Healey, 1997) • “The contact point between relatively autonomous organizations which are interdependent and interacting to achieve some larger system objectives” (Wren, 1967) • “Common boundaries between people, systems, equipment, or concepts” (Nooteboom, 2004) An interface is a non-human thing subject to agreement between parties, while interface management relates to the people responsible for planning, coordinating, and executing this agreement. The essence of interface management is the relationship between interfaces, interdependencies, and interactions. Interfaces exist between components, subsystems, systems, and a system of systems. In turn, these interfaces create interdependencies within the system and the environment in which the system will operate. They also create interdependencies during project development for the entities responsible for delivering various segments of the project. To ensure alignment, the related parties who are associated with each interface must interact to coordinate design and development interdependencies associated with the interface. Such interaction for the purposes of interface alignment increases the chances of smooth integration, verification, and validation later in project execution. As previously noted, the boundary provides the basis for characterizing an interface, but interfaces do not resolve themselves. Rather, interfaces require people to proactively recognize and resolve them; more specifically, the people associated with each shared boundary must describe and define the interface between them, and agree upon how to resolve it. Too often in large-scale complex projects, the emphasis is on the interfaces, but not the entities involved in aligning those interfaces. Interface management focuses on both the interfaces themselves, and on the people (or entities) affected by these interfaces, including the way they must interact to resolve their interfaces.

3.2.1 ​Interface Defined

One of the most problematic aspects of interface management is a consistent understanding of what an interface is and is not within the project and SE community. In the real-world project community, views of what is and is not an interface vary widely. In large-scale complex projects, we must begin to think about interfaces more holistically across the project’s internal and relevant external environment. From this holistic view, we can apply the management practices that allow us to manage the full scope of interactions within and external to the project. For the purposes of this book, we define an interface as: a common boundary between two or more independent projects, systems/subsystems, contract scopes of work, organizations, or project phases; thusly requiring an exchange of data or information to obtain agreement between entities. Establishing a common interface definition provides the foundation for preventing interface problems when elements of the project that fall along the common boundaries are developed and

Interface Management Introduction

53

Figure 3.1  Interface between two parties

integrated. An interface recognizes an informational or material need between two (or more) independent parties as illustrated in Figure 3.1. The reader will note two underlined terms in the aforementioned definition: (1) common boundary and (2) independent. These terms are underlined because they identify two aspects crucial to defining what is and is not considered an interface. Both aspects are discussed later in the book in more depth, but here, the independent aspect of an interface means the lack of a controlling relationship between the parties sharing the common boundary. The common boundary aspect of an interface means that deliverables or functions from the independent parties will meet or interact. A controlling relationship is one in which the parties have some formal arrangement. For example, a client has a contract with a contractor. The contract forms the basis for a dependent (controlling) relationship. Specifically, the contractor agrees to provide the client with specific products and services in return for monetary payment. As expected, the contract describes the terms of the agreement between the two parties. Another example can be provided within a client’s project organization in the case of a project with multiple subprojects. Personnel within a given subproject must coordinate with each other because they have been assigned specific roles and responsibilities for the subproject’s scope of work. In this sense, the established roles and responsibilities for the subproject form the basis for a controlling relationship between the various subproject personnel. However, one subproject team may be required to coordinate with a separate subproject team to align project changes in scope that affect multiple parts of the project. In this situation, neither subproject team is controlled by the other. Thus, they need some mechanism to formally communicate, coordinate, and document agreements for boundaries between their two subproject scopes. The same analogy can be used for two different departments within the same organization. For example, the engineering department must coordinate and interact with the procurement department because their departments have been assigned specific roles and responsibilities within the organization relative to the project. However, in this case, neither department has a controlling relationship with the other, but each is dependent upon information and material to perform their related functions on the project. (We will describe the concept of a controlling relationship in more detail later in this chapter, but again this concept is key to understanding and defining an interface.) In some instances, existing processes and procedures may be adequate to govern interactions between the departments as might be the case in a mature organization with long-standing engineering, procurement, and construction processes. In many cases, though, the two example departments will require a formal interface management process. With the interface defined, the project team can assess and determine where in the project to apply interface management.

54

Project Interface Management

3.2.2 ​Interface Group

Two or more parties associated with a common boundary are referred to as an interface group (see Figure 3.2). For the purposes of this book, an interface group is defined as: a group consisting of two (or more) independent parties who share a common boundary but have a relationship with limited or no direct control over one another’s activities. As mentioned briefly previously, while these two parties share a common boundary, no formal control exists between the parties; this might be the case between two main contractors contracted to the same client on the same project. Each has a contract with the client, but no contract governs the relationship between the two main contractors; still, these entities must communicate and coordinate issues where their respective scopes of work collide to ensure successful integration with each other as they complete deliverables in their respective scopes of work. However, their need to communicate and coordinate is implicit rather than explicit. This can be problematic when neither party is under any obligation to the other party; that is, without a direct controlling relationship. While each of the two contractors illustrated in Figure 3.2 has its own scope of work and deliverables, when these two scopes are performed together on the same project and the deliverables must integrate or align with each other, managing the interfaces becomes important. Therefore, in the best interest of the project, interface groups must be identified and established to ensure the alignment of issues associated with their respective boundaries. Such alignment early in the appropriate planning stages can prevent interface problems (and accompanying cost and schedule overruns) when the various components and subsystems are delivered and integrated later during project development. Interface groups are identified by the project sponsor early in the project during project planning, preferably after the project management plan and contract strategy has been developed, but before project execution starts. To establish interface groups, common boundaries must first be identified and understood by all involved parties.

Contractor A

Contractor B

Interface Party

Interface Party

Interface Group Figure 3.2  Interface group consisting of two parties

3.2.3 ​Common Boundary

As mentioned in Section 3.2.1, the common boundary (also known as a battery limit) is a key interface management concept. Figure 3.3 shows two parties that are independent of one another in terms of maintaining control or responsibility; that is, each party has its own area of responsibility and does not have a means to directly influence the other. Yet, both parties share areas of responsibilities that are dependent upon one another. Let’s use the previous contractor example to help make the point. Each of two independent main contractors has its own contract with the same client for the same project; each is responsible for

Interface Management Introduction

55

Interface Party A

Interface Part B

Common Boundary Figure 3.3  Common boundary

its own respective scope of work. The contract, i.e., the mechanism of control, is with the client and not with the other contractor. In this example, neither contractor maintains any contractual relationship with the other. Thus, they are under no direct obligation to deliver any goods and services to each other. The lack of such a mutual contractual relationship means that these two contactors have no direct controlling mechanism to ensure they cooperate in the best interest of the project. However, when the products or services these contractors are delivering connect to each other, either physically or functionally, it becomes necessary for these independent contractors to interface with each other to align their respective boundaries. While the previous example involved one project with two independent contractors, in which the contracts defined the respective scopes and thus implicitly identified the common boundaries, other types of common boundaries can be established. For example: • Between two independent projects that integrate with each other—it is common for two different projects to integrate together into a large system-of-systems or supersystem • Between two different organizations (i.e., companies)—it is common for different companies to undertake projects that must integrate, or connect, to each other or into an existing system • Between two different technical disciplines (e.g., electrical and structural)—whether automation, control, electrical, or piping and mechanical; it is routine for technical disciplines to interface during the design and development process • Among functional departments such as risk management and safety—many issues require interface activities among an organization’s functional departments, such as global safety issues, alignment and response to industry oversight agencies, alignment and response to formal management, or technical queries from a project’s contractors, etc. Identifying common boundaries between the parties is accomplished by undertaking interface analysis of the system being developed and defining how the project will be executed over its lifetime. For example, the client has contracted with an architect to design a modern office building and has separately contracted with a construction company to build the office building. The architectural and the construction parties must communicate and collaborate to ensure the final product—the building—meets the client’s expectations and needs. Analysis of the architecture of the system to be developed for the project will also help to identify boundaries between the parties. For example, in developing an aircraft, the parties designing and developing the aircraft wings must collaborate with the party developing the fuselage as they have physical,

56

Project Interface Management

functional, and logical (signals and software) boundaries. These common boundaries are also useful for understanding the interface areas, issues, and items to address during interface activities.

3.2.4 ​Interface Areas, Issues, and Items

The interface groups described in Section 3.2.2 form the foundation for further defining the scope of interfaces between members of the groups; identifying the interface groups is prerequisite to defining interface areas, issues, and items. It should be noted that the intensity of interface interaction is dependent upon the scope of the interfaces between the respective parties. More interface scope will result in higher interface intensity between the groups. After establishing which interface parties share a common boundary (i.e., once the interface groups are defined), interface areas, issues, and items are identified for each group. As illustrated in Figure 3.4, an interface area flows down to the interface issues, which are further decomposed into interface items. This construct helps to simplify interface complexity into manageable elements and is used as part of the interface analysis process described in Chapter 5. An interface area is: a defined area of interest on the common boundary between two or more interface parties. An interface area (also known as interface point) is characterized by one or more interface issues, and requires interface parties to agree with the resolution of interface items associated with the issue. Interface areas represent discrete or specific segments along the common boundary that need to be aligned. For example, Interface Party A (aircraft fuselage) identifies hydraulic, electrical, and structural interface areas with Interface Party B (aircraft wing). These interface areas help to further define the scope of the interface with other parties and serve as a basis for identifying interface issues. For each interface area, there can be one or several interface issues. An interface issue is: a statement identifying specific aspects, such as physical or functional, of the interface area requiring interface activity with another interface party. These further decompose or break down the interface area into specific issues that need detailed interface activity. For example, Interface Party A (aircraft fuselage) identifies an electrical interface area with Interface Party B (aircraft wing). From this point, Interface Party A identifies interface issues such as power management system, wing lighting, mechanical control, etc. With interfaces issues identified, the interface parties can begin to derive specific interface items for each interface issue. For example, for two parties sharing an interface area such as the electrical

Interface Item Interface Issue Interface Item

Interface Area Interface Issue Figure 3.4  Interface areas, issues, and items

Interface Item

Interface Management Introduction

57

area, the power management system may be an issue that the two parties need to align since it crosses their respective boundaries. Other issues may include, for example, the alignment of power management system hardware compatibility to ensure that both parties have power management system physical components that can operate together. Several factors influence the intensity of the interface activity between interface parties; these factors may include the project plan for development, system architecture, and external influences on the project, among others. Some interface groups will have very intense interface activity because they share several interface areas, while others may require very little interface activity. For each interface issue, there can be one or several interface items that need to be resolved to fully resolve the issue. An interface item is: a specific interface data or information request(s) resulting from an interface issue, which is generated from one interface party toward another interface party. Interface items are typically coordinated using an interface management database tool and conducting interface management meetings with the respective interface groups. The items are coordinated and closed when an interface agreement has been reached by the parties. As illustrated in Figure 3.5, two parties share an electrical interface. Two issues have been identified that relate to the electrical area, for which three interface items must be addressed to resolve the electrical interface across the common boundary shared by the two parties. This construct can be used to analyze and decompose all categories and types of interfaces associated with the project and it helps to identify which parties need to interact to resolve interdependencies during project execution. More important, this construct provides a framework to ensure interface activity covers all relevant aspects across the project and between those entities that can influence or intervene in the project. A more detailed look at interface analysis is provided in Chapter 5.

3.2.5 ​Interface Agreement

When all interface items are resolved for an interface issue, the associated issue becomes resolved; when all interface issues are resolved for an interface area, the associated area becomes resolved. The objective of the interface group is to obtain agreement on all interface areas for the group. Caglar and Connolly state, “Interface agreements result in exchange of any project information generated by one party that is needed by another party in order that the other party can continue with its scheduled

Power Cable Specificaon Item Hardware Compability Issue Power Distribuon Board Item

Electrical Area Power Management Issue Figure 3.5  Electrical area example for interface area, issues, and items

Power Management Signal Item

58

Project Interface Management

project tasks. This can include but is not limited to the engineering drawings, specifications, design reports and calculations, equipment details and project schedule information, and delivery of free issue or CPIs. There is no limitation on the source of interface agreements. They can arise from several sources including members of the project team, contract requirements, responsibility matrices, customer requirements, third party vendors/suppliers, and other project contractors and project stakeholders” (Caglar, 2007). An interface agreement is reached when the parties accept the proposed solution. The interface agreement mutually acknowledges a specific resolution by two or more interface parties for an interface item. Interface agreements form the foundation for effective interface management since they represent progress toward resolving interface issues and areas along the common boundary. For example, Interface Party A submits an interface item to Interface Party B to confirm the pipe sizing at a specific physical interface point. While this is a simple example, reaching interface agreements can require significant effort. Some challenges to be aware of are: • Integrating the timing of the deliverables committed for the interface agreement into the schedules of both parties as well as into the overall integrated schedule • Incorporating the elements of the agreement into the action tracking system in order to monitor progress towards implementation • Monitoring to ensure the agreement is reflected in the respective parties’ project, e.g., included in engineering designs, fabrication timelines, and such • Assuring technical integrity of the systems, people, and processes associated with the interfaces—­system integrity assurance Obtaining the agreement between the interface parties for each interface item is essential to aligning the interfaces. An interface agreement is reached when both parties attain a suitable solution that addresses the concerns of both parties. When a suitable solution is reached, the item is said to be resolved. When all items for an interface issue are resolved, there is agreement at the issue level. When all issues for an interface area are resolved, there is agreement at the area level. When all interface areas are resolved, the interface group has achieved its objective. As can be expected, many factors impact the ease or difficulty in resolving interfaces. Remember, interface parties have no controlling relationship. Rather, they are dependent upon the willingness of each party to participate in good faith—which does not always happen. This topic will be discussed in more detail later in the book.

3.2.6 ​Interface Analysis

Interface analysis is a key component of interface management because the process provides the mechanism to begin understanding the breadth and depth of interfaces within and external to the project. Interface analysis answers questions about how to organize to ensure effective interface management and identifies the issues that need to be addressed among the relevant interface parties. The interface parties can be grouped during interface analysis to form interface networks; each interface network may include particular types of stakeholders or interfaces. Thus, interface analysis is defined as: the process of examining the project environment and system architecture to determine the scope of interfaces, both within and external to the project, from which to identify and organize interface networks, interface groups, and interface areas, issues, and items. As a top-down approach, interface analysis is conducted as part of early project planning and begins by obtaining an understanding of the project environment and the architecture of the system to be developed by the project, including the industry, relevant regulations, and any oversight entities that can influence the project during the execution phase. This part of the analysis provides a view of the external environment and the key entities that require interaction with the project either directly or through the sponsoring organization (see Figure 3.6).

Interface Management Introduction

59

Project Execu on Strategy

Industry Oversight

Interface analysis

System Architecture

Organiza onal Influence

Figure 3.6  Interface analysis influences

In cases in which the project is required to interface with an existing system or another project, this part of the analysis is expanded to include these aspects of the environment because they will influence the project either directly or indirectly. With the entities known, the interface analysis proceeds to identifying specific interface areas; for each interface area, specific interface issues and interface items are defined. In some instances, a contract or agreement may be established between projects that require integration with one another. If this is the case, the agreement or contract can include how the projects will cooperate to ensure successful integration, describing work processes and procedures as well as any requirements and specifications as shown in Figure 3.7. In addition, the interface analysis process examines the project’s planned development, including the strategy for contracting the project, the timing of milestones or key events, critical dependencies between entities, and project phases. It is important to obtain an understanding of how the project will be developed during the execution phase and what the key entrance criteria are for the respective milestones, stage gates, and key events along the project timeline. Equally important is gaining an understanding of other project processes and procedures, such as risk management, quality control and assurance (i.e., audits, verification, and validation), and change management. Interface analysis is discussed in more detail in Chapter 5.

3.2.6.1 ​Interface Management and Other Project Processes

Interface management is not a stand-alone management function. Rather, it must be aligned with, and will interact with, other project processes as conceptually illustrated in Figure 3.8. Thus, it is

60

Project Interface Management

Project Execu on

System Architecture

Organiza on Influences

Interface Groups

Interface Area

Interface Issue

Interface Items

Figure 3.7  Influencers’ impact on interface analysis process flow

Change

Integraon

Risk

Interface Management Scope

Cost

Schedule

Figure 3.8  Interface management relationship to other project processes

Interface Management Introduction

61

important to ensure that these processes account for interface management and vice versa. For example, interfaces can represent risk and should be included as part of the risk management process. Similarly, project changes can cross common boundaries and affect more than a single entity. Thus, interfaces need to be included as part of the project’s change management process. Interface management and its alignment to other project processes will be discussed in more detail later in the book.

3.2.6.2 ​Interface Networks

One critical output of the interface analysis process is the identification and organization of interface networks. Interfaces, and the interaction by various entities to resolve them, occur on several levels of a large-scale complex project. Interface networks are designed to identify and group relevant entities in an organized way that ensures efficient and effective interaction. An interface network is therefore defined as: a group of interface parties established to coordinate interface issues associated with specific types of stakeholders of the project. For example, an interface network may be established for the client’s main contractors to coordinate external interfaces and an internal interface network may be established within the client’s organization to coordinate internal organizational interfaces associated with the project. Within the systems engineering domain, interface networks are referred to as interaction networks in the Systems Engineering Body of Knowledge (SEBoK). However, we have chosen to use the term interface networks for better alignment with the content of this book. In practice, what we call the networks matter little; it is more important to understand the networks’ purpose and function within interface management (see Figure 3.9).

Contractor Network

• Coordinate interfaces between a project’s various contactors Project -to -Project Network

• Coordinate interfaces toward other projects Project Sponsor Network

• Coordinate interfaces between Client’s management teams Figure 3.9  Interface network examples

62

Project Interface Management

3.3 ​INTERFACE CATEGORIES AND TYPES As stated previously, one of the challenges in interface management is to understand what is and is not an interface. A common misconception about interfaces is that they are limited to the engineering department. Unfortunately, this misconception ignores the connection between engineering disciplines and the larger project, the project environment, the organization, and the specific industry environment. Modern large-scale projects are complex, with segmented areas of responsibility and scopes of work that are often complicated by elaborate contract strategies. Accordingly, interface management applies a holistic system view not only within the project, but also outside the project, to the external environment that can influence or affect the project or the system being developed by the project. This section of the book provides a basis for the common understanding of potential interface categories and types. Ultimately, each organization will evaluate which types and categories of interfaces to manage and how they are managed. Understanding these types and categories assists in establishing interface networks and defining the scope of interface activity across the project, as part of the interface analysis process.

3.3.1 ​Interface Categories

This book recognizes four general categories of interfaces: technical, project, organizational, and industry. These interface categories are notionally illustrated in Figure 3.10, which conceptually shows layers of interfaces extending from technical to industry. Technical (also known as system) interfaces represent interaction to deliver the product being developed by the project. These interfaces are directly associated with development of the system to be produced by the project; they reside mainly within the engineering departments. Thus, technical interfaces are shown in Figure 3.10 as existing within the project environment. Extending out from

Industry

Organizaonal

Project

Technical

Figure 3.10  Interface categories

Interface Management Introduction

63

technical interfaces, project interfaces occur within the organizational environment, but also encompass technical interfaces. Project interfaces include technical interfaces, but also include interfaces related to project management activities among the various interface parties. Extending out from the project layer, organizational interfaces are the next layer and encompass the project and technical interfaces. These interfaces typically are associated with free issue or CPIs. However, when integrating with another independent project, they can include organizational issues associated with agreements with other organizations. Organizational interfaces can flow both toward the project and toward the industry as the final layer, which is illustrated in Figure 3.10. Industry interfaces typically are associated with regulations and requirements from industry oversight agencies and bodies, including audits of the project. Every project is conducted within an industry and is subject to industry safety, health, and environmental standards. Industry oversight agencies exist to ensure that project development is consistent with established safety and environmental regulations; to prevent accidental environmental impact and protect workers performing hazardous jobs, among other regulatory considerations. While Figure 3.10 illustrates the various layers of interfaces, every layer may not be addressed within the interface management system. Each organization sponsoring a project will decide at what level to conduct the interface management system and how it relates to other organizational and project processes. However, categorizing interfaces in this way can help support interface analysis and assist in determining how to structure the interface management program for the project.

3.3.1.1 ​Technical Interfaces

Technical, or system, interfaces are normally associated with conceptual design and detailed engineering of the system being produced by the project. The International Council on Systems Engineering (INCOSE) Handbook v3.2.2 identifies technical interfaces as physical, logical, human-system, and energy (INCOSE, 2012)—and further describes them as follows: • • • •

Physical—connection point between hardware systems, subsystems, and components Logical—data signals and signal exchange protocols, etc. Human-System—operator versus operator terminal Energy—electrical power (generating, distributing, transmitting, and consuming)

The SEBoK also defines technical interfaces as matter, energy, or information flows exchanged between the system-of-interest and its external components in the context of its use, including physical interfaces (BKCASE, 2015). Technical interfaces occur across technical disciplines, often with different areas of responsibility, such as electrical, mechanical, piping, structural, safety, and process, among others. Typically, engineering processes address technical interfaces and interdiscipline coordination within a single entity’s scope of work. However, technical interfaces can also result when two different contractors provide interconnected systems for the same project. In the latter case, the technical interface has two or more interface parties.

3.3.1.2 ​Project Interfaces

Project management related interfaces occur across the 10 Project Management Institute (PMI) project management Knowledge Areas (PMI, 2015) and the project’s life cycle or phases, called Process Groups by PMI (2015). A brief description of each PMI Knowledge Area is provided below: • Project Integration Management—coordinates the other project areas to work together, especially to manage the interdependencies among the Knowledge Areas. These interfaces include issues related to free issue items provided to contractors from other contractors, company/cli-

64

Project Interface Management

•

• • •

• •

•

•

•

ent provided items to contractors, deliverables to support milestones, or the stage-gate process, etc. Project Scope Management—used to ensure that the project includes all of the work required and that no new work is added outside the defined scope. Interfaces include resolving overlap, conflicts, or gaps in scopes of work between interface parties. In large-scale complex projects utilizing complicated contract strategies, scope misalignments are common and even likely. Project Schedule Management—includes the processes to manage the schedule and timely completion of the project. Typical interfaces associated with this management area are related to aligning project schedules among various interface parties. Project Cost Management—includes the processes to plan, manage, and control costs in order to complete the project within the approved budget. Project Quality Management—works to ensure that the project meets its requirements or, in other words, does what it is expected to do. It is common for interface parties to request results from acceptance tests and other verification and validation events for products being delivered to them from other contractors. These interfaces can also include documentation of procedures for receiving the item and verifying their condition upon receipt. Project Resource Management—includes the processes used to develop, acquire, manage, and lead the project team. Project Communications Management—includes the processes to effectively communicate the right project information among the right stakeholders (both internal and external) at the right time. This includes how interface progress is reported through respective project management chains. Project Risk Management—includes identifying, managing, and controlling project risk (both positive and negative). It is typical for the project plan to change as a result of rebaselining or unexpected events. Interfaces related to risk are normally associated with timecritical events that require rapid resolution to prevent negative consequences. On the other hand, from the point of view of informed risk management, interfaces represent risks that can be addressed through effective project interface management. Project Procurement Management—includes the processes necessary to acquire the materials and services needed to complete the project, including contract development and administration. Interfaces related to procurement typically include managing the delivery of specified products, services, or information from interface parties’ sub-suppliers and vendors to avoid negative impact on deliveries for another interface party. Project Stakeholder Management—includes the processes used to identify and manage the people and entities impacted by the project and engaging them in project activities and decisions.

Effective interface management reduces the risk inherent in common boundaries with explicit or implicit dependencies; thus, it is directly related to project risk management. During all phases or process groups, addressing these risks involves considerations for all the Knowledge Areas identified by PMI. The project material or information needs between interface parties can extend to all facets of project management: shared risks, alignment of project schedules, quality control methods, inspection routines, use of preferred vendors lists, coordination of critical skills/personnel, etc. Interfaces across these management areas can be related to procurement activities, contract clarifications, safety procedures during installation and commissioning, critical material deliveries between contractors and subcontractors, and risk mitigation strategies across different contractors that have no formal controlling relationship. Effective interface management is unequivocally crucial to effective project scope, schedule, and cost management on large-scale complex projects. We submit that failure to manage interfaces can have a devastating impact on scope, and especially schedule and cost on such projects.

Interface Management Introduction

65

3.3.1.3 ​Organizational Interfaces

Managing a complex project often requires the integration of plans and resources from multiple organizations that may not have a direct contractual relationship. Each such organization likely has its own approach to what INCOSE calls the Organizational Project-Enabling Processes (INCOSE, 2012), which includes: • Life-cycle model management process—this includes the approach to the entire project process • Infrastructure management process for a project—this may include such items as facilities and computer networks and other information technology infrastructure • Project portfolio management process—this includes how project selection decisions are made and resources allocated between the organization’s projects • Human resource management process—this includes how people are managed and how skills are developed • Quality management process—this can include quality control, quality assurance, and verification and validation issues for the various parties on a complex project Organizational interfaces extend from the project and into the client or contractors base organization and functional areas. This means that when entities need to cooperate to address interfaces, their personnel must recognize and understand the differences in organizational processes and may need to consider them in developing the interface solution. As an example, during project execution, it is common to have CPIs provided by the client or contractor. These CPIs need to be delivered by the organization to the project at a specified time and to detailed specifications. Coordination at the organizational level is necessary to align the CPI with the project design and development. Misalignment can create unwanted delays, rework, and added cost. Organizational interfaces also include operations; i.e., the organizational entity that will take control of the project after completion. Operator input during the design and development of the project is critical; ultimately, they are the end users of the system being realized by the project. For projects delivering elements that integrate with an existing system or another project, organizational interfaces may involve obtaining agreement on integration requirements and specification, timelines, allocations, etc. To manage an organizational interface, it is necessary to address what each party will do to collaborate in terms of internal business processes at their respective organizational boundaries. For example, for projects integrating with other projects with different clients, the organizational interfaces might be addressed by a cooperative agreement between the two parties (projects) that establish guidance and integration requirements, administrative policies, and management practices.

3.3.1.4 ​Industry Interfaces

The final category of interfaces is industry interfaces. Nearly every project is developed within a specific industry, which is guided by industry standards and regulations and under the oversight of government agencies. In large-scale complex projects, involvement with industry regulators is expected to ensure the project is adhering to regulatory requirements. For example, in the oil and gas industry, a plan for development and operations must be submitted to authorities for review and approval prior to project execution. During project execution, it is not uncommon to seek clarification of industry standards and regulations. Large-scale projects integrating with existing government facilities, such as rail network or oil process facilities, must interface effectively with government counterparts.

66

Project Interface Management

These categories of interfaces help illustrate how interface management applies in a project from lower levels in technical disciplines, such as engineering, up through higher oversight levels, such as senior executives or industry oversight agencies. Interface management identifies the layers of interfaces, devises a structure to organize the interactions, and reduces the complexity of interactions among independent entities on a project. This helps to ensure that clear interface requirements are transmitted from the party that has the requirement to the party that needs to fulfill it. In addition to the categories, interfaces can be described by type, as discussed in the next section.

3.3.2 ​Interface Types—Internal and External

We recognize two types of interfaces—internal and external. An internal interface is defined in this book as: an interface occurring within an interface party’s scope of work or area of responsibility, within the same project for the same client contract, including any derived subcontracts. An external interface is defined to be: an interface requiring coordination along common boundaries between two independent entities (interface parties) with no controlling, contractual, or organizational relationship.

3.3.2.1 ​Internal Interfaces

Whether an interface is identified as internal or external depends upon what is used to discriminate between these two types, in other words, how the client or the higher-level contractor defines what is internal and what is external. Contracts are a common method of defining the boundary between internal and external interfaces. In the example in Figure 3.11, Contractor A is the main contractor. Contractor A’s scope of work establishes which interfaces are under the contractor’s control (internal interfaces), and which are outside its control (external interfaces). As shown, the main contractor is using two subcontractors to execute the contract. From the main contractor’s (Contractor A’s) perspective, any and all interfaces occurring within Contractor A’s contract will be managed as internal interfaces. This includes any interfaces that may exist between the two subcontractors shown in Figure 3.11. In some cases, contractual or cooperative agreements are reached between subcontractors as is indicated by the arrow between the two subcontractors. This is often the case when subcontractors

Contractor A

Subcontractor 1

Subcontractor 2

CONTRACTOR INTERNAL Figure 3.11  Contractor internal interfaces

Interface Management Introduction

67

have a history of working together and whose specialized products are reliant upon the other. Thus they have an interest in working closely together to ensure their two products align as they have done on previous projects. While the previous example used the main contractor’s contract to differentiate internal from external interfaces, there are many other ways to establish the boundary between the two interface types. For example, the client may establish internal interfaces among its management teams who are managing various subprojects or between various functional departments in its organization that are supporting the project, such as safety and environment. In this case, the client has designated its organization or entity as the boundary establishing which are internal and which are external interfaces. So, in such a case, interfaces between the organization’s functional departments are defined as internal.

3.3.2.2 ​External Interfaces

External interfaces occur between two (or more) parties that do not have a controlling relationship. Because there is no controlling relationship, these interfaces typically represent the highest risk to a project. This is illustrated through the relationships shown in Figure 3.12. In Figure 3.12, the client has contracted with two separate contractors (A and B). The contractors have established their own organizations to complete their respective work. These two main contractors (A and B) do not have a contractual relationship with one another, but they must nonetheless cooperate and communicate in order to deliver their respective portions of the project. The interfaces between Contractor A and Contractor B are defined as external interfaces. Also shown in Figure 3.12, each main contractor (A and B) has control over their internal interfaces through a contractual relationship with their subcontractors. This contractual relationship makes it easier to dictate the processes, procedures, and tools to be used to manage interfaces, which of course is more difficult when managing external interfaces.

CLIENT

Contractor A

Subcontractor A1

Contractor B

CONTRACTOR EXTERNAL

Subcontractor A2

CONTRACTOR INTERNAL

Figure 3.12  Contractor external interfaces

Sub contractor B1

Subcontractor B2

CONTRACTOR INTERNAL

68

Project Interface Management

3.4 ​SUMMARY In this chapter, basic interface definitions, terminology, and concepts have been presented to provide a consistent foundation for the remainder of the book. As a relatively new management function, interface management acts to align project management with SE, and with the project’s external influencers, to reduce risk. It provides a structured, transparent, and logical process to identify and organize interfaces within complex projects, including external entities that influence the project. Complex interactions can be identified, organized, and resolved methodically to prevent unwanted or unintended negative consequences to scope (including quality), schedule, and cost during project integration. Obtaining a consistent understanding of interface management enables diverse organizations and teams to identify and manage all of the interfaces across the project internally and externally. Although all interfaces must be properly identified and managed, the majority are generated during project planning and early execution. This is an ideal opportunity to recognize the interfaces to be managed, and to define their scope and resolution plans. Interfaces that are not properly managed can introduce safety, cost, and schedule risk. Failure to do so can and does create negative outcomes for the project later during the life cycle. It is significantly easier to influence the project’s outcome when interface issues are identified early in the project. With this chapter providing an introduction to the concepts and terminology of interface management, the next chapter focuses on the basic interface management process. An inherent challenge for major capital projects is determining the scope of interfaces and how to best manage them in order to provide positive outcomes and prevent negative consequences. Chapter 4 describes the process for identifying, organizing, and resolving interfaces both within the project and with external entities that influence the project.

3.5 ​REFERENCES BKCASE Editorial Board (2015). The Guide to the Systems Engineering Body of Knowledge (SEBoK), v. 1.4. R.D. Adcock (EIC). Hoboken, NJ: The Trustees of the Stevens Institute of Technology. Retrieved August 8, 2014 from www.sebokwiki.org. Caglar, J. and M. Connolly. (2007). Interface Management—Effective information exchange through improved communication. ABB, Inc. Value Paper Series, Houston, TX. Flyvbjerg, B. (2007). “Truth and Lies About Megaprojects.” Inaugural Speech, Faculty of Technology, Policy, and Management, Delft University of Technology, September 2007. Healey, P. (1997). Project Management: Getting the Job Done on Time and in Budget, ISBN: 0750689439, Butterworth-Heinemann, Woburn, MA. 01801-2041. INCOSE (2012). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2. Nooteboom, U. (2004). “Interface management improves on-time, on-budget delivery of megaprojects,” JPT Online, The Society of Petroleum Engineers, August, 2004. p. 32–34. Retrieved June 7, 2014 from http:// www.intecsea.com/publications/technical-publications/267-interface-management-improves-on-time -on-budget-delivery-of-megaprojects. Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 6th Edition. Project Management Institute, Newtown Square, PA. Wideman, R. M. (2002). Wideman Comparative Glossary of Project Management Terms, v3.1. Retrieved June 2, 2014 from http://maxwideman.com/pmglossary/PMG_I03.htm. Wren, Daniel A. (1967). “Interface and interorganizational coordination.” Academy of Management, Journal 10, no. 1: 69–81.

4

Basic Interface Management Process “The unlike is joined together, and from differences results the most beautiful harmony.” —Heraclitus

Management is the planning, organizing, leading, and controlling of human and other resources to achieve organizational goals efficiently and effectively (Jones and George, 2014); these are often identified as some of the functions of management. Applying management functions to projects helps to structure and simplify complexity. By establishing management processes in the project, the organization is setting the foundation to drive the actions of people, communicate expectations of desired outcomes, build a framework to monitor and control activities, and provide order and structure. Similar to other management functions, project management processes are an important aspect of planning, organizing, monitoring, controlling performance, and ensuring completeness during project execution. Project interface management is one of many project and systems engineering (SE) management functions within large-scale projects. Interface management focuses on simplifying complex interface interactions resulting from complicated project development strategies and complexity in designing and developing the system resulting from the project. Like other management functions, interface management provides a holistic framework to include people, processes, procedures, tools, and techniques. Equally important, interface management considers the project environment and how project development occurs over time. Against this backdrop, the project team can begin to understand the breadth and depth of interfaces needed to deliver the project, and can begin to plan and emplace the appropriate management system to ensure effective and efficient interface activity and interaction. As expected, interface management shares many similarities with other management functions and includes a heavy reliance on a basic process, which consists of a number of steps and activities to help guide the actions of those within, or associated with, the project interfaces. In this chapter, we focus on the basic interface management process model and the actions essential to completing the steps and activities in the process. The basic interface management process is presented conceptually in Figure 4.1. Rather than prescribing strict adherence to this model, we use the model to describe the process as a general guideline. As with any other management process models, the process illustrated in Figure 4.1 can and should be tailored and applied by the project team to the unique circumstances and environment of each project. Further, the application of each step and activity in the process, or the need for additional steps, is at the discretion of each project team.

69

70

Project Interface Management

Determine Interface Networks

Identify Interface Parties

Identify Interface Areas

Define Interface Issues

Document Interface Items

Monitor & Control Activities

Close Out Items & Issues

Figure 4.1  Basic Interface Management Process Model

The seven basic steps in the process model in Figure 4.1 include: • • • • • • •

Determine Interface Networks Identify Interface Parties Identify Interface Areas Define Interface Issues Identify, Plan, and Document Monitor and Control Activities Resolve and Close Out Interface Items and Issues

One may view this process as strictly linear—where one step follows the other. However, this is not the case. There is considerable overlap and iteration between the steps and within the process. Further, given the many different interface networks, interface groups, and intensity of interface activity within a large-scale complex project, the process is nearly always at different stages for different actors (i.e., entities affected by the process). The process is presented in a simple linear manner in this chapter to illustrate the flow of activities associated with managing interfaces. This helps those unfamiliar with interface management to gain a better understanding of the flow of activities across the spectrum of the process. As with any management process, the interface management process is part of a larger interface management system or program, including the people, tools, techniques, and procedures needed to perform the process. In essence, the interface management process acts as the nerve center for the project’s interface management system and provides the structure to guide the project’s interface personnel and others involved in managing interfaces in the performance of their roles and responsibilities. As stated, the process is not a series of isolated stovepipe activities, but is aligned to and integrated with the use of an interface management tool to help manage the volumes of data and information that flow within—into and out of the process. Inherent in the process is the use of analysis and management techniques that support identification of project interfaces, and ensure that interfaces are logically structured and are managed in alignment with the other parts of the interface management system. Thus, the process is essential in order to align the various pieces of the project and to help maintain interface management effectiveness and efficiency. That is, the process drives the simplification and control of complex interactions between entities such that each entity receives the right information or material at the right rime to prevent unwanted schedule delays or costly scope misalignments. In addition, this process is not stand-alone; it is connected to other project management processes, which will be discussed later in the book.

Basic Interface Management Process

71

Subprocesses established within each step help to better define how activities are performed to complete the step. For example, the Monitor and Control Activities process step is usually specified in the project’s interface management procedure or philosophy, which is distributed via contracts to contractors and to the sponsoring organization’s project team. In this book, we provide an overview of the process with examples. However, as with any process, there are myriad possibilities when implementing a management process and the project team for each individual project must consider the best way given their existing project management system, organizational culture, and the specific circumstances of the project under development.

4.1 ​INTERFACE PROCESS—PROJECT PHASES The timing for completing the activities within the interface management process is graphically depicted in Figure 4.2 along the project phases. This illustration is not intended to be exact, but rather activity completion is approximated and subject to the circumstances of each project. The step Determining Interface Networks generally occurs during project initiation or very early in the planning phase. At this point, sufficient information should exist to begin crafting the various interface networks. Depending on the project approach, iteration may be required during the project life cycle to update interface networks, especially if the project management plan or approach changes significantly. This step is typically performed by the client’s project team, but is also applicable to the main contractors’ teams after contract award if it is determined that the scope of work requires the management of multiple interface networks. Performing this step is also necessary when integrating with another project or into an existing system. The steps Identify Interface Parties, Identify Interface Areas, and Determine Interface Issues are shown from the project’s initiation phase and well into the planning phase. Again, the client’s project team performs this step initially to help gather information to set up the project’s interface management system and begin to form the basis for what information needs sharing between the respective interface groups within each interface network. Once the client begins to award contracts for the various scopes of work or establishes cooperation agreements with other projects and existing systems, interface groups are initiated and begin collaborating to identify and plan their respective interface

Determine Interface Networks

Resolve & Close Out Interface Issues & Items

Identify Interface Parties Identify Interface Areas Determine Interface Issues

INITIATING

PLANNING

Monitor & Control Activities

Identify, Plan, & Document Interface Items

EXECUTING

Figure 4.2  Basic Interface Management Process—Project Phases

MONITOR & CONTROL

CLOSING

72

Project Interface Management

items. It may be necessary to iterate back to the Identify Interface Parties, Identify Interface Areas, and Determine Interface Issues if the scope of work has changed prior to contract award. Regardless, it is good practice to allow each interface group to iterate through these steps after initiating the group to make sure no interfaces were accidentally omitted during initial completion of these steps. After initiating the interface group, each group will work to identify specific interface items associated with each interface issue that needs to be resolved to ensure their scopes of work and their areas of responsibility and deliverables align. Each interface item is planned in accordance with the project schedules of each interface party. If this step in the process is performed correctly, and the project schedules are accurate and reliable, then this is the time where interface clashes are identified. A clash means that one party requires resolution of an interface, but the other party is unable to meet the required timeline. As an example, out-of-sequence engineering can result in numerous technical interface clashes. The Monitor and Control Activities step is an activity performed by all parties in the interface management system; although the client, as the benefactor, is the main party of concern. Clearly, it is in the client’s best interest, and the project’s, to ensure interface management activity is progressing as planned between all parties. This step requires the establishment of interface management key performance indicators (KPIs), which are measures of performance (Bible and Bivins, 2011), and collection of data and information to evaluate how the interface management system is performing during project execution. As with nearly every management function, reporting progress is a standard part of the project reporting process. Information and results from this step of interface management will flow into the project’s reporting process. This step also includes interface verifications and audits to ensure management procedures are implemented as required and interface agreements are implemented as agreed by the interface parties. We will discuss this step in much more detail later in the book. Finally, the Resolve and Close Out Interface Issues and Items steps are performed throughout most of the project execution phase and into the project’s closing phase. During project execution, regular interface activity normally results in reaching agreement on how to resolve individual interface items, which are then implemented by the responsible interface parties, and then the interface item is closed. Ultimately, resolution of all interface items will result in corresponding interface issues being closed, which eventually leads to all interface areas being closed. This step interacts with the Monitor and Control Activities interface process step in that as interface issues and areas are closed, it may be necessary to conduct interface verification, audits, or design reviews to confirm that all interface agreements have been implemented by the respective parties.

4.1.1 ​Top-Down Analysis—Bottom-Up Synthesis

It should be clear from Figure 4.2 that the interface management process requires analysis during the project planning phase and synthesis during the project execution phase. Analysis is the means of separating any material or abstract entity into its composite elements, which is the opposite of synthesis, which involves putting together or combining parts into a whole (Forman and Selly, 2001). Analysis serves a crucial role during planning because it simplifies complexity by using a structured and logical approach. Similarly, synthesis provides the framework to ensure traceability of interface activity and full resolution of interfaces between parties. The interface management process is top-down decomposition requiring interface analysis (described in detail in Chapter 6) during the project planning phase and bottom-up synthesis during the execution phase. More specifically, the analysis process starts at a high level from Determine Interface Networks and works toward a more detailed view as the process progresses toward Identify Interface Items. This provides a framework to segment complex relationships and required interactions into manageable pieces so that they can be logically analyzed while reducing

Basic Interface Management Process

73

the chances of omitting interfaces. As all interface items are identified, we begin to move up the process model (i.e., bottom-up) to synthesize the results starting at the interface items level and working toward final resolution and closeout of all interface areas.

4.2 ​DETERMINE INTERFACE NETWORKS Recall from Chapter 3, an interface network is a group of interface parties established to coordinate interface issues associated with specific stakeholders of the project. These interface networks are logical groupings of related project entities that need to interact with each other in order to resolve interface issues relevant to their group. According to the International Council on Systems Engineering (INCOSE, 2011), system architecture is a selection of the types of system elements, their characteristics, and their arrangement; also sometimes expressed as system components and their relationships. Interface networks are derived from the system architecture developed for the project and the development environment of the project. Both the architecture and the environment influence the composition of interface networks, which can include external elements that can influence the project, such as oversight agencies, other projects, and existing systems with which the project must integrate.

4.2.1 ​Interface Network Overview

Interface networks are analogous to communication interaction networks (CINs) (Wang et al., 2012). A CIN is essentially a graphical representation of who talks to whom among a group of individuals. In the case of interface networks, the who or whom are entities or groups rather than individual people. However, just as important as who talks to whom is what information these parties need to convey to one another and when. In everyday terminology, one can think of our individual social and professional networks as an example of interface networks; however, interface networks represent entities or groups and not individual people. For example, an individual may use a social network site to communicate and interact with family and friends, and a professional networking internet site (such as LinkedIn) to communicate and interact with professional colleagues. These networks provide a way for people to structure networks so that they can control, either intentionally or subconsciously, the types of information shared with the parties within each network. In addition, the means to communicate may vary. For instance, the family network may choose to use a phone system while interaction with professional colleagues may use an internet site such as LinkedIn. Our family members are generally organized into one interface network, friends into a second interface network, and our colleagues at work as a third. Each of these networks serves to organize the type of interaction we have with its constituent members (i.e., interface parties) within each network. Within the family interface network, private or sensitive family matters are communicated among individuals as part of personal interactions. Different relevant information is communicated within networks associated with friends and within networks associated with work. Specifically, the interactions focus on information that is appropriate within the network. If we examine our family and work interface networks (a.k.a. interaction networks) closely, we find it is not usually necessary for those in our work network to interact with those in our family network, except in unusual circumstances, such as a medical emergency or annual social gathering. Rather, these networks are normally separated and logically organized by the types of interface activity occurring within these groups and the type of information that needs to be shared among its members. The point is that we naturally organize our interactions with others into groupings because it helps to establish boundaries for the types of interactions we have with the individuals within those networks. The same is true for the various entities involved in large-scale complex projects. The difference is that members of project interface networks are entities (e.g., companies or other projects) rather

74

Project Interface Management

than individuals. In project interface networks, individuals communicate and interact on behalf of entities. Interface networks on large-scale capital projects typically include the client’s prime contractor network (for interactions between the client and prime contractors) and the client’s internal interface network (for interactions within the client’s internal structure). However, the project may include many more interface networks depending upon the system architecture, the project’s development environment, and operational conditions after transitioning the system to its owner. Projects that require integration into a national infrastructure, such as rail or oil and gas transfer, may include civilian and government interface networks. The central role these interface networks play is to organize different independent parties or entities into logical groupings for interaction purposes. That is, interface networks are related to specific aspects of the project under development and/or the system produced by the project. It is reasonable to say these interface networks are simply groups of related stakeholders.

4.2.2 ​Interface Network Examples

The number and type of interface networks utilized is dependent upon a number of factors including the project development strategy, the system produced by the project, the environment in which the project is developed, and the operating environment in which the system is fielded, installed, or transitioned. Later in the book, we discuss analysis techniques and tools to identify and organize interface networks. Some examples of interface networks include: • • • • • • •

Client’s prime contractor (CPC) Client internal project (CIP) Project-to-project (P2P) Project-to-existing system (P2ES) Project sponsor-to-industry (PSI) Organization-to-organization (O2O) Contractor Internal (CI) or Prime Contractor Internal (PCI)

4.2.2.1 ​Client’s Prime Contractor Interface Network

The CPC interface network provides a communication interaction network for the client and one or more main contractors contributing to the same project that have no contractual relationships. Main contractors have a contract directly with the client and thus the controlling relationship is toward the client and not toward other main contractors or their teams. This type of network allows the various contractors to interact on interface issues related to their respective scopes of work. More precisely, it allows these contractors to interact on issues that cross their common boundaries, which are established by their scopes of work. This network can also include any client entity, which is supplying free issue items or company provided items (CPIs) to interface parties within the network. These items typically require interface alignment on technical specifications and management requirements, such as related project constraints of time, cost, and scope.

4.2.2.2 ​Client Internal Project Interface Network

A routine practice on large-scale complex capital projects is to subdivide the project into different parts or subprojects, which reduces organizational and communication complexity, and, for many entities, can leverage a greater variety of products and services across a global marketplace. In practice, this approach often results in several main contractors or contractor teams contributing to the

Basic Interface Management Process

75

project, such as described in the CPC interface network previously mentioned. In doing so, the client establishes subproject teams, each of which represents the client for a main contractor or main contractor team. It is normal for these teams within the client entity to interact with each other in order to implement changes that extend across scope boundaries for their contractors, provide input to technical queries from main contractors or government oversight agencies, and establish common interface risk responses to uncertainties extending across scope boundaries. In addition, the sponsoring organization may be providing substantial CPIs to the various subproject teams. In these situations, the client’s internal organization can establish an internal interface network to identify entities within the organization and project that need to interact to coordinate and agree on interface issues across the sponsoring organization’s subproject teams, such as technical queries, approved changes, etc.

4.2.2.3 ​Project-to-Project Interface Network

In a P2P network, one project under development is integrated to or with another project under development. These projects can be part of the same organization or belong to a completely different organization or even to a competitor. This type of network provides a direct P2P communication channel to formally interact and coordinate related interface issues between independent projects that are required to integrate with each other. This is fairly common in the American defense industry where several military system projects are under development at the same time, but are required to operate as a family of systems when fielded. This form of interface network is also common in the oil and gas industry where offshore project tie-ins are standard practice to minimize the offshore footprint and maximize the effectiveness of existing field architectures.

4.2.2.4 ​Project-to-Existing System Interface Network

Many large-scale capital projects are required to integrate into existing systems, such as a new oil or gas pipeline into an existing processing facility, a new rail line into an existing railway infrastructure, or a new airplane model into the existing aerospace infrastructure. In these cases, it may be necessary to establish a P2ES interface network for interface parties between the existing system and the project. The basis of this network is the activity necessary to integrate the project into the existing system or infrastructure.

4.2.2.5 ​Project Sponsor-to-Industry Interface Network

In some situations, the project’s sponsoring organization may need to establish an interface network with industry agencies, such as safety and environmental bodies. Either the client or members from the project team on behalf of the client can fill the role of project sponsor. Such an interface network may be needed where large-scale projects are conducted close to sensitive wildlife areas and require environmental monitoring, or involve adherence to strict safety protocols during development. Such networks can be useful where projects extend across significant distances and involve many local communities and state governments and interest groups.

4.2.2.6 ​Organization-to-Organization Interface Network

In some cases, competing organizations or businesses sponsor separate projects, but these projects require collaboration, cross-contribution, or other joint cooperation between the projects. Such arrangements are typically governed by an agreement between the two organizations and result in various specifications and requirements, in addition to commercial terms, to be met by the respective

76

Project Interface Management

project organizations when the systems are fielded to operations. Such an arrangement also requires the two organizations to establish common processes, procedures, tools, etc., for the development of their respective projects. If these projects are operated in unison or together to create value for the respective companies, then this interface management network is useful to coordinate common operating procedures and joint response procedures for emergency situations.

4.2.2.7 ​Prime Contractor Internal Interface Network

In some situations, the prime contractor’s scope of work or teaming arrangement may force the establishment of a Prime Contractor Internal (PCI) interface network. It is common for major companies to agree to a teaming arrangement by which a number of companies divide the scope of work for their related specializations. For example, one company may be responsible for engineering, another company in the team for procurement, and still a third company for fabrication and construction. In such an arrangement, especially when there is no prior teaming experience between the contractors, an internal interface network can help to synchronize interfaces among the various entities. This is especially true when the contractors’ management systems are different. This type of network is also useful when the scope of work is expansive or exceedingly complex, which requires the dispersion of work to be carried out by different divisions of the same company at different geographic locations. For example, a main contractor awarded a contract for engineering decides to subcontract part of the work to an engineering company, which then decides to disperse the engineering scope to several locations and departments within their company. A similar case could be true for construction activities where the scope is being conducted at several locations and then assembled, i.e., integrated, at another site.

4.2.3 ​Output of Interface Network Analysis

The output of this process activity is the identification of the total number and types of interface networks. As stated previously, each project environment and each sponsoring organization is different. Therefore, after identifying project interface networks, the project team needs to ascertain the appropriate process to manage each network. For example, an organization may elect to manage an O2O interface network through the company’s legal department or the P2P interface network through the project management office (PMO), while the remainder of the networks are managed through the project’s interface management system. Regardless, all interface networks affecting the project need to be accounted for within a management system, either the sponsoring organization’s (such as a project or portfolio management office) or the project’s interface management system. Later in the book, we will discuss how the interface networks, managed under the project’s interface management processes, are used as the basis for setting up the project’s interface management system and preparing for the implementation of that system prior to the start of the project execution phase. Identifying and managing interface networks in the interface management system rather than as part of other organizational processes or management systems forms the foundation for the scope of interface management for the project. This distinction means that the interface networks assigned for management in the project’s interface management system are the basis of responsibility for the client’s project interface manager. Placing interface networks under other organizational processes means that responsibility for these networks is outside the scope of the project’s interface manager unless otherwise specified by the project manager or project director. As is the case in all roles, it is important to be clear about what is and is not within the responsibility of the project’s interface management system in order to prevent confusion, overlap, or duplication of effort.

Basic Interface Management Process

77

4.2.4 ​Common Pitfalls

A common mistake is putting all interface parties into one interface network. On the surface, it may appear to be easier and simpler to establish one network with all interface parties, but in reality, this approach often creates a number of problems including: increased difficulty in verification and auditing, confusion in monitoring and control, uncertainty over roles and responsibilities, and failure to reduce complexity.

4.2.4.1 ​Diff iculty in Verif ication and Auditing

It is much more difficult to audit and conduct verifications. Each network represents an aspect of the project and the system developed by the project. When placing all interface parties into a single interface network, it is much more difficult to identify which aspects of the interface management system are performing poorly. It is much easier to audit the network and conduct verifications on the areas between the respective interface groups when separate interface networks are specified.

4.2.4.2 ​Monitoring and Controlling Confusion

In large-scale complex capital projects, the number of interface groups can be extensive (often up to 50 interface parties). When these groups are located within the same network, it can create confusion as to which parties should be assigned to interface groups, missing interface issues, and difficulty in identifying specific sources of interface breakdowns. By defining the interface network as the first activity during interface planning, the aspect of the interface network span of interaction can be better defined, monitored, and controlled.

4.2.4.3 ​Failure to Reduce Complexity

Finally, one of the primary objectives of interface management is to simplify interaction complexity by logically organizing complicated interactions into management segments. Interface networks are a key tool in meeting this objective because they segment interface parties by related area. Mixing unrelated groups increases the chances of miscommunication or interaction interference and detracts from the effectiveness of interface analysis during the planning phase at least in part because it delays the down-plan decisions on interface parties until after sorting out which entities should be involved, one of the main purposes of interface network analysis.

4.3 ​IDENTIFY INTERFACE PARTIES The purpose of identifying interface parties is to ascertain which parties within an interface network need to interface and establish important interface roles between the relevant interface groups. This activity also includes the steps to designating interface groups and establishing the lead interface party (LIP) and interface party relationships for each interface group.

4.3.1 ​Analyze Interface Networks

Each interface network must have at least two interface parties and normally contains several (20 or more). The reason for the minimum is obvious since there would be no need to establish a network for a single entity. Once the interface network is determined, interface analysis aids in identifying all parties within the network that potentially need to interface. At this point, the purpose is to understand the role each party in each interface network plays. This activity is normally performed by the project sponsor’s organization during the early part of the planning phase. More specifically, the

78

Project Interface Management

project’s interface manager or someone on the project team performs this responsibility during early project planning. With a total list of network parties, each party is reviewed to ascertain whether they share any common boundary or boundaries with another party or parties in the network. In cases where the number of parties is high, approximately 20 or more, the initial intention is to eliminate parties that clearly do not need to interface in order to reduce the total amount to a more manageable number. In many cases, it will be very easy to ascertain which entities share a boundary. For example, two parties sharing a physical connection point, or physical interfaces, are normally easy to identify. In other cases, the shared boundary will be more difficult to determine and will require more in-depth analysis, such as those with logical (i.e., signals or software) interfaces. The output of this activity is a preliminary list of interface parties based on interface boundaries determined by scopes of work or responsibility.

4.3.2 ​Designate Interface Groups

With a complete list of interface parties within each interface network, the needs of each interface party are evaluated against all other parties to determine which interface parties need to interface with other parties within each interface network. To be assigned as an interface party in an interface group, it is only necessary to share a boundary with another party, however trivial and minor. In fact, the intensity of interfaces will vary from interface group to interface group and align directly to the scope of work and the system developed or products or services provided by the respective parties. A preliminary interface party matrix (i.e., high-level responsibility matrix) is developed to identify all the interface parties that must interface with each other. This analysis also forms the basis for identifying which parties do not need to interface and confirming there are no shared boundaries or interface points. An important aspect of this analysis is that consideration needs to be given throughout the life of the project, not just a specific time period, such as during the engineering phase. Interface management applies from early project planning and conceptual design through the transition of the project to the project sponsor (i.e., operator, sponsoring organization, etc.). In practical terms, this means that some interface groups will activate early in the project life while others may lie dormant until later in the project life. Regardless, it is important to identify all interface groups early in the project and update as needed. For example, updates may be necessary when the contract strategy changes, the project enters or exits a stage gate, or after a formal systems engineering design review where it may be discovered that new interface parties are needed. As will be discussed later, the timing for initiating each group needs to be considered during interface management planning.

4.3.2.1 ​Interface Group Analysis

When establishing interface groups, it is necessary to understand how important one party is to the other. The project execution plan, often called the project management plan, will provide an overview of how the project is executed by describing the project phases and execution model to be followed, including decision gates. This plan is an important source for helping to establish LIPs within interface groups. The decision gates in the plan are important for establishing project phase boundaries and identifying which entities will be involved at which stages of the project. This helps to understand how roles and responsibilities migrate over the life of the project. In turn, these roles and responsibilities translate to increased or changing importance of certain areas of the project at different points in the project life. This analysis helps to determine if and when to transition an interface party to the lead interface role of the LIP.

Basic Interface Management Process

79

In addition, the architecture of the system delivered as a result of the project is another source to help establish interface parties. The system is the realization of the project such as a new aircraft, power plant, offshore oil facility, etc. The system architecture identifies the major subsystems and components and indicates how the system is to be designed, developed, and integrated. By studying the system’s technical architecture, which elements represent more critical aspects of the design can be inferred. A third important source for identifying the interface parties is the project’s contract strategy. There are many approaches for contracting on a project; for example, using a single main contractor to perform all the work or using multiple main (prime) contractors with numerous subcontractors, suppliers, and vendors. The contract strategy will also include planned time frames for awarding and executing contracts. Often, contracts are awarded at different times during project execution to maximize efficiency and coincide with availability of resources. Once contracts are awarded to specific main contractors, interface parties can be named and interface groups formed and initiated, which will be discussed later in the book. Depending upon the project’s operational concept, when the project under development is integrated with another project or into an existing system or facility, it may be necessary to review cooperation agreements with the other projects and requirements documents from existing systems. These agreements, or contracts between projects, are a means to establish tie-in specifications, management arrangements, commercial terms, and organizational responsibilities relative to the cooperation.

4.3.2.2 ​Def ine Shared Boundaries

Defining shared boundaries is a step that both the client and contractors perform. While it is common for the client to list the general boundaries as part of a responsibilities matrix or similar document as part of the contract, the common boundaries (or battery limits) are often at a high level. After a contract is awarded and interface parties are identified, the respective interface groups will perform further analysis of their respective scopes of work to refine the common boundaries. The common boundaries serve as a starting point for further top-down decomposition to interface areas, issues, and items.

4.3.3 ​Establish Lead Interface Party and Interface Party Relationships

The final step in identifying interface parties is to establish which party will be designated as the LIP, and which party will be the interface party. The LIP is the interface party that is assigned as the one responsible for an interface group by the owner of the project’s interface management system. The LIP is responsible for managing interface activity with an interface group. Each interface group is assigned an LIP. A standard practice is for the client or owner of the project’s interface management function to assign the LIP to the interface party with the most critical need in the group or the party with system integrity responsibility. Thus the LIP typically represents the interface party who has the most urgent or important requirements in the relationship or represents the most important package, component, subsystem, or system contributing to the project. The output of this process activity is an interface group matrix identifying each interface group. The LIP and interface party relationship is illustrated in Figure 4.3. Figure 4.3 illustrates a generic offshore oil and gas project. The figure shows that the project is subdivided into several sections, which are later contracted to different companies. At this point, the respective contractors for each segment of work is not known, or at least they should not be known

X

X

X

X

X

Transport & Installation EPC Contractor

Hook-Up Contractor

Drilling Jack-up rig Contractor (services)

Flotel Contractor

Warranty Surveyor

X

X

X

X

X

X

Jacket EPC Contractor

Living Quarter EPC Contractor

Figure 4.3  Interface group matrix (oil and gas project example)

X

X

X

Topside EPC Contractor

SURF EPCI Contractor

Jacket EPC Contractor

Living Quarter EPC Contractor

Topside EPC Contractor

Contractor Principle Interface Groups

X

X

X

SURF EPCI Contractor (Hanz)

X

X

X

Transport & Installation EPC Contractor

X

Hook-Up Contractor

X

X

Drilling Jack-up rig Contractor (services)

X

Flotel Contractor

X

X

X

X

x

Warranty Surveyor

80 Project Interface Management

Basic Interface Management Process

81

when this activity is being performed. If the project has already awarded contracts for the various scopes of work, then the project is well behind in planning for interface management. Developing this interface group matrix should be completed before the first contract is awarded. Remember, the analysis thus far only correlates to the project environment and system architecture, but identification of this structure helps to set up the interface management system in preparation for the initial contracts and the start of the project execution phase. In the illustration, we observe several interface parties. A brief description of each party is provided for readers who are unfamiliar with the oil and gas industry. This is meant only as an example and is applicable to any industry. • Topside EPC—This interface party’s scope of work requires the contractor to engineer, procure, and construct (EPC) the topside facility. A topside facility is the part of the offshore platform where hydrocarbons are produced and processed. • Living quarters (LQ) EPC—The scope of work for the LQ requires the contractor to EPC the facility’s living quarters. The living quarters can be thought of as an offshore hotel on the platform. It accommodates offshore personnel and provides a platform monitor and control functional facility. • Jacket EPC—The scope of work for the jacket requires the contractor to EPC the jacket structure to support the offshore platform. The jacket is the steel structure supporting the offshore platform. • SURF EPCI—The scope of work for subsurface umbilical (electrical, signal, and fluid cable bundles) risers and flowlines (SURF) requires the contractor to engineer, procure, construct, transport and install (EPCI) all subsurface components that allow the offshore platform to transport hydrocarbons from the facility to a transport carrier or pipeline. • Transportation and Installation (T&I) EPC—The scope of work for T&I requires the contractor to EPC the systems necessary to T&I topside and living quarters from their construction site to the offshore field. • Hook-up—The scope of work for the hook-up contractor is to engineer, procure, and fabricate all hook-up items necessary to physically connect the topside, jacket, and LQ after installation. Hook-up activities result in mechanical completion in most cases, which acts as an entry to start the commissioning process. • Drilling and wells (D&W) jack-up rig (JUR)—The D&W JUR scope of work requires the contractor to drill and complete a specific number of offshore wells. • Flotel—The scope of work for the flotel is to provide temporary accommodation for personnel offshore during mechanical completion (i.e., physical connection of the facility) and commissioning (i.e. the validation that the system is ready to be transitioned to operations). The flotel is analogous to a floating hotel that provides accommodations for offshore personnel. As shown in Figure 4.3, all interface parties are assigned within at least one interface group. Further, one of the interface parties within the interface group has been designated as the LIP, as shown by the gray top row where several interface parties have been designated as the LIP. Most important, the interface group matrix shows every group with an LIP and an interface party. In this example, contractors shown in the top row are LIPs against any party in which they have an X in the corresponding column. For example, Topside EPC is LIP against seven interface parties, as shown in the Topside EPC row. In essence, the project sponsor, or owner of the interface management process has designated Topside EPC to be the most important interface party within this interface network. Priority is given to the LIP role by working from left to right in the top row. This means that Topside EPC is the main priority, then for any group in which topside EPC is not a member, this LIP designation has then been assigned to Living Quarters.

82

Project Interface Management

This process is repeated for every interface network, which results in an interface group matrix for each interface network. As will be demonstrated later, the interface group matrix serves as the basis for setting up the interface management software tool, which the interface groups will use to conduct interface activity.

4.3.3.1 ​General LIP Role and Responsibility

The operative word in the LIP title is lead. This word does not imply a master/servant relationship. Rather, it denotes additional responsibility given to one party over the other by the owner of the interface management process to ensure interface activity is initiated and sustained, and that progress is made in resolving interface areas between the groups. Some of the responsibilities entrusted to the LIP are: • Prepare a schedule for interface group kickoff meetings with interface contractors • Plan and schedule regular interface working group meetings with other interface contractors to include preparing meeting agendas, recording meeting minutes, hosting meetings, etc. • Develop and maintain the interface management database (i.e., interface register) in cooperation with respective interfacing parties • Ensure that all interfaces are satisfactorily planned and closed out within a time scale that will not jeopardize the project schedule • Develop action plans consisting of required activities, decisions, timelines, and personnel required to resolve complex interface issues • Deliver status reports

4.4 ​IDENTIFY INTERFACE AREAS Managers use project plans, timelines, and budgets to reduce execution risk, the risk that designated activities will not be carried out properly. However, they inevitably neglect two other critical risks, the white space risk—that some required activities won’t be identified in advance, leaving gaps in the project plan; and the integration risk—that the disparate activities won’t come together at the end (Matta and Ashkenas, 2003). Identifying interface areas during early project planning helps to prevent these problematic issues later in project execution. With the common boundaries established among the various interface groups, it is now possible to begin identifying and documenting the relevant interface areas that need to be resolved within the interface group. As defined in Chapter 3, an interface area is . . . a defined area of interest on the common boundary between two or more interface parties. An interface area is characterized by one or more interface issues that the interface parties must agree upon and resolve. It should be noted that each interface group has different interface areas, issues, and items, which are dependent upon the common boundary they share. It is preferable that both the client and contractors perform this step. The client should perform this activity early in the project planning phase to help develop the responsibility matrix for the respective prime contracts. The responsibility matrix illustrates the broad division of responsibility among the various contracts as the project proceeds through its life cycle. Prime contractors should also perform this activity immediately after contract award as part of project and interface planning. This helps to prevent misalignments in their scope of work and establishes a foundation for common understanding for future interface activity with other interface partners. A common understanding of the interface areas between the interface parties is important to ensure that both the scope of work or responsibility and their respective plans for delivering their services and products align with one another. In addition, a common understanding

Basic Interface Management Process

83

of the interface areas serves as the base for further decomposition into specific interface issues and items, which will be discussed later in this chapter. Examples of interface areas are piping, electrical, telecommunications, safety, control, automation, pipelines, structural, schedule, signal exchange, process, procurement, free issue items, transportation, installation, etc. The aim is to first identify the main areas between the two (or more) parties, which serves as a basis for further decomposition. A common method for identifying and confirming interface areas is conducting an interface kickoff meeting between interface groups, often with client personnel present. Each interface party reviews the relevant portion of their scope of work with the other interface party and provides each party an opportunity to query the other. This results in an understanding of which technical (electrical, structural, process, etc.) and management (project management, procurement, etc.) personnel are required to support future interface activity (see Figure 4.4). Identifying these interface areas is critical to more detailed activity by the interface groups during interface meetings that result in further defining interface issues and specific interface items related to each issue. Establishing and agreeing to the interface areas ensures that each party can identify respective personnel within their organization to handle these areas. For example, an interface group with an electrical interface area will likely identify their respective project electrical leads as the owners of this interface area. Thus, these personnel become key to follow-on activities of determining interface issues and items within the interface management process. What should become evident in the description of the interface process thus far is that while the process may start with activities by the project sponsor’s project organization, such as identifying interface networks and groups, the process quickly begins to involve interface parties more as it moves into identifying interface areas. As the reader will notice going forward, this is especially true during the next steps in the process.

Electrical Area

Interface Issue

Interface Items

Management Area

Interface Issue

Interface Items

Safety Area

Interface Issue

Interface Items

Figure 4.4  Identifying interface areas

84

Project Interface Management

4.5 ​DETERMINE INTERFACE ISSUES To this point in the interface process, interface networks are established, interface groups determined, and the interface areas within each interface group established. It is now possible to begin a more thorough analysis of each interface area for each interface group to describe the scope of interface issues as illustrated in Figure 4.5. As defined in Chapter 3, an interface issue is a statement identifying specific aspects of the interface area, such as physical compatibility or functional conformance, requiring interface activity within an interface group. The interface parties within each interface group commonly determine interface issues after the interface group is initiated. However, it is possible for the project sponsor’s organization to generate a preliminary list of interface issues from organizational informational archive assets if similar projects have been completed previously. While it is not always necessary to perform this step, it is helpful in complex system architectures where interfaces extend across many technical and managerial areas. This process also provides a mechanism to further organize interface items and to prevent identification and coordination of redundant items. This is especially true for multidiscipline interfaces. In essence, this step aids in further decomposition of interface areas into individual interface items. As illustrated in Figure 4.5, three interface areas are identified for an interface group: electrical, management, and safety. Further analysis during the Identify Interface Issues step reveals there are five issues across the three areas that need coordinating through interface activity and interaction. In the electrical area, the interface group, and/or client, has determined power protection and power management for alignment between their areas of responsibility. In this situation, power crosses the systems being designed, developed, and delivered by the interface group. In this context, the interface group with technical representatives from the electrical discipline can begin to identify specific

Interface Items

Electrical Area

Power Protection

Interface Items

Power Management

Interface Items Interface Items

Management Area

Schedule

Interface Items Interface Items

Safety Area

Figure 4.5  ​Identifying interface issues

Environment

Interface Items

Human

Interface Items

Basic Interface Management Process

85

interface items associated with each issue. The aim of these issues is to ensure that power is protected across the systems being developed by the interface group and that power flow can be managed effectively and safely. Thus, both system designs must align to prevent integration problems.

4.6 ​IDENTIFY AND PLAN INTERFACE ITEMS An interface item is a specific data or information request(s) resulting from an interface issue from one interface party to the other interface party. Arguably, interface items are the most important aspect of interface activity as they produce the documented agreements between the parties in an interface group. Interface items are identified by each of the interface parties in the interface group to the other party or parties, and are typically coordinated through an interface management database tool. Figure 4.6 shows eight interface items resulting from the five interface issues identified previously. When an interface item is identified, it is important that all parties agree on the delivery due date for the information, data, or item. It is common for interfacing parties to establish a regular meeting schedule (i.e., weekly or bi-weekly, or as otherwise appropriate) to review and discuss each interface item. The output resulting from interface meetings typically includes the following: 1. A number of action items related to the interface items for the respective parties to make progress on existing interface items 2. Identification of new interface items 3. Realization of an agreement on some of the existing interfaces that can now be closed 4. Identification of critical interface items that can create negative consequences to the project if not resolved

Protection Relay Type Electrical Area

Power Protection Power Management

Relay Setting Distribution Signals Milestone Interdepend

Management Area

Schedule

Factory Test Dates Design Reviews

Safety Area

Figure 4.6  Identifying interface items

Environment

Safety Signage

Human

Gas Fume Protection

86

Project Interface Management

When an interface agreement is obtained, interface items are closed. However, to reach agreement on an interface item requires the interface parties to maintain close communication and work collaboratively. Interface items are the focus of daily interface activities between the groups and the daily interface activities are focused on obtaining agreement. While Figure 4.6 only shows an abbreviated title for the interface item, in actuality, when entering the interface into the interface management tool much more data is included. At a minimum, the interface item includes the following information: • • • • • •

Brief title Applicable system or component Discipline (electrical, process, mechanical, multidiscipline, etc.) Description of the interface and what is required Planning dates Attachments (if necessary)

A number of interface software tools are available in the market, including proprietary tools developed by large companies. Depending on the interface software tool, the amount and types of information to be included can vary greatly. Regardless, each item should contain sufficient information to ensure a clear understanding by the other party.

4.6.1 ​Responsible and Receiving Parties

By now, it may appear obvious that a dependency relationship develops between two interface parties as they undertake interface activity. Both interface parties can identify and raise an interface item in the interface management system. When one party does so, it is dependent upon the other party to provide the information. Different interface management systems will describe this relationship differently, but we use the terms receiving party and responsible party. While this concept is discussed later in the book, the basic premise is that the initiator of the interface is termed the receiving party because they will receive the information. The party providing the interface to the receiving party is termed the responsible party because this party is responsible for providing the information necessary to resolve and close the interface. Both parties must be satisfied with the exchange of information to resolve an item. If not, the process is repeated back and forth until sufficiently addressed.

4.6.2 ​Planning Interface Items

In identifying interface items, the first hurdle to overcome is determining whether or not the item is a valid interface. A valid interface is one in which both parties agree is related to their scope or area of responsibility. Interfaces are sometimes raised erroneously; for example, an interface may be directed to the wrong interface party or it might be a duplicate of a previously identified interface. Ensuring sound interface analysis during the interface planning process can prevent costly errors with interface activity during the project execution phase. Assuming an identified interface is deemed valid, the interface group can begin to plan for its resolution and assign target dates for completion. Planning the resolution of interface items must be based on accurate and reliable project schedules versus arbitrarily established dates or those based on “hope” and “wish”. During this process, any interface “clashes” will become clear. An interface clash arises when the “need” date of the receiving party cannot be met by the other (responsible) party. In fact, these situations almost certainly arise in large-scale complex projects because it is extremely difficult to maintain total alignment of project schedules, especially if there are many different interface parties involved in the project. Any clashes that cannot be resolved are brought to the attention of the client, or owner of the interface

Basic Interface Management Process

87

management system, for arbitration. It may be necessary for the client to clarify priorities or to assist with mitigating action to prevent serious negative consequences.

4.7 ​MONITOR AND CONTROL INTERFACE ACTIVITIES Monitoring and controlling consists of those processes that are required in order to track, review, and orchestrate the progress and performance of the project (PMI, 2017). In any interface management system, it is necessary to ensure that the respective parties are working in good faith. This includes meeting regularly, documenting the results of these interface meetings (including action items), meeting interface planning dates, and working together to respond to changing situations which inevitably happen in large-scale projects. The Monitoring & Controlling step in the interface management process provides the framework for measuring, monitoring, and controlling interface performance during project execution. Interface performance is monitored using two basic methods: objective and subjective. Objective methods rely on quantitative metrics to measure performance against numerical performance targets. Subjective methods rely on qualitative factors to provide context for objective metrics. In its simplest form, objective methods rely on numbers while subjective methods are based on judgment. To make the distinction, a simple example of a patient being admitted to a hospital is provided. It is common for patients to have their vital signs and blood samples tested at regular intervals. These objective measures use specific equipment and the results are compared against specific criteria to ascertain whether a measurement is too high, too low, or within expected performance levels. In addition to these standard objective measures, the medical staff personnel perform subjective assessments, such as observing the color of the patient’s skin, shining a light into the eyes to evaluate responses, etc., and then use them to make judgments about the condition of the patient. These objective and subjective assessments combine to help the hospital staff gain a better understanding of the patient’s health.

4.7.1 ​Subjective Monitoring Methods

Subjective methods include observation of interface activity through participation in interface activity events, inquiry and interaction with interface management personnel, and review of interface meeting results. The aim of subjective monitoring is not to replace objective methods, but to supplement them and provide context and help to explain the underlying cause when performance deviates from expectations. Subjective methods rely on human senses and judgment formed through sensory inputs, which is then compared to expectations. For example, objective methods describe performance, but the performance metric itself is not very useful in explaining why performance deviates from expectations. Subjective methods allow us as humans to observe the environment in which the performance is occurring and better understand the factors contributing to the performance result—good or bad.

4.7.1.1 ​Participation in Interface Activity Events

Participation in interface activity meetings and reviews with interface groups is a useful way to gain insight into how a group is performing. Such participation helps the client or owner of the interface management system to assess the professional relationship between the interface parties. Individuals from either interface party who are less than cooperative can disrupt progress. By observing events within these meetings, it is possible to ascertain whether the interface group is working in good faith or whether members are presenting obstacles or challenges that impede the resolution of key issues.

88

Project Interface Management

By participating in interface meetings and reviews, the client or owner of the project’s interface management system can maintain visibility of developing issues within various interface groups and networks. In this way, the client can ensure regular interface interaction is occurring, adequate resources are provided by each party to coordinate the relevant issues, and human interaction remains professional and conducive to working toward the resolution of issues. In this regard, there is a human element and dynamic that serves to help move progress forward or prevent problems.

4.7.1.2 ​Inquiry and Interaction with Interface Management Personnel

It is also possible to gather performance information through regular interaction with the project’s interface personnel or those assigned with interface responsibility. It is nearly impossible to understand the concerns of people within the interface system by reviewing quantitative results. Rather, it is through personal interaction with members within the system that valuable information can be obtained. Short conversations, email inquiries, and impromptu meetings at the coffee machine can yield valuable insight into the thoughts and feelings of interface personnel, such as early manifestation of frustration, which can foretell problems that are more serious if not dealt with early.

4.7.1.3 ​Review of Interface Meeting Results

Every interaction between interface parties in the form of a meeting results in minutes that outline who was present, what topics were discussed, highlights of each topic, status of actions from previous meetings, and identification of new actions. By reviewing these minutes and other information generated during these meetings, it is possible to form an opinion of how well the group appears to be operating. Build up of actions, week after week, with little progress, poor attendance, and continued cancellation of meetings can all be signs of group problems; these subjective opinions can be compared against objective performance measures to form a more thorough judgment.

4.7.2 ​Objective Monitoring Methods

Objective measurements are quantitative and require the collection of measurable data, such as number, volume, weight, height, flow, pressure, etc. Most often, these methods appear in the form of important metrics that are meant to indicate the level of performance of a management function. As mentioned previously, objective methods are similar to someone being admitted to a hospital where one’s vital signs and blood samples are taken regularly to provide insight into how the body is functioning. Objective metrics are an important element of the management function and often take the form of basic statistics and KPIs.

4.7.2.1 ​Basic Performance Statistics

A number of basic statistics are used to monitor interface performance; these are based on the four main status conditions for an interface at any given time: identified, open, overdue, and closed. Most available interface software tools provide basic statistics on the number of interfaces in identified, closed, open, or overdue status at any given time. An identified interface is an interface that has been identified by one or more of the interface parties and has been recorded in the interface system but has not yet been validated by the interface group as suitable to open. An open interface means that the interface parties agree that the item is a valid interface, have agreed to open the item, and have planned response and resolution dates. An overdue interface item is an interface that is still open, but is past its planned resolution date. A closed interface item means that the interface parties have agreed to the completion of the information exchange and have therefore closed the item. An interface item cannot be closed unless all parties within the interface group have reached agreement.

Basic Interface Management Process

89

4.7.2.2 ​Other Potential Performance Statistics

However, other statistics may be valuable to track—such as the number of meetings conducted by an interface group, the number of canceled meetings, technology disruptions, etc., that focus not just on the progress of interfaces, but the humans and the tools driving the process. Such statistics might help ensure that the environment is conducive for effective interface activity.

4.7.3 ​Establishing KPIs

KPIs are items that, if monitored properly, provide measurable assessment of project performance. KPIs are used for monitoring changes from one reporting period to another and should a change occur, for understanding the significance of the performance change (Salapatas, 1985). The key to establishing KPIs as an objective performance measuring method is determining which metrics matter for each specific project and which performance level is expected. Some general metrics are provided below for guidance, but this list is not meant to be all-inclusive. Rather, it is intended to stimulate thought about which aspects of the interface management system are important for measuring its performance. This will vary from project to project and it is the responsibility of each project team to decide the best metrics for their respective situations.

4.7.3.1 ​Excessive “Identif ied” Interfaces

As stated earlier, an identified interface item means the interface item is recorded in the interface management software tool by one of the interface parties and is waiting for acceptance or confirmation, but is not yet open. Typically, one party or the other will input what they believe are interfaces into the interface management system for discussion at the next interface meeting. At the meeting, the interface group will determine whether the item is a valid interface and if so, will open it and plan dates. If not, it will be deleted from the system. While this is an acceptable practice, occasionally a large volume of interfaces will remain in identified status for long periods. From an interface management performance perspective, when these items are in identified status, they tend to be overlooked by the interface groups and therefore the number of interface items in this status should be monitored and managed to ensure the number is as low as possible. Ultimately, the goal is to monitor and manage interface activity to ensure items are resolved, which leads to the resolution of interface issues and the closeout of interface areas between the interface parties. Excessive interface items in an identified status can indicate problems within the group. While some interfaces items can be in this status for temporary periods, it is expected that the interface group will work to open and resolve the interface items as quickly as possible. One KPI could be number of identified interfaces. To establish a performance target, the client can mandate the project remain below a certain number or percentage, such as 5 or 10%. Meaning, the number of identified interface items should remain below 5 or 10% of open interfaces. Remember, KPIs are indicators. It could be that the project exceeds the performance target for valid reasons. The performance target exists to notify management that something is happening in the system and requires further investigation.

4.7.3.2 ​Excessive “Overdue” Interfaces

Open interfaces that are past their planned resolution dates is termed an overdue interface. Presuming that the interface dates are connected in some way to the project schedules and other project plans, overdue interfaces represent project risks. Excessive overdue interfaces can indicate poor planning and interface group dysfunction. Thus, it is important to monitor these interfaces carefully. In some cases, these interfaces can give indications of a more serious problem on the horizon, such as

90

Project Interface Management

schedule delays. There are a number of reasons why an open interface item can become overdue (i.e., is not resolved by the planned resolution date). These may include: • • • • • • •

Lack of agreement between the parties on how to resolve the interface Establishing resolution dates incorrectly (i.e., not linked to the project plans) Unexpected delay in work from one of the parties Relationship breakdown between the parties Change in work priority Unforeseen absence of key personnel Scheduling resolution dates without considering holidays, vacations, and other resource issues

Nevertheless, the challenge is to correct the situation by performing some form of controlling action to either resolve these interfaces or establish a new resolution date that is suitable to all parties.

4.7.3.3 ​High-Priority Interfaces

Some interface management programs develop a process to identify specific interface items as high priority or critical. These interface items can cause negative consequences to either the interface parties or to the project if not resolved as planned. Most interface management software has functionality to allow interface groups to identify high priority or critical interface items and highlight those items for management. This designation is set by the receiving party (that is, the party that initiated the interface) and indicates that negative consequences will result if the item is not resolved within the planned dates. Some clients prefer to monitor the total number of high-priority interfaces because they represent near-term risk that requires action. This is a metric to signify the importance of taking corrective action immediately, which helps to focus the attention of key management on the issue. An example KPI using this designation is number of high-priority or percent of high-priority interfaces. The client may accept a certain number and set the KPI to less than “n” (where “n” represents some value). If the project is managing a few thousand interfaces, then it may be acceptable to have a few situations (low percentage) that results in changes to the interface planned dates. A large percentage of high-priority interfaces relative to the total number of open interfaces could indicate planning problems, schedule changes, or lack of adequate interface activity.

4.7.3.4 ​Overdue High-Priority Interfaces

As the description implies, these high-priority interfaces are past their expected resolution or planned dates. This situation no longer represents risk; the risk has now become an issue. This metric signifies to the client that some negative consequence has occurred and is likely to manifest in the form of a change request or variation order request. From a monitoring perspective, an overdue interface item means that the interface parties have not been able to resolve the interface items by the planned resolution date they established in earlier interface meetings. Assuming the planned resolution dates are connected to the respective project plan, then these overdue high-priority interface items represent interface issues and require some controlling action.

4.7.4 ​Interface Performance Reporting

Performance reporting plays an important part in the Monitoring & Control step because it represents the mechanism to communicate interface performance to key project members. Whether as part of a subproject weekly or monthly status report, project status report, or as part of the project portfolio status report, interface performance reporting serves to focus attention on parts of the

Basic Interface Management Process

91

interface process, or specific interface issues, which require increased attention. An example of interface information reporting is discussed later in the book, but the inclusion of KPI information and standard statistics in the report are recommended as part of the weekly and monthly trend information. It is important, however, to ensure the performance metrics are put in context when reporting to prevent misunderstanding by those in the reporting chain.

4.8 ​RESOLVE INTERFACE ISSUES AND ITEMS The final step is to resolve each interface item and the parent issues, which will lead to the close out of interface areas. This step in the interface process is a direct result of interface activity; it occurs primarily during project execution and extends into the project closeout phase. As discussed previously, this part of the process is bottom-up, requiring synthesis, and is not completed until all items and issues are resolved and verified as implemented. Once verified as implemented, interface areas are closed out. It is important to note that interface item resolution often only indicates an agreement on an interface issue. However, that does not always mean the agreements have been properly implemented, for example, in the respective detailed engineering designs; they must be verified. Verification of interface activities can occur immediately after the agreement is made between the parties or significant time may pass before the agreement is implemented. Regardless, verification of interface agreements must be included in the project plan; verification can include analysis, demonstration, inspection, test, analogy, simulation, and sampling (INCOSE, 2015). The owner of the project’s interface management system normally prescribes this part of the interface management process in more detail through an interface management procedure or policy for the verification step to ensure that all parties are operating consistently across the project. For example, it is common for the client’s project team to establish a procedure that governs interface management during the project’s execution phase, which serves as a reference document in the respective contracts with contractors that are contributing to the project. This procedure also specifies applicability of the procedure to other interface networks; for example, in some cases, one project may have to adapt to the interface management system of another project. In addition, each contractor establishes its own interface management system based on the requirements from the client. This topic will be discussed in more detail later in the book. To resolve an interface issue and, subsequently, an interface area, the interface parties must reach consensus or agreement on each item. While this sounds fairly straightforward and simple to accomplish, many factors influence how well the parties achieve agreement. First, each party may have its own interests, typically contractual or functional responsibility, as its first priority. However, alignment with strategic objectives of the project tends to align parties with the same priorities. When a proposed solution is presented that does not conflict with their priority or interest, then agreement is typically not difficult to obtain. However, when a proposed solution to interface items conflicts with the other party’s interests or functional responsibilities, it can be very difficult to obtain agreement on an interface item. For example, a proposed solution that would transfer more work to the other party is typically met with resistance. Thus, it is important for both parties to work in a constructive way and maintain a good relationship to achieve agreement and resolution of interface items. Unfortunately, there are times when the two parties are not able to reach agreement and the issue needs to be escalated to higher management for facilitation. The inability to reach agreement imposes some level of risk as one party or both parties are not obtaining what they need to fulfill their respective scopes of work or responsibility. As it is not possible to leave interfaces unresolved, some intervention by the contractor’s management team or the client may be required to ensure a reasonable agreement is reached.

92

Project Interface Management

When an interface is agreed upon by both parties, it can be closed. This process transfers the interface item from an open status to a closed status and archives any information related to the interface item. Interface information includes the interface sheet that details the final agreement between the interface parties, which includes any documentation, such as drawings or schedules, and any attached documentation exchanged between the parties to reach the agreement. After an item is resolved and closed, each party must take action to ensure the agreement is implemented and adhered to within the scope of work or responsibility. Occasionally, the agreement is reflected as part of the closeout, such as on a final and approved technical drawing. In other cases, it must be incorporated at a later date, such as an agreement by one party to deliver material to the other party by a future date. In cases where the agreement must be enforced after the interface is closed, some verification activity needs to be performed to confirm adherence to the agreement.

4.9 ​SUMMARY As with any management function, a process is required to guide the actions of those within and affected by the process. The interface management process presented in this chapter illustrates the general flow of activities from identifying interface networks to close out of individual interface items and ultimately all interface areas. Since each project produces a unique result and is conducted under different circumstances and environments, the project team should view the process presented in this chapter as a guide. The main purpose of this discussion is to show that establishing an interface management process can assist in structuring, organizing, and segmenting complex interface interaction into manageable parts. This minimizes the opportunity for gaps in scopes of work or areas of responsibility and helps prevent integration problems later in the project’s life cycle. An effective process, including the interface management process, relies on tools and analytical techniques to support the people assigned, in this case, with interface responsibilities. This is especially true during project planning when the interface management system architecture needs to be established. In Chapter 5, we begin to explore analytical techniques from the project management and SE disciplines to support the interface management process. Then, in Chapter 6, we address interface management tools and their use to increase effectiveness and efficiency of the process. The aim of this chapter and the next two are to provide the reader with the skill, knowledge, and ability to plan and prepare a project’s interface management system for the execution phase.

4.10 ​REFERENCES Bible, Michael J. and Susan S. Bivins. (2011). Mastering Project Portfolio Management: A Systems Approach to Achieving Strategic Objectives. ISBN 10: 1604270667. J. Ross Publishing, Inc., Plantation, FL. Forman, E. H. and M. A. Selly. (2001). Decision by Objectives. World Scientific, River Edge, NJ. INCOSE (2015). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, Fourth Edition. San Diego, CA: International Council on Systems Engineering (INCOSE). ISBN: 978-1-118-99940-0. Jones, G. R. and J. M. George. (2014). Contemporary Management, 8th Edition, McGraw-Hill, New York, NY. Matta, N. F. and R. N. Ashkenas. (2003). “Why Good Projects Fail Anyway.” Harvard Business Review, September 2003 Issue. Project Management Institute (PMI). (2017). A Guide to the Project Management Body of Knowledge (PMBOK ® Guide), 6th Edition. Project Management Institution, Newtown Square, PA. Salapatas, J. N. (1985). Performance Measurements for Projects and Project Management. Price Waterhouse. August 1965. Pittsburgh, PA. Yi Wang, Marios Iliofotou, Michalis Faloutsos, and Bin Wu. (2012). Analyzing Interaction Communication Networks in Enterprises and Identifying Hierarchies, Department of Computer Science and Engineering, University of California–Riverside, Riverside, CA.

5

Interface Analysis “Analysis is the art of creation through destruction.” —P.S. Baber, Cassie Draws the Universe

This chapter on interface analysis is important to this book because it forms the basis for applying the critical thinking that is necessary to decompose the factors contributing to interface complexity into simpler and more manageable elements—by understanding, structuring, and organizing them. By methodically and logically analyzing the project environment, the system to be developed, and the relationships (or lack thereof) among stakeholders, the project team can better understand the factors driving interface and interdependency complexity and define how best to manage this complexity during project execution. In essence, the interface analysis process forms the foundation for the project’s interface management system and directly affects the management of interfaces and interdependencies during project execution. Performing the interface analysis process thoroughly during early project planning can pay dividends throughout the remainder of the project by increasing the likelihood of establishing a management system to monitor and control interactions between various entities contributing to the project or affected by the project. This is especially the case for the project sponsor, for whom the project delivers the most benefit. Conversely, getting this process wrong, or not performing it at all, will likely have the opposite affect and create significant problems and challenges for the project, the project sponsor, and those contributing to, or affected by, the project. So, how does one get it right? That is, how can the project proceed to devise a management system that will effectively manage and control the complexity inherent in interfaces, interdependencies, and interactions as the project progresses through its life cycle? In short, it starts by breaking the complexity problem down into smaller and more manageable elements. Since every project is unique, the factors contributing to its complexity will vary from project to project. The intent of this chapter is to provide a road map, presented as sequential steps, to methodically break down the complexity problem and manage the factors driving interface complexity. The outcome of the interface analysis process is a clear understanding of interfaces and interdependencies existing within the project and those influenced by external sources such that reasonable decisions can be taken to structure an interface management system to manage complexity during project execution. While a road map is provided in this chapter, analysis always requires critical thinking by those undertaking the process. Thus, the process presented here is meant to guide the actions of those who are assigned responsibility for establishing the project’s interface management system, but it is not intended as a recipe to be followed blindly. Specifically, the process provides a starting point to 93

94

Project Interface Management

help responsible persons make the best possible decisions about the management system that most effectively and efficiently addresses interface-driven complexity for their respective projects. Also, the process is intended to help these responsible persons to implement a system to manage interfaces and interdependencies—a system that will reduce risk associated with interface complexity and prevent unwanted negative consequences. The basic interface management process was presented briefly in Chapter 4 where the discussion focused primarily on defining what the process is in relation to the project life cycle. In this chapter, we focus more closely on how to perform the initial steps in the process; we address how to apply project management and systems engineering (SE) tools and techniques to analyze, that is decompose or break down, complexity into more manageable elements. The understanding of interface analysis in this chapter enables building the interface management system that will be discussed in Chapter 6. The interface analysis steps are shown in Figure 5.1 along the left side of the process with shaded boxes. Steps in the process are performed during the initiating and planning stages of the project, normally by the project sponsor’s organization, and, as stated, serve as the basis for the project interface management system to be implemented throughout the project during the execution phase. Interface analysis uses a top-down approach. That is, we start by exploring the broader project context and logically work to reduce complexity by breaking it into manageable segments—first determining which interface networks are applicable for the project, next identifying the interface parties within those networks, and then defining the main interface areas and issues between the relevant interface parties. Combined, these steps provide the mechanism to deconstruct the project environment so that reasonable decisions can be made about where interface complexity and risk reside and how to manage interfaces during the execution phase. In Figure 5.1, the steps in the analysis process are shown as linear and occurring across the project initiating and planning phases for the sake of simplicity in illustrating how to perform interface analysis. In reality, these steps overlap, and require iteration, especially if the project has a complicated development approach with multiple phases, such as engineering, procurement, and construction phases. As mentioned, this process is performed by the client or project sponsor organization, which is ultimately responsible for implementing project and SE management systems to ensure that the

Determine Interface Networks

Resolve & Close Out Interface Issues & Items

Identify Interface Parties Identify Interface Areas Determine Interface Issues

INITIATING

PLANNING

Monitor & Control Activities

Identify & Plan Interface Items

EXECUTING

MONITOR & CONTROL

Figure 5.1  Application of interface analysis in the interface management process

CLOSING

Interface Analysis

95

project is managed to a successful conclusion. However, it is natural for the project’s governing system to flow down these systems to scopes of work and areas of responsibilities by those contributing to the project’s development, and thus this analysis may be performed or at least validated at every level. In some cases, it may be necessary for parties within the project, such as main contractors, to perform this process to implement interface management within their respective scopes of work to enable them to manage internal interfaces and interdependencies. The same interface analysis process provides a useful road map for these situations. Regardless, the client’s management team will dictate the interface management system for the project and the terms and conditions under which it is expected to operate. All subordinate interface management systems within the project must align with the client’s expectations and guidance. The output, or outcome, of the interface analysis process is the information necessary to establish the basis for an interface management system that is appropriate to the circumstances of the project. That is, the output provides sufficient information to enable decisions for establishing an interface management system—one that provides the most effective means of mitigating interface and interdependency risk as the project progresses through its life cycle, which can often last many years. The results of interface management analysis are then used in Chapter 6 to produce an interface management system that describes, prior to contract awards and prior to actual contractor performance of work, how the project sponsor expects interfaces to be managed. The interface analysis process identifies what groups may need to communicate, about what interface areas and issues, and provides a foundation for: • Aiding the sponsor’s project organization to develop a procedure or plan that explains how interfaces will be managed across the project • Determining how interface management will link to other project processes, such as risk, document control, and quality management processes • Setting up an automated software interface register tool to manage high volumes of expected interface activity • Establishing the basis for interface training to ensure that project personnel who are entrusted with interface responsibilities are well prepared to execute those responsibilities This chapter addresses how to apply interface analysis and the tools and techniques that are available to perform it. We introduce a notional project example in the next section to help reinforce the concepts presented in this chapter.

5.1 ​NOTIONAL PROJECT EXAMPLE To reinforce the tools and techniques described in this chapter, along with how they support the interface analysis process, we have elected to introduce a notional project example from the oil and gas industry. This example project provides context and a sense of realism to better illustrate how to apply tools and techniques to the analysis process. It is used throughout the remainder of this book. The reader is not expected to be an expert in the oil and gas industry or have knowledge of oil and gas projects or system architectures. Instead, high-level information about the notional project, called Project Diamond (to be performed by the fictitious ABC Corporation), is provided in the appendices described in Section 5.2. While a notional project example from the oil and gas industry is used, the approach, tools, and techniques are equally applicable to other industries such as defense, information technology, telecommunications, aerospace, etc., where complicated project development approaches are employed to deliver large-scale projects. All companies and organizations in the notional project are fictitious.

96

Project Interface Management

5.2 ​PROJECT DIAMOND OVERVIEW ABC Incorporated is a global oil and gas company operating in many energy markets around the world, including Europe, Asia, and North America. ABC’s Global Energy Division remains focused on continued value creation in its oil and gas business segment, especially in the European market where new hydrocarbon exploration opportunities have arisen in the Barents Sea area. In terms of hydrocarbon exploration, the area is divided into the Russian side on the East and the Norwegian side on the West, with the two areas showing different petroleum geology. The Russian side contains a number of very large gas fields contained in upper Jurassic sandstone reservoirs, whereas the Norwegian side contains much smaller middle-lower Jurassic sandstone reservoirs bounded by fault blocks, which are large areas of rock created by stresses in the Earth’s crust. Some of the largest discoveries were made in the 1980s, but have still not been brought into production because of a combination of the extreme climate conditions, political instability, and the historically low price of gas. However, given current global oil and gas market conditions, and the realization of a substantial reduction in the costs of goods and services, ABC Inc.’s Project Diamond field has been deemed economically viable based on future energy price projections. Project Diamond encompasses a 20 km area on the Norwegian side of the Barents Sea within the development licenses DL 0072 and DL 0046. ABC Corporation (65%) is the operator for Project Diamond, while TDN, Inc. (25%) and Waverly Exploration (10%) are partners and are contributing capital funding equal to their filed percent of ownership. The project has previously received favorable 1 and 2 gate decisions in 2013 and 2014. However, the project has been on hold since the downturn in the global oil and gas market. Recently, ABC and its Project Diamond partners have submitted the plan for development and operation (PDO) to the Norwegian authorities and received approval this year. As a result, a gate 3 decision has been issued to move forward with project development. Project Diamond has been found to be economically viable with proven reserves of 250 million barrels of oil equivalents (MMBOE), probable reserves of 300 MMBOE, and possible reserves of 350 MMBOE. Project Diamond is envisioned with a fixed offshore platform partial processing, drilling, and living quarters (pdQ) and with a subsea development to transfer the Project Diamond well’s combined oil and gas stream to another project’s platform, the Sapphire platform (located 10 kms to the east on the Russian side of the Barents Sea). Once separated at Sapphire, the hydrocarbons are transferred to onshore processing facilities via separate oil and gas pipelines. Project Sapphire is operated by XYZ, Inc. and is envisioned as a fixed offshore processing platform pdQ with subsea oil and gas pipelines to shore-based terminal facilities. In addition, Project Sapphire will provide power to operate Project Diamond, which will be delivered through a subsea power and fiber cable from Sapphire to Diamond. The Oil Pipeline Project has been awarded by POL Industries and the Gas Pipeline Project is being performed by PGP Industries. All four projects are under development at the same time. Project Sapphire is expected to deliver first oil about 3 years from now, while Project Diamond is expected to deliver first oil about 4 years from now. Oil and gas pipelines are expected to be ready to connect to Project Sapphire 2 years from now. Additional information about Project Diamond is provided in Appendices C, D, and E, which respectively include the documents briefly described here: • Appendix C—ABC Management of Project Development: This document states ABC Corporation’s requirements for evaluating, planning, maturing, and executing field development projects from the decision to initiate a commercialization project of petroleum resources up to the handover to the operating organization. The key objective is to ensure orderly planning and execution of all development projects and to ensure a consistent evaluation and decision process within ABC and with contractors and other stakeholders. ABC Corporation uses a decision gate (DG) process with specific requirements for achieving a decision at each gate. Each of the project development DGs are described in this document.

Interface Analysis

97

• Appendix D—Project Diamond Mandate: Project Diamond has successfully achieved DG3 and is now preparing for the project execution phase, which at ABC is the phase performed after DG3 and up to DG4. This document serves as ABC’s guidance for further development of the Project Diamond project execution plan (PEP). • Appendix E—Project Diamond PEP for DG3 to DG4: The purpose of this document is to outline how Project Diamond is planned to be executed from DG3 to DG4. This document describes project targets, strategies, and the management and control systems that are established to meet the project objectives. It outlines the most important elements in the project execution phase, and how the project intends to handle these in order to achieve the timely, cost effective, and safe development of Project Diamond. It is highly recommended that the reader review this material and become familiar with its content and the sample project, Project Diamond. The material will give the reader greater context for the project used to illustrate the interface management concepts and processes discussed throughout this and subsequent chapters.

5.3 ​INTERFACE ANALYSIS PREPARATION One of the more difficult aspects of devising a management system for a large complex project is that of knowing where to begin, which can be overwhelming, especially if the person responsible for establishing the management system is new to the project organization and has little or no knowledge of the project or its environment. In fact, it can be quite an advantage if the person responsible for establishing the management system is a permanent employee of the sponsoring organization and has some understanding of the project’s history and other personnel to be involved in the project. As a member of the sponsoring organization, an individual will be familiar with existing policies and procedures, organizational culture, and possibly will be involved in or have knowledge of early project activities, such as those occurring during earlier DGs. However, it is common for sponsoring organizations to acquire competency or expertise from industry professionals to help establish project management systems, such as interface management. Arguably, one of the worst-case scenarios for a person responsible for devising a management system is to join the project organization as an employee or as a consultant after a gate 3 decision. As a project receives a favorable gate 3 decision, it is common for the sponsoring organization to rapidly acquire project personnel and start the process of devising and planning for implementation of the project’s management systems. A gate 3 decision, or similar decision, initiates activity to begin developing the project. In essence, the project begins its execution phase to realize the project result. Typically, the pace of activity after DG3 can be described as hectic; and joining a project organization cold can be quite overwhelming. One strategy to counter this situation and ensure time is used efficiently and effectively is to have a plan to guide one’s actions and activities from the moment of joining the sponsoring organization. This section provides suggestions for such a new member of the project team who is brought on board to address or assist with interface management. While it may be argued that these initial activities to establish oneself as part of the project organization are self-explanatory and need not be described in this book, they are included since they are important for ensuring thoroughness, robustness, and quality during interface analysis and devising a management system that is appropriate for the project’s circumstances. It is simply not reasonable to suggest that anyone can join a large, evolving project organization and immediately start devising a management system without being properly oriented, familiarized, and prepared. Williams (2003) noted that on average, the time for new external hires to achieve full productivity ranged from eight weeks for clerical jobs to 20 weeks for professionals to more than 26 weeks for executives. Although the acclimation process may be shorter for consultants with specific expertise, the period of rapid

98

Project Interface Management

acceleration after DG3 can be a challenge for newer people in large complex projects who are attempting to get off to a fast start.

5.3.1 ​Orientation and Onboarding Phase

The orientation phase begins once an individual has been selected and has agreed to join the project organization; it includes the initial days after joining the project organization. This phase is characterized by getting established in human resource systems, completing the administrative check-in process, obtaining access to sponsoring organization systems (such as security systems), and getting settled in the project office environment. Orientation is an introductory period aimed at obtaining an awareness of new surroundings, including people, environment, and routines. While this phase can last a number of weeks as the project organization establishes itself, it is normal to complete the main activities within the first week of joining the organization. The efficiency and effectiveness of the project organization’s orientation and onboarding process can vary. One should not expect the organization to provide the optimal plan. Rather, each joining individual should have an expectation of what needs to be accomplished in order to become comfortable in the new work environment. Orientation and onboarding can relieve a great deal of stress and improve the effectiveness of the interface analysis process because it ensures that the individuals performing the process have the right tools and familiarity with the project organization and environment to facilitate the steps in the process.

5.3.2 ​Familiarization Phase

The familiarization phase leverages the orientation phase. In this phase, the individual becomes familiar with the project organization and how it intends to operate. The familiarization phase answers the questions who, what, when, where, and why about the project environment. A key aspect of this phase involves becoming familiar with project personnel, their roles and responsibilities, and their relationship to the interface management function. It is equally important to understand what project organization roles have not been filled—as this may influence completeness or require assumptions when performing interface analysis. In addition, it is important to understand how the project organization will operate—such as: • Determining which software tools have been chosen and obtaining access to relevant programs, including training • Understanding how project information is organized and where it will be stored • Identifying which governing documents one is responsible for or will contribute to developing or updating • Confirming regular meeting schedules and plans • Learning project organizational administrative processes such as scheduling meeting rooms, obtaining organizational charts, contact and location information, etc. Interface analysis is not performed in a vacuum. Rather it is reliant upon access to and contributions from other project organization members. Establishing a plan to become familiar with the project organization and how it will operate will serve to initiate the interface management process efficiently and quickly.

5.3.3 ​Preparation Phase

Upon completing the orientation and familiarization phases, a new project member has sufficient understanding about the new project organization to begin preparing for interface analysis and

Interface Analysis

99

starting the interface management process. The preparation phase is focused on the preparatory activities that are necessary to perform interface analysis, such as obtaining information and data about the project—including historical information. As the reader now understands, we assume the reader is entering a large-scale complex project immediately after a successful DG3 and the project is now entering the project execution phase. During the preparation phase, relevant data and information needs to be identified, gathered, and reviewed in preparation for starting the analysis process. Specifically, key project documents are collected such as the sponsoring organization’s approach to managing development projects, the PEP (or similarly named document), the project mandate, relevant organizational procedures, and other project governing documents. These documents contain information that can help to establish assumptions, constraints, and unknowns prior to starting the interface analysis process. For example, the project organization can mandate that the project’s interface management system must comply with and use specific interface management register tools (constraint). These documents may not provide the necessary detail related to establishing an interface management system for the project; these missing details must be clarified with document owners, such as how interface management is envisioned to interact with other project management processes, such as risk management to manage interface risks, and document control to understand how interface documentation will be exchanged. This phase is also about collecting information from activities that provide inputs to the DG process. Typically, project organizations use some version of a stage-gate project development model to guide their projects. Each DG, or stage gate, requires specific information to support the decision process. These inputs provide valuable information about the project and help to explain why it received a decision to proceed. These input artifacts are useful during the interface analysis process because they help to provide context for the project and further identify any assumptions, constraints, and unknowns. More important, these documents can shed light on the factors driving or contributing to interface and interdependency complexity, which will need to be addressed by the interface management system.

5.4 ​INTERFACE ANALYSIS PROCESS Analysis is defined as a careful study of something to learn about its parts, what they do, and how they are related to each other (http://www.merriam-webster.com/dictionary/analysis). An important aspect of the analysis definition is careful study, which implies a logical and structured approach to ensure complete and thorough understanding of what is being studied. Following a methodical approach when performing analysis can increase thoroughness and completeness, ideally leading to a better outcome. From a high-level perspective, analysis requires steps to be performed in a logical or structured sequence. Each step in the process requires the collection of relevant data and information, which is used as inputs to applying appropriate tools and techniques. Processing data and information inputs using appropriate tools and techniques results in outputs designed to provide incrementally better understanding of what is being studied. Depending on the result of the outputs, additional repetition through the analytical steps may be needed. When combined (or synthesized), the results from the analysis process provide a better understanding of what is being studied as well as information to assist in making decisions. This general description of analysis is applied to interface analysis. For each of the interface analysis steps, we identify the relevant data and information inputs, the tools and techniques useful in processing the data and information, and the outcome to be achieved by performing the step. Back in Chapter 2, we described complexity, the elements needed to address it, and stakeholder analysis and its outputs as important inputs to interface analysis, which is, of course, the subject of this chapter.

100

Project Interface Management

Then, in Chapter 6, we show how interface analysis outputs serve the decision-making process and how they serve as inputs to creating the project’s interface management system. Figure 5.2 shows the interface analysis steps; these steps help to form the basis for establishing an interface management system. The outputs of the steps provide the foundation for formulating an implementation plan to be addressed in Chapter 6; the implementation plan describes how the project’s interface management system will be implemented across the project and throughout the project life cycle. Finally, once the interface management system has been implemented by the project sponsor organizations, the outputs of interface analysis—(1) interface networks, (2) interface parties, (3) interface areas, and (4) interface issues—serve as inputs to the relevant interface parties to further decompose and address interfaces and reduce interface complexity. The client (or project sponsor organization) is responsible for the project’s interface management system and is thus responsible for performing the interface analysis process described in the coming sections. It is important that this process be conducted as thoroughly and completely as possible since the main objective is to establish the best possible interface management system for the circumstances of the project.

5.4.1 ​Interface Network Analysis

As briefly discussed earlier in this book, we can look to social networking as an analogy to describing interface networks. In social networking, as individuals we establish (join) multiple networks (personal and professional) to segment dimensions of our lives. By segmenting or compartmentalizing other individuals into various network groupings, we are decomposing and handling complexity in our lives. As a result, many people belong to multiple personal and professional networks such as a Facebook network where relevant personal information is shared with selected friends and family, a professional LinkedIn network to interact with like-minded professionals, and perhaps many other special interest networks such as carpentry, sports, outdoor activities, etc. This same segmenting of our respective personal networks is very similar to that which is being accomplished using project interface networks.

Determine Interface Networks Identify Interface Parties Identify Interface Areas Determine Interface Issues

INITIATING

Figure 5.2  Interface analysis steps

PLANNING

Interface Analysis

101

Interface network analysis is necessary to understand how to group interface parties by their respective interface purviews. In large-scale complex projects, there are many different parties, with many different scopes, areas of responsibility, and degrees of influence at various organizational and project layers, or levels. The aim of interface network analysis is to segment related interface parties into networks of like entities, such that they share a common interface perspective. Interface network analysis takes a high-level view of the project environment with project entities both inside and outside the project scope and attempts to understand the different potential interface dimensions of the project. By interface dimensions, we are referring to potential interface activity from various interface perspectives. A dimension could be the scope of work, industry regulations, tie-in to other projects, etc. Once again, this is similar to social networking where we segment our social networks by family, friends, work colleagues, and personal and professional interests. These dimensions of our lives help to establish relevant social networks as the interface dimensions help to identify the interface networks for a project. As shown in Figure 5.3, the process used to perform the interface network analysis step is to gather relevant project information to identify potential interface networks and compare them against typical interface networks in order to specify the interface networks applicable for the project. Relevant project information can include the PEP, the project mandate, and the contract strategy, among other documents. When reviewing project information, it is possible to ascertain how the project is to be developed using the sponsoring organization’s project development process and how the system being developed by the project will function when in operation. In these project information documents, the desired information may take the form of a textual description, may be illustrated in architectural renderings, or contain reference to animated model simulations—or some combination of these. This information will describe or illustrate other entities outside the project, such as those that will operate with the system developed by the project; that is, how the project fits within the environment within which it is expected to operate. In addition, the PEP may provide varying degrees of detail about project development and is dependent upon the organization’s preferences. The project’s contract strategy and company provided items (CPIs) can help to define interface entities within the project environment. The contract strategy will lay out an approach for how the project is segmented to deliver the project result. Remember, it is uncommon for a single contractor to have sufficient expertise and competency to deliver all elements of a large-scale project. Instead, the project sponsor organization will look to maximize value while acquiring the best products and services throughout the marketplace by sourcing from multiple firms. More important, review of these project documents leads to the identification of additional documents that may need to be gathered and reviewed. For instance, if we find in reviewing the PEP that the system to be developed by the project integrates into an existing facility or another project, then

Project Sponsor-to-Industry (PSI) PEP

Project Mandate

Organization-to-Organization (O2O) Project-to-Existing System (P2ES)

Contract Strategy

Project-to-Project (P2P) Client’s Prime Contractor (CPC) Prime Contractor Internal (PCI)

Data / Info

Figure 5.3  Interface network analysis

Client Internal Project (CIP)

Identified Interface Networks

102

Project Interface Management

additional research is needed to identify relevant information about these systems and their relationships during the project’s development. A cooperation agreement may exist between firms that are developing parallel projects that must integrate during operation. In such a case, access to the cooperation agreement is needed to understand the extent of the integration. As expected, this part of the process can be a journey of discovery until sufficient information has been obtained to provide a clear picture of the project development and its environment. When adequate data and information has been collected and reviewed, the analysis team begins comparing collected project information against a list of most common interface networks, which were included in Chapter 4. For ease of reference, these networks include: • • • • • • •

Client’s prime contractor (CPC) Client internal project (CIP) Project-to-project (P2P) Project-to-existing system (P2ES) Project sponsor-to-industry (PSI) Organization-to-organization (O2O) Contractor Internal (CI) or Prime Contractor Internal (PCI)

This network list is not intended to be all-inclusive, but it serves as a starting point. It may be necessary to include other possible interface networks depending on the unique aspects of the project. It is important to understand that modern, large-scale complex projects are typically not independent endeavors. Rather, systems being developed by projects are often required to integrate with other projects and existing systems. This is an important aspect of the project environment, which certainly impacts effective management of the project’s interfaces. In some cases, it may be necessary for one project to be a participant in the interface management system of other projects, either within the same organization or toward projects undertaken by other organizations. Earlier in the book, we discussed the interface group concept and the roles of the lead interface party (LIP) and the interface party. The central notion is that in an interface group, each of the two (or more) parties has specific roles and responsibilities. One party is identified as the lead, or LIP, while the other is known as the interface party. This relationship denotes one party being more reliant upon the other. The interface group and LIP concept is not only applicable within a project; it may also apply at the project level where one project must interface with another project or existing system. One cannot assume that interface activity toward an external entity will be conducted using its project interface management system. Rather, there are many factors to be considered and agreement must be obtained with other projects and existing facilities. In cases in which it is agreed to use another project’s interface management system, specifically how this will be accomplished needs to be addressed within the relevant interface management plan or procedure and accounted for in the project interface implementation plan to be described in Chapter 6. The interface network analysis step ends with determining (1) which interface networks will be managed within the project’s interface management system, (2) which networks will be managed as part of another project’s processes, and (3) which networks are covered by other projects or existing facility interface management programs in which your project will be a participating member. Interface network analysis is the initial step in breaking down a project’s interface and interdependency complexity. By segmenting the various project entities into networks and understanding who is responsible for managing those networks, interface complexity is compartmentalized into manageable elements, which can be further decomposed during follow-on analysis steps. It may be questioned why all parties cannot be placed in a single network. Grouping all interface parties into a single network creates practical challenges in devising the interface management system and managing interfaces, which is counter to the purpose of establishing an interface

Interface Analysis

103

management system in the first place. For most major projects, the reasons for organizing multiple interface networks as opposed to a single network include: • Creates confusion: Establishing an interface register with a high number of interface parties within a single network can be confusing, not only affecting the visual appearance and setup of the register, but also locating the group you are looking for and the specific interfaces. Grouping interface parties into related networks makes it much easier to locate and understand interface dimensions. Individuals can be members of many groups; from a management perspective, it can be difficult to maintain control of who is to have access to what groups, especially in large-scale projects where hundreds of people have access to the interface management system. • Different rules: There are times when specific interface parties may establish the rules of the interface group, such as when interfacing to an industry party or another project. It is common to establish special interface rules to govern how certain interface groups will interact. Using an interface network makes it easy to segment out these groups and handle them according to the unique rules that govern their interaction. For example, a cooperation agreement between two companies whose projects must integrate may establish principles that need to be accounted for within their interaction, but these principles may not be applicable to other unrelated interface parties. The different rules may also apply to interface groups working on a classified project where certain information may need to be handled according to specific security procedures. • Controlling access: It can be quite a challenge to segment information even within one interface group to the people that need access. An individual, such as a manager, may belong to many different interface groups and be involved in many different aspects of interface management. Information being discussed in one group may not be applicable for people involved in other groups. When all interface groups belong to a single interface network, controlling which interface dimensions relate to which entities can be difficult. For example, when one company is interfaced with a separate company about technical integration issues, it can become problematic when commercial (e.g., procurement, sales, etc.) issues are raised, because these may be addressed in another interface group, which may have different members, rules, and access permissions. • Reporting challenges: From an interface management reporting perspective, when interface parties are bunched into a single network, it can be difficult to assess how certain groups or types of participants are performing. By establishing interface networks, it is easy to determine which aspects of the project are performing well, or not well, through a simple review of basic statistics. For example, contractors performing work to deliver the project may account for 40% of the total interface groups within a single network. It can be problematic to extract just these groups to determine how they are performing. While some software tools have the functionality to aid in this process, obtaining the right information may still require unnecessary time and data manipulation, when it could instead be easily reported through basic statistics provided for each network.

5.4.1.1 ​Project Diamond Example

In reviewing the Project Diamond information provided in Appendices C, D, and E of this book, several project characteristics emerge that are appropriate for identifying potential interface networks, including: • Significant oversight by government safety and industry agencies • Requires integration with other project(s) and as such, is governed by a Project Development Cooperation Agreement

104

Project Interface Management

• The project development approach segments Project Diamond into many subprojects • Employs a complicated contract approach to support project development (numerous engineer, procure, and construct (EPC) and engineer, procure, construct, and install (EPCI) contracts) • Sponsoring organization employs internal subproject teams to manage each contract • Topside EPC (process, drilling, and utilities) is central to system functionality • Extensive CPIs and free issue provided by sponsoring organization to the project Given these project characteristics, the following interface networks are recommended. 5.4.1.1.1 ​Project Organization-to-Organization Interface Network This network is proposed for Project Diamond to conduct interface coordination between companies whose projects are involved in the combined field development and operation—Project Diamond (ABC, Inc.), Project Sapphire (XYZ Corporation), Project Oil Pipeline (POL), and Project Gas Pipeline (PGP). This group is established for the purpose of coordinating and agreeing to interfaces related to the field development cooperation agreement established among the four companies including commercial issues, production license, hydrocarbon allocation, cooperation agreement conditions, legal, etc. It has been agreed by the respective companies that this interface network will be established and managed by ABC, Inc. However, personnel access to this interface network will be strictly controlled due to concerns over sensitive commercial information. 5.4.1.1.2 ​Project-to-Project Interface Network This network is proposed to conduct interface coordination among the four projects involved in the combined field development: • • • •

Project Diamond (ABC, Inc.), Project Sapphire (XYZ Corporation), Project Oil Pipeline (POL), and Project Gas Pipeline (PGP).

The operational concept of the area specifies Project Diamond to recover its hydrocarbons, partially process them by removing water content, and transfer the hydrocarbons along subsea pipelines to Project Sapphire. At Sapphire, Diamond’s hydrocarbons will be received and combined with Sapphire’s hydrocarbons. Sapphire will separate the oil and gas and transfer each along separate oil (POL) and gas pipelines (PGP) to onshore facilities. Sapphire will also provide power to Diamond. The purpose of this interface network is to manage technical, management, and industry interfaces related to hydrocarbon production and transfer; including power transfer from Sapphire to Diamond. It has been agreed by the respective projects to establish this interface network and that Project Diamond will manage this interface network within its interface management system. 5.4.1.1.3 ​Project Sponsor-to-Industry Interface Network This network is proposed to be established toward the industry safety agency, and other associated projects in the field development (Diamond, Sapphire, POL, and PGP), to ensure alignment between the projects’ designs and compliance with industry health, safety, and environmental (HSE) regulations. This network is intended to manage interfaces related to HSE aspects of the overall field design and development to support safety audits and verifications, the safety application process, etc. The Safety agency and each project have agreed to provide representation and this interface network will be managed within the Project Diamond interface management system.

Interface Analysis

105

5.4.1.1.4 ​Client’s Prime Contractor Interface Network Project Diamond’s development approach requires a complicated contract strategy composed of several EPC and EPCI contracts to segment the project (Topside, Living Quarters, Jacket, Subsea). This network will be established to manage technical, management, and other interfaces between Project Diamond’s contractors and issues along their shared scope of work boundaries. This network includes contractors providing CPI on behalf of ABC, Inc. and is the main focus of Project Diamond’s interface management system since it is directly focused on the work to deliver the project result. 5.4.1.1.5 ​Project Diamond (Client) Internal Project Interface Network ABC, Inc. utilizes subproject management teams to oversee the project’s complicated contracts in order to deliver the project result. As a result, a subproject team for each EPC and EPCI contract oversees the contract on behalf of the client (ABC, Inc.). This network is established for the client’s (ABC, Inc.) internal subproject teams to formally communicate interface issues affecting their subproject areas of responsibility and their contractors’ scopes of work. This network is intended for the client’s management teams to align interface risk mitigation strategies, scope changes, and other issues affecting multiple parts of the project. This ensures alignment of respective company personnel prior to the client teams issuing formal correspondence to their respective subproject contractors. 5.4.1.1.6 ​Prime Contractor Internal Interface Network Closer examination of the project’s contract strategy confirms the importance of the Topside EPC contract as central to key functionality to be delivered in the final system. This scope includes engineering, procurement, and construction as well as implementing the safety automation system (SAS) throughout the facility. Also, this scope assigns system integrity responsibility to the Topside EPC contractor who must ensure standardization, commonality, and integration of the entire offshore facility. In this context, system integrity means the Topside EPC contractor is charged with the responsibility for ensuring commonality, standardization, alignment of equipment and processes, etc., across the project so that the system developed by the project can integrate seamlessly. This network manages internal interfaces within the Topside EPC scope of work and is comprised of only those companies representing the Topside EPC/SAS team. 5.4.1.1.7 ​Project Diamond Interface Network Summary In defining the relevant interface networks, the first step in simplifying interface complexity is achieved; and it is these networks that form the basis for structuring the project’s interface management process during implementation. In Chapter 6, the interface management procedures are developed. It is important to understand that each network is unique and how these networks will operate and be guided mostly by the same rules; however, the process should be flexible enough to allow for special circumstances, such as cases in which a network includes other companies or projects. With the interface networks established, we can continue to analyze each network to understand the parties that need to belong to each network and their relationship to other entities within the network. Figure 5.4 provides a summary of Project Diamond’s proposed interface networks and the preliminary list of interface entities within each group. In Figure 5.4 it can be observed that interface entities comprise different types of organizations including projects, contractor companies, project sponsoring companies, industry agencies, organizational departments (operations and drilling & wells), and subproject management teams. This illustrates one of the advantages of interface management; it provides a means to account for disparate entities associated with the project—both those inside the scope boundary and those who can

Topside EPC Jacket EPC Transport & Install Living Quarters Hook-Up Drilling & Wells SURF

Client’s Prime Contractor (CPC)

Topside EPC Jacket EPC Transport & Install Living Quarters Hook-Up Drilling & Wells SURF Operaons

Client Internal Project (CIP)

Prime Contractor Internal (PCI)

Topside Engineering Topside Procurement Topside Construcon Topside SAS

Figure 5.4  Project Diamond interface networks and parties

INTERFACE PARTIES

Project Diamond (ABC) Project Sapphire (XYZ) Project Oil Pipe (POL) Project Gas Pipe (PGP)

Project-to-Project (P2P)

DIAMOND PROJECT INTERFACE NETWORKS

ABC Corporaon XYZ Corporaon POL Industries PGP Incorporated

Organization-toOrganization (O2O)

Industry Safety (PSA) Project Diamond (ABC) Project Sapphire (XYZ) Project Oil Pipe (POL) Project Gas Pipe (PGP)

Project Sponsor-toIndustry (PSI)

106 Project Interface Management

Interface Analysis

107

influence the project from outside the project boundary, so that they can be grouped into networks by shared interface interest.

5.4.2 ​Interface Parties (Interface Group) Analysis

Within each network, the entity population set needs to be defined to understand the scope of participation within each network and the relationships shared between the various entities. This analysis process identifies the relevant actors to participate in the network and their relationship (or non-relationship) to all other actors in the network. The relationship state between actors in a network is binary (1 or 0); either there is a relationship or there is not. That is, in a given interface network the entities within that network may or may not have a relationship with each of the other actors in the network. As illustrated in Figure 5.5, interface party analysis requires inputs including the interface networks identified previously, project information, and organizational information assets. As they are the output of interface network analysis, the interface networks serve as a starting point to determine the entities in each of the networks. Project information and organizational information assets serve to describe and establish the relationships between the entities. Tools and techniques are then applied to these inputs to derive an interface group matrix for each network. These tools and techniques include interviews, interface entity relationship models, and a template for interface group matrices.

Figure 5.5  Interface party analysis

The number of participants within an interface network can vary from just two entities to many (up to 50 or more in special cases). The number of entities within a network influences the difficulty in determining the interface groups. In networks with only a few entities (3 or 4), this process can be straightforward and may only require interviews with relevant project personnel. In networks with a large number of entities, more advanced techniques to establish relationships may be needed—such as the development of an interface entity relationship (IER) model. After determining that a relationship exists, the interface group matrix template provides a format to establish the LIP and structure the interface groups. The output is an interface group matrix for each interface network that identifies the interface parties and their relationships to other parties in the network.

5.4.2.1 ​Interface Entity Relationship Models

In interface networks comprised of many entities, an IER model can aid in visualizing relationships between different entities within a network. IER models are based on concepts used in entity-­relationship modeling techniques, which aid in understanding the relationships among various system and software objects. Peter Chen, then a faculty member at M.I.T. Sloan and later at Carnegie-Mellon University,

108

Project Interface Management

published a seminal 1976 paper on entity relationship modeling, which has been widely adopted for database design, business process engineering, and information systems. In his paper, Chen proposed an entity-relationship model to supplant and enhance three earlier data modeling approaches. The entityrelationship model views the world as consisting of entities (persons, things, events, or organizations) and relationships (the association between entities or members of entities); such as mother-daughter, the relationship between two person-type entities (Chen, 1976). An entity relationship model describes interrelated things of interest in a specific domain of knowledge and how they are related. For the purposes of interface management, a domain of knowledge is analogous to interface networks. An entity relationship model is composed of entity types (nouns which classify the things of interest) and specifies relationships (verbs) that can exist between instances of those entity types. In reference to interface networks, entities are organizations (companies, departments, projects, existing systems, oversight agencies, local interest groups, etc.). The concepts of entity relationship modeling are useful in identifying and visualizing relationships between interface entities within a network of several parties. It is worth noting that IER models are subject to defined symbols and construct rules. While appropriate for systems and software engineering purposes and also database development, strict rules and symbols are not necessary in developing IER models. Rather, simple construct methods are preferred. The intention of the IER model is to gain an appreciable understanding of the relationships that exist between various entities within an interface network. As such, the reader is encouraged to utilize creativity and simplicity in developing IER models and be less concerned with strict adherence to entity relationship construct rules. Using the information provided in Figure 5.4, an IER model has been constructed in Figure 5.6 that represents the CPC interface network. This IER example model provides an abstract visualization

Hook-Up SURF EPCI Commissioning

SURF Engineer

SURF Procure

SURF Construct

LQ Engineer

Offshore Team

Onshore Team

Jacket EPC

Engineer Team

Jacket Engineer

Safety Auto System SAS

Topside Engineer

Topside Procure

Topside Construct

Jacket Procure

Jacket Construct

D&W

Well Completion

Well Drilling

Well CleanUp

Topside EPC PQ Procure

LQ Construct

LQ EPC

Install Team

Transport Team

Engineer Team

Trans & Install (T&I)

Figure 5.6  Project Diamond—Topside EPC IER model (CPC interface network)

Drilling & Wells

Interface Analysis

109

of the relationships between Topside EPC (the light gray box in the center) and all other entities within the CPC interface network. Specifically, the model explores from the perspective of Topside EPC whether or not a relationship exists with other entities within the network and which entity should be designated as the LIP. While the Topside EPC perspective for the CPC interface network is displayed in this model, additional IER models can be developed to show the perspectives of other entities existing within the interface network or any other interface network. In constructing the model, boxes are used to represent entities. In this case, entities represent contractors within the CPC network where each contractor is depicted by an entity box. Within each entity box, major sub-entities are displayed using circles. The sub-entities represent sub-organizations contributing to delivering the scope of work in this case, whether the sub-organizations in a contract belong to one organization or multiple organizations. Sub-entities shown with the same shade of gray within an entity box belong to the same organization, such as all the sub-entities with the Trans & Install (T&I) entity box. Sub-entities belonging to different organizations are depicted in different shades of gray within the entity box, as shown in the Drilling & Wells entity box, which depicts four different organizations representing the entity in four different shades of gray. In all cases, the entity box is defined using the various scopes of work and areas of responsibility described in project documents. Solid lines are used to depict which entities within the Project Diamond CPC interface network have a relationship to the Topside EPC entity box. In Figure 5.6, lines have been connected to Topside Engineer to indicate that Topside Engineering will be managing interfaces on behalf of the Topside EPC entity. However, this may or may not be known at the time the relationship diagram is first drawn and connecting to the Topside EPC entity box is initially sufficient; the diagram can be refined later, after contract award, if it is not readily apparent which sub-entity will be responsible for managing interfaces. In any case, where a solid black line connects two parties within a network, an interface group will be established. In Figure 5.6, interface groups will be established against six interface entities (HookUp, SURF EPCI, Drilling & Wells, Trans & Install, Jacket EPC, and LQ EPC). However, it is necessary to identify which of the interface parties should be established as the LIP. While the solid black line simply denotes an interface relationship, each solid black line has a termination point with a black ball at one end of the line. The location of the black ball at the end of the line identifies the party to be designated as the LIP when establishing the interface groups. In some cases, this designation may be obvious and included in the terms and conditions of a contract or department area of responsibility description. In other cases, this designation may not be clear and may require additional analysis or research. Regardless, the LIP responsibilities are included in the interface management procedure, which will be discussed in Chapter 6, and are an important aspect of ensuring that the project’s interface management system operates effectively and efficiently. An interesting by-product of this process is a clearer picture of interface, interdependency, and interaction complexity existing within this network. A quick scan of the Figure 5.6 diagram shows a complicated web of intertwined entity relationships with significant dependencies. For example, it is clear in viewing this IER that Topside Engineering is a critical sub-entity, not only within the Topside EPC organization, but to all other interface entities within the CPC interface network. It is reasonable to expect that other interface entities would be negatively affected by delayed Topside engineering activities or poor quality of interface material and information. As a result, it is this type of insight to be gained from interface analysis and from which appropriate management processes can be emplaced to monitor and control interface activities between interface entities. This information can be captured in an interface group matrix.

110

Project Interface Management

5.4.2.2 ​Interface Group Matrix Template

The interface group matrix template is a formatted matrix to aid in structuring interface parties that have an interface relationship into interface groups. The group matrix template helps to easily identify which interface parties are assigned interface lead roles. As shown in the sample interface group matrix in Figure 5.7, the matrix is structured with lead interface parties across the top row and corresponding interface parties along the first column on the left (shown as Entity #1–5). The LIP is assigned based on each entity’s criticality to the project and its role and responsibility. Several entities are listed in the lead interface parties row from left to right. INTERFACE NETWORK - INTERFACE GROUPS Lead Interface Party

LIP #1

LIP #2

LIP #3

LIP #4

LIP #5

Interface Party Entity #1 Entity #2 Entity #3 Entity #4 Entity #5

X X X X

X X X

X

Figure 5.7  Interface group matrix example

A relationship between parties is denoted by an X in the cells that align between the LIP and the corresponding interface party. The X indicates a member of an interface group (an interface party), while the entity in the Lead Interface Party row indicates the LIP for that interface group. As indicated in Figure 5.7, eight interface groups are proposed within this interface network. In this example, the project sponsor has assigned LIP #1 as the main LIP given its importance to the project and relationship to all other parties. In interface groups not involving LIP #1, the priority has been assigned to LIP #2, then LIP #3, etc. For example, in the interface group containing LIP #2 and Entity #3, LIP #2 is the LIP, while in the interface group containing LIP #4 and Entity #5, LIP #4 is assigned as the LIP. It is reasonable to question how the determination is made to define one party as a LIP. Typically, for project contractors, this determination is made after concept development when the project’s system architecture is decided. This responsibility is then assigned as a formal contract requirement to the contractor delivering critical elements of the system’s functionality. For P2P and O2O networks, this designation is normally included in the cooperation or commercial agreement between the two projects or organizations. The technique of identifying interface parties, and using the matrix template to assign interface groups, provides the means to determine which parties need to interface with other parties. More important, it helps to establish which of the parties is more dependent upon the other party and to determine lead interface responsibility. It is also important to note that in projects spanning many years or those with considerable scope changes, this process may need to be reviewed periodically, or as appropriate, and adjustments made to parties and interface groups within a network.

5.4.2.3 ​Project Diamond Interface Group Matrices

Continuing with our CPC interface network from Project Diamond, Figure 5.8 illustrates the interface group matrix for the CPC interface analysis. Here we see the results of our analysis using the

Interface Analysis

111

PROJECT DIAMOND PRIME CONTRACTOR (CPC) INTERFACE NETWORK - INTERFACE GROUPS Lead Interface Party Interface Party Jacket EPCI SURF EPCI Living Quarters EPC Trans & Install (T&I) Hook-Up Drilling & Wells

Topside EPC

X X X X X X

Jacket EPCI

SURF EPCI

Living Quarters EPC

X X

X X

T&I

Hook-Up

X

X X

X X

Figure 5.8  Project Diamond CPC interface network matrix

IER model (Figure 5.6) and after completing similar IER models with the other interface entities, perhaps one from the point of view of each entity. Figure 5.8 shows how the CPC interface network is structured, including which entities comprise the network, what the interface groups are, and which entities have been assigned lead interface responsibility. In addition, it is now possible to observe that 15 interface groups have been established for the network. Looking at the first column of Xs, we see that it contains six interface groups, one for each interface party paired with Topside EPC as the LIP for each of the six groups. In the case of Project Diamond, Topside EPC is central to all the main system functions, and as such, it is designated the main LIP except in the interface groups in this network for which it has no direct role except oversight. As another example, we can see that one interface group comprises the Hook-up and Drilling & Wells entities with Hook-up assigned as the LIP for the interface group. Later in the book, as we discuss setting up the interface management system, implementation, and managing interfaces during the project’s execution phase, it will become much easier to understand the central role these groups play in managing interface and interdependency complexity throughout the project.

5.4.3 ​Interface Area Analysis

Using project management based artifacts (e.g., PEP, contract strategy, scopes of work, etc.), interface parties have now been organized into networks of entities with related interface interest and paired into interface groups. As is now realized, this only requires a high level of understanding of interfaces between entities. Analysis of interface areas marks a transition point from identifying who the interfacing parties are to what they need to interface about at a high level. The aim of interface area analysis is to determine the interaction domains relevant for an interface network that are needed to establish the interface management register, which will be covered in Chapter 7. Interaction domains are the basis for interactions between the parties and are based on relevant information and material needed by a party from other interface parties in the network in order to deliver the respective scope of work or area of responsibility within the interface network. In essence, interface areas bind interface parties within a network to relevant interface domains for their network. In some ways, these interface areas act as restrictions to support interaction in relevant domains while preventing interaction on topics that are not relevant for some interface parties within a network. For example, it may be appropriate for interface parties in one interface network to interact over commercial (i.e., nontechnical business disciplines such as contracts, supply chain, procurement, revenue/expenses) interfaces and issues, but inappropriate for them to do so in another interface network.

112

Project Interface Management

In Section 5.4.1.1, six interface networks were established for Project Diamond. A closer examination of these networks reveals that each network consists of different types of interface entities, each with different purposes. In interface area analysis, the aim is to obtain a better understanding of the breadth of interface domains between interface parties within a network. Thus, this aspect of interface analysis relies heavily upon technical artifacts developed during early SE activities to understand the connections between entities within a network. Interface areas are typically established by discipline or system, although other categories may be relevant, such as subsystem and procurement packages for internal networks and nodes for software-, control-, and automation-related networks.

5.4.3.1 ​Interface Area Disciplines

Interface area disciplines include both technical and management disciplines. By discipline, we are referring to the occupational field within an entity, which has responsibility for interacting with other interface parties related to interfaces within their occupational field. Technical disciplines reside primarily within engineering, research, and technology departments and include: electrical; process; automation; instrumentation and metering; hydraulic; structural; piping; heating, ventilating, and air conditioning; avionics, etc., among many others. These disciplines serve as the interaction point for solving technical interfaces within a project and to entities extending beyond the project’s scope boundary. As previously defined in Chapter 3, technical interfaces are normally associated with conceptual design and detailed engineering of the system under development by the project. The Systems Engineering Body of Knowledge (BKCASE, 2015) also defines technical interfaces as matter, energy, or information flows exchanged between the systemof-interest and its external components in the context of its use, including physical interfaces. Management disciplines reside primarily within project management, but can also extend to the sponsoring organization. In this book, we refer to these types of interfaces as project and organizational interfaces. Project management related interfaces occur across the 10 Project Management Institute (PMI) project management Knowledge Areas (PMI, 2017) and the project’s life cycle or phases—called Process Groups by PMI (see Chapter 3, Section 3.3.1.2 Project Interfaces). Management disciplines across the project interface areas include project control, schedule, operations, commercial, legal, change management, risk, etc.—among several others that may be specific to an organization or project. Project material or information needs between interface parties can extend to all facets of project management—such as shared risks, alignment of project schedules, quality control methods, inspection routines, use of preferred vendor lists, coordination of critical skills/ personnel, and others. Interface interaction across these management areas can relate to a wide spectrum of topics—including procurement activities, contract clarifications, safety procedures during installation and commissioning, critical material deliveries between contractors and subcontractors, and risk mitigation strategies.

5.4.3.2 ​Interface Area Systems

Arguably, one of the most overused and least understood words in the English language is system. This word is used to convey many different intentions and meanings, as noted in Chapter 2 (Section 2.3.3.2 What Is a System?). In the context of defining interface areas, we are referring inwardly to the system developed by the project and its physical elements. Kossiakoff and Sweet (2003) define system as a set of interrelated components working together toward some common objective. While simple and concise, this definition implies a multiplicity of interacting parts that collectively perform a significant function and also implies a closed system where all aspects of the system exist within its boundary. Further, this definition is oriented toward the integrated physical system to perform the common objective. At least on the surface, there is no mention of the infrastructure, such as people or processes, to translate the system from idea to reality.

Interface Analysis

113

System-related interface areas comprise the main (physical) systems needed to perform the functionality of the project’s outcome. For example, an airplane requires airframe, fuselage, wing, landing, guidance, and other systems to perform its main system function of air transportation. An offshore oil and gas platform requires the well, separation, treatment, transfer, and safety systems that when combined into a unified system (i.e., a supersystem comprised of many individual systems) can perform its main functions to recover, process, and transport hydrocarbons. Understanding the true meaning of system often relies on the perspective under which the word is used and is the reason we incessantly focus on defining its context to ensure the right perspective. In establishing interface areas by system, it is common to identify each system by a number followed by a title, such as System 13 Flowlines, System 22 Guidance, System 43 Avionics, etc. System identifiers are not random; they are usually identified during early SE activity during concept development and are contained in the project’s SE management plan or similarly titled document. Figure 5.9 provides an example of interface areas by discipline, system, and nodes.

5.4.3.3 ​Interface Area Approaches

In general, there are two approaches to establishing interface areas; predetermined (preset) and specified. Both approaches require the use of some method to categorize interface areas (i.e., disciplines, systems, nodes, etc.). In simple terms, a predefined approach relies on a predetermined template of interface areas that is applied automatically to an interface network while a specified approach requires interface areas to be tailored to the specifics of the interface network. In establishing predetermined or specified approaches, any combination of interface area categories can be used to best describe the interface area. This can, and will vary, based on the unique aspects of each project and preferences of project personnel. 5.4.3.3.1 ​Predetermined Interface Areas In a predetermined approach, interface areas are established using a predetermined set of project disciplines or systems. Predetermined interface areas are a way of leveraging commonalities for similar projects within a specific industry. While the system being developed by the project may be unique, it likely shares significant similarities with other projects within the same industry. For example, new airplane development projects share common technical traits with previous airplane models, which allows for interface areas to be predetermined. The same is true for oil and gas projects where similar management and technical disciplines are utilized to develop offshore oil and gas platforms (facilities). In both examples, projects within these industries use similar technical and management disciplines to deliver the project result. The predetermined approach is quite useful when undertaking a project similar to a previous project where the system developed by the project is similar and will involve similar interfaces. 5.4.3.3.2 ​Specified Interface Areas In a specified approach, interface areas are determined based on the specific circumstances of the project and the interface network. There are many occasions in which projects are unique and thus have no similar project precedent. Thus, the project organization and interface personnel must analyze the precise nature of the interface activity within a network to determine the areas that apply. Specified approaches also occur when technological advances within an industry change the way system functions are performed, which introduces new technical or management domains. For example, in the defense industry, significant progress has been made on remotely operated military systems, which introduces new and unique technical and management interface domains for project development. The oil and gas industry has continued to introduce and advance techniques for enhanced or improved oil recovery, which introduce new methods, procedures, and processes

70 86

Civil/architect

Drilling

Electrical

Project control/cost/economy

Geology

HVAC

Instrumentation/metering

Marine operation

Inspection

Piping/layout

Material technology

D

E

F

G

H

I

J

K

L

M

System Title

Automation

Telecommunication

Fire and Gas Detection

Hydrocarbon Separation

Control and Monitor

Power

Chemical Injection

Gas Pipeline

Oil Pipeline

Water Injection

Crude Oil Transfer

Gas Transfer

Drilling

Figure 5.9  Interface area—discipline, system, and node example

87

20

14

89

35

32

30

29

21

27

Procurement

B

C

System Code

10

Discipline

Administration

A

Discipline Code

001

V51

L01

E12

E11

P42

P41

F22

F21

C34

C33

C32

C31

Node Code

General

Process Control - Fuel & Water Pumps

Power Distr. & Control

Emergency Shutdown - Onshore Control

Emergency Shutdown - Platorm

Planned Shutdown - Utilities

Planned Shutdown - Wellhead

Fire & Gas Control - Living Quarters

Fire & Gas Control - Platform

Process Control- HVAC

Process Control - Utilities

Process Control - Injection

Process Control - Wells

Node Title

114 Project Interface Management

Interface Analysis

115

domains. Technology advancements change and extend the boundaries of interface activities to new domains, which then need to be accounted for more precisely in some interface networks.

5.4.3.4 ​Project Diamond Interface Areas

In the Project Diamond example, six interface networks are proposed. To illustrate how interface areas are applied to an interface network, we will use just three of the six networks; CPC and P2P between Projects Diamond and Sapphire, and the Topside EPC PCI interface networks. 5.4.3.4.1 ​Project Diamond Client’s Prime Contractor Interface Network This network is established to manage technical, management, and other interfaces between Project Diamond’s contractors and issues along their shared scope of work boundaries. This network includes contractors providing CPIs on behalf of ABC, Inc. and is the main focus of Project Diamond’s interface management system since it is directly focused on the work to deliver the project result. Figure 5.10 shows a wide range of technical and management discipline areas among the client’s prime contractors. This is because Topside retains central control of main systems and has been contracted to provide system integrity. The main emphasis of interface activity is to ensure integrity across all systems. Thus, only disciplines are used as interface areas for the CPC network. That said, it is not wrong if system were to be included as an interface area. In this example, it was determined not to be necessary. 5.4.3.4.2 ​Project-to-Project Interface Network This network is proposed to conduct interface coordination between projects involved in the combined field development—Project Diamond (ABC, Inc.), Project Sapphire (XYZ Corporation), Project Oil Pipeline (POL), and Project Gas Pipeline (PGP). The operational concept of the area specifies Project Diamond to recover its own hydrocarbons, to partially process them by removing water content, and to transfer the hydrocarbons along subsea pipelines to Project Sapphire. As shown in Figure 5.10, in the P2P network, interface areas have been established both by discipline and by system. Although Project Diamond has many more systems resident within the Topside module, only those systems listed in Figure 5.10 are appropriate for interface interaction within this P2P network because they are directly associated with transferring hydrocarbons between the projects in the network. 5.4.3.4.3 ​Topside EPC Prime Contractor Internal Interface Network Closer examination of the project’s contract strategy confirms the importance of the Topside EPC contract as central to key functionality to be delivered in the final system, as illustrated earlier in the IER diagram in Figure 5.6. The scope of the Topside EPC contract includes engineering, procurement, and construction as well as implementing the SAS throughout the facility. The SAS is critical to safe operation of the offshore facility and involves intense interaction among elements of the Topside EPC contract team. As a result, interface areas have been established by node as shown in the Topside Engineering PCI interface network interface areas in Figure 5.10. The node areas relate to major SAS elements and serve to focus interface interaction and interdependencies on these areas during execution of the contract.

5.4.4 ​Interface Issue Analysis

This purpose of this step in the interface analysis process is to identify interface issues. In Chapter 3, interface issues were defined as: a statement identifying specific aspects, such as physical or functional,

30

32

70

86

Drilling

Electrical

Project control/cost/economy

Geology

HVAC

Instrumentaon/metering

Marine operaon

Inspecon

E

F

G

H

I

J

K

Reservoir

Pipeline

Muldiscipline

Y

Z

76

Emergency Shutdown

Figure 5.10  Project Diamond—interface areas example

Weight control

X

Health, safety and environ (HSE)

S

W

T

Mechanical

R

Telecommunicaon

Quality management

Q

Subsea

Process

P

T

Operaon

U

S

Structural

L

Z

Y

X

W

U

R

Q

P

O

N

M

O

Telecommunicaon Automaon

N

87

Piping/layout

Material technology

K

J

I

H

G

F

E

D

C

B

A

Discipline Code

L

Fire and Gas Detecon

Hydrocarbon Separaon

Control and Monitor

Power

Chemical Injecon

Gas Pipeline

Oil Pipeline

Water Injecon

Crude Oil Transfer

Gas Transfer

Drilling

System Title

Discipline Title

Muldiscipline

Pipeline

Reservoir

Weight control

Subsea

Telecommunicaon

Health, safety and environ (HSE)

Mechanical

Quality management

Process

Operaon

Structural

Material technology

Piping/layout

Inspecon

Marine operaon

Instrumentaon/metering

HVAC

Geology

Project control/cost/economy

Electrical

Drilling

Civil/architect

Procurement

Administraon

Project Diamond & Sapphire Project-to-Project (P2P) Interface Network

M

20

14

89

35

29

21

Civil/architect

C

D

10

27

Administraon

Procurement

System Code

B

Discipline Title

A

Discipline Code

Project Diamond Client's Prime Contractor (CPC) Interface Network

001

V51

L01

E12

E11

P42

P41

F22

F21

C34

C33

C32

C31

Node Code

General

Process Control - Fuel & Water Pumps

Power Distr. & Control

Emergency Shutdown - Onshore Control

Emergency Shutdown - Platorm

Planned Shutdown - Ulies

Planned Shutdown - Wellhead

Fire & Gas Control - Living Quarters

Fire & Gas Control - Plaˆorm

Process Control - HVAC

Process Control - Ulies

Process Control - Injecon

Process Control - Wells

Node Title

Project Diamond Topside Engineering Prime Contractor Internal (PCI) Interface Network

116 Project Interface Management

Interface Analysis

117

of the interface area requiring interface activity with another interface party. Interface issues are specific questions or statements and serve as a foundation from which to later verify interface activity. In projects with extremely high interface complexity, there may be many interface dimensions for a single interface area, requiring further decomposition. In these cases, interface issues provide the means to further decompose and categorize high-level interface areas into more discrete segments. Admittedly, this step is not widely utilized currently nor is it included as part of the example project illustrated in this book, and thus will not be mentioned beyond this chapter. However, as systems developed through projects become increasingly more complex over time, the importance and applicability of this step will increase. Thus, the main reason for including it in this chapter is to make the reader aware of this technique and its benefits, as well as ways to perform it—should that be required. In most large-scale projects, it is often sufficient to simply identify the interface areas, bypass interface issues, and move directly to identifying related interface items associated with each interface area. Where interface areas have minimal dimensions or aspects, it is quite reasonable to manage without interface issues, but this is not always recommended, especially in complex areas of the project. In situations in which the interface area is expansive, involving many dimensions or aspects, and for which the criticality of the interface area is high, further analysis should be applied to decompose, segment, and structure the interface area into manageable elements. In this way, interface groups can initiate interface items for each issue; ensuring complete coverage across the entire interface area. In situations in which a single interface area requires interface interaction across several dimensions of the interface area, then further decomposition, segmenting, and organizing into interface issues will aid in reducing complexity by dividing it into more manageable elements. This is the benefit of decomposition and hierarchical analysis; it provides a logical and methodical way to further deconstruct interface areas into relevant interface issues. There are a number of techniques to identify interface issues for a single interface area, but this book will focus on two: hierarchical decomposition and design structure matrix (DSM).

5.4.4.1 ​Hierarchical Decomposition Diagram

A hierarchical decomposition diagram (HDD) shows a high-level function, process, organization, data subject area, or other type of object broken down into lower level, more detailed components. For example, decomposition diagrams may represent organizational structure or functional decomposition into processes. For purposes of decomposing interface areas to identify related issues, decomposition diagrams provide a logical process to visualize issues as interface area sub-elements for complex or complicated interface areas, especially if these areas involve different sub-groups, entities, or parts of the organizations. The HDD allows for increasing decomposition appropriate to the level of complexity for relevant interface areas. Figure 5.11 shows different interface issues related to an electrical (power) interface area shared between two interface parties. Here we observe a single interface area involving numerous interface dimensions or aspects including: power equipment, management signals, protection equipment and settings, and emergency shutdown, among others. In situations such as this interface area, each issue could require the attention of different entities or sub-entities or teams within each interface party, each of which has responsibility for different aspects of the interface area. Further, in highly complex interface areas, it may be necessary to subdivide into sub-interface issues as illustrated in Figure 5.12. Further, decomposing interface issues into sub-issues is directly related to one’s perception of the level of complexity of the issue in the context of other factors, such as when multiple teams or sub-entities within the interface party must contribute to resolving interface items (e.g., reaching interface agreements). Also, when multiple interface items are related, or when there is a need for specialized resources to contribute to specific sub-issues. Sub-issues might also be needed when elements of the issue are proprietary or on a need to know basis. Again, one must apply critical thinking

Power Management Signals

Power Protection Equipment

HMI Signals

Certification

Power Management Signals

Power Protection Equipment

ESD System Hierarchy

Load Shedding

Installation & Completion

Installation & Completion

Emergency Shutdown Process (ESD)

Emergency Shutdown Process

Power Protection Settings

Figure 5.12  Interface area issues and sub-issues—hierarchy decomposition diagram

Metering Signals

Distribution Signals

Commonality

Compatibility

Power Equipment

Electrical (Power)

Power Protection Settings

Figure 5.11  Interface area issue—hierarchy decomposition diagram

Power Equipment

Electrical (Power)

Power Procedures

Power Procedures

CPI & Free Issue Items

CPI & Free Issue Items

118 Project Interface Management

Interface Analysis

119

to understand the appropriate level at which to decompose an interface area, but it is important to realize that when an interface area may be less straightforward than it initially appears, techniques such as creating interface issues and sub-issues are useful and available. The purpose of decomposing interface areas is to simplify complexity associated with expansive, complicated, or multifaceted interface areas. As demonstrated throughout this chapter, managing interface complexity is about breaking down the problem into manageable elements through decomposition, and then structuring and organizing those elements in a way to increase clarity and minimize confusion. Another technique to aid in understanding interface issues is the use of a DSM.

5.4.4.2 ​Design Structure Matrix

A DSM provides a simple, compact, and visual representation of a complex system that supports innovative solutions to decomposition and integration problems (Browning, 2001). This is accomplished by displaying the relationships between components of a system in a compact, visual, and analytically advantageous format. A DSM is a square matrix with identical row and column labels. Elements are represented by the shaded elements along the diagonal. An off-diagonal mark signifies the dependency of one element on another. “Reading across a row reveals what other elements the element (in that row) provides to; scanning down a column reveals what other elements the element (in that column) depends on. That is, reading down a column reveals input sources, while reading across a row indicates output sinks” (Browning, 2001). This technique allows for a visual presentation of and logical progression through dependencies that exist among the elements in a complex system. Browning notes two main categories of DSMs: static and time-based. “Static DSMs represent system elements existing simultaneously, such as components of a product architecture or groups in an organization. Static DSMs are usually analyzed with clustering algorithms. In time-based DSMs, the ordering of the rows and columns indicates a flow through time: upstream activities in a process precede downstream activities” (Browning, 2001). Static DSMs are essentially variations of the square matrix called an N2 diagram and have been used by systems engineers to represent architectural components and interfaces (Becker et al., 2000). Yet, DSMs provide the flexibility to model components, teams, activities, and parameters, which align well for the purposes of understanding relationships within interface areas, including disciplines, systems, and nodes. Browning’s paper reviews four applications of a DSM that are useful to project management and SE professionals: • • • •

Component-based or architecture DSM Team-based or organization DSM Activity-based or schedule DSM Parameter-based (or low-level schedule) DSM (Browning, 2001)

The first two are static DSMs, while the third and fourth are considered time-based. Decomposing interface areas into issues may require one or more of the following DSMs to fully explore the breadth and depth of the complex interface areas to understand the spectrum of disciplines, systems (subsystems), and nodes involved in the area. 5.4.4.2.1 ​Component-Based or Architecture DSM This DSM can be used to model system architectures based on components and/or subsystems and their relationships. This type of DSM is beneficial for understanding interface issues associated with system-based interface areas. “A DSM can represent a system architecture in terms of the relationships between its constituent components. Such a model informs system decomposition into subsystems. Intelligent decomposition, or partitioning, is important to managing system complexity” (Browning, 2001).

120

Project Interface Management

5.4.4.2.2 ​Team-Based or Organization DSM This DSM can be used to model organizational structures based on teams, individuals, or groups and their interactions. The team-based DSM is useful for decomposing discipline-based interface areas. As discussed in the stakeholder analysis topic in Chapter 2, developing complex systems requires various groups and teams to effectively exchange information, often through interfaces. “Building and analyzing a team-based DSM highlights inter-team interfaces, which provide the greatest leverage for improving the organization” (Browning, 2001). 5.4.4.2.3 ​Activity-Based or Schedule DSM This type of DSM is used to model processes and activity networks based on their activities, information flow, and other dependencies. As shown in Figure 5.10 in Topside Engineering Prime Contractor Internal Interface Network interface areas, those interface areas can be established based on nodes. In essence, an activity-based DSM represents process input and output relationships, such as in software nodes for a fire and gas function. In systems exposed to dangerous or flammable chemicals, a fire and gas system is useful to detect and notify the appearance of such chemicals to allow for operations to cease and thus prevent a dangerous or deadly situation from occurring. Activitybased DSMs are useful in understanding the process flow from detection, alarm, and notification through the fire and gas network. Equally important is understanding how this process transitions across various parts of the system operation. Within the project environment, different entities may be responsible for different parts of the fire and gas system, which can be provided by different entities during project development. An activity-based DSM is useful in understanding product design, which “is characterized by highly coupled, interdependent activities—solving engineering chicken and egg problems—which must converge iteratively to an acceptable design solution. When activities begin work without the necessary information, the arrival or change of that information causes rework. Thus, rework results from information arriving at the wrong time, perhaps because of poor activity sequencing, changes, delays, mistakes, etc. Knowing which activities produce and depend on what information can help planners better understand and mitigate unintentional iteration or rework as a source of schedule risk” (Browning, 2001). 5.4.4.2.4 ​Parameter-Based (or Low-Level Schedule) DSM This type of DSM is used to model “low-level relationships between design decisions and parameters, systems of equations, subroutine, parameter exchanges, etc.” (Browning, 2001). “Thus, a difference between activity- and parameter-based DSMs is the level of analysis. Activity- and parameter-based DSMs also differ in the scope of their representations. While an activity-based DSM models a design process, a parameter-based DSM merely documents the physical relationships between the parameters that determine a design. Thus, an activity-based DSM may include reviews, tests, and coordination links that would not typically appear in a parameter-based DSM” (Browning, 2001). 5.4.4.2.5 ​DSM Resources Given DSMs’ application across the spectrum of project management and SE, resources are available at DSMWeb.org (http://www.dsmweb.org/en/dsm.html). DSMWeb.org is a not-for-profit organization that provides free tutorials, use cases, and publications with resources and tools for developing various types of DSMs. In addition, an example DSM is illustrated in Figure 5.13. An Excel DSM macro, including user guide, is also available for download from http://www.dsmweb.org/en/ dsm-tools/research-tools/excel-macros-for-partitioning.html.

Interface Analysis

Element Name

Element 1 Element 2 Element 3 Element 4 Element 5 Element 6 Element 7 Element 8 Element 9 Element 10 Element 11 Element 12 Element 13 Element 14 Element 15 Element 16 Element 17 Element 18 Element 19 Element 20

121

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

1 2 3 4 5 6 7 8 9 10 11 12 13 14 1 2 3 4 5 6 1 1 1 1 1 7 1 1 1 1 1 1 1 1 1 8 1 1 1 1 9 1 1 10 1 1 11 1 1 12 1 1 1 1 1 13 1 1 1 1 1 1 1 1 1 1 1 14

15 16 17 18 19 20

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 15 16 17 18 19 20

Figure 5.13  DSM Excel macro template

5.5 ​SUMMARY By performing the interface analysis process, the client or sponsoring organization has established the basic structure of the project’s interface management system by identifying the relevant interface networks, interface parties existing within those networks (who needs to talk to whom), the interface groups, and at a high level, the interface areas and issues that exist between the parties (what they need to interact about). This structure is captured in the interface group matrix for each interface network. Using this process, we have structured entities into related interface domains using interface networks and identified which parties belong to each interface network and their relationships. As we move into Chapter 6, we use this information as the basis for formalizing the project’s interface management system and preparing for implementation. This includes preparing the interface management procedure, setting-up the interface register tool in preparation for start of interface activities, establishing the interface organization and preparing roles and responsibilities, planning for interface training, and preparing for interface kick-off meetings with interface organizations and contractors. The output of the analysis in this chapter is crucial for establishing the foundation for the interface management plan discussed in Chapter 6 that defines how the project will manage interfaces throughout the project’s life cycle in order to minimize and control the complexity of interfaces and interdependencies.

122

Project Interface Management

5.6 ​REFERENCES Analysis (n.d.). In Merriam-Webster.com. Retrieved from http://www.merriam-webster.com/dictionary/analysis. Becker, O., J. Ben-Asher, and I. Ackerman. (2000). “A method for system interface reduction using N charts,” Systems Engineering, vol. 3, pp. 27–37. BKCASE Editorial Board. (2015). The Guide to the Systems Engineering Body of Knowledge (SEBoK), v. 1.4. R.D. Adcock (EIC). Hoboken, NJ: The Trustees of the Stevens Institute of Technology. Accessed August 8, 2014. www.sebokwiki.org. Browning, Tyson R. (2001). “Applying the design structure matrix to system decomposition and integration problems: a review and new directions.” IEEE Transactions on Engineering Management 48, no. 3: 292–306. Chen, Peter. (March 1976). “The Entity-Relationship Model—Toward a Unified View of Data”. ACM Transactions on Database Systems 1 (1): 9–36. doi:10.1145/320434.320440. Kossiakoff, A. and William N. Sweet. (2003). Systems Engineering Principles and Practice–First Edition. John Wiley & Sons, Inc., Hoboken, NJ. Pimmler, T. U. and S. D. Eppinger. (1994). “Integration Analysis of Product Decompositions,” in Proc. ASME 6th Int. Conf. on Design Theory and Methodology, Minneapolis, MN. Project Management Institute (PMI). (2017). A Guide to the Project Management Body of Knowledge (PMBOK ® Guide), 6th Edition. Project Management Institute, Newtown Square, PA. Williams, R. (2003). Mellon Learning Curve Research Study. Mellon Corp, New York, NY.

6

Interface Management Planning “Reduce your plan to writing. The moment you complete this, you will have definitely given concrete form to the intangible desire.” —Napoleon Hill

The foundation for interface planning was established during the interface analysis process in Chapter 5. Awareness of the factors influencing interface and interdependency complexity in the project and its environment is obtained from the result, or output, of the interface analysis process. This awareness provides a basis for informed, reasoned, and rational decisions about how best to manage these complexity factors with available resources and devise the project’s interface management program to handle interfaces and interdependencies effectively during project execution. However, these decisions about how to best manage interfaces affect a diverse project audience and thus, need to be communicated and conveyed in a way that is easily and clearly understood by disparate entities that contribute to—and are affected by—the project. More important, these decisions need to be interpreted consistently by all personnel with interface roles and responsibilities and by any entities actively involved in the interface management process. This includes those personnel within the project, parties external to the project (such as other projects or existing facilities), and entities that can influence or intervene in the project, such as safety or regulatory agencies. As implied by Napoleon Hill in the opening quote, decisions and intentions that are firmly locked away in the brain of an individual serve little purpose to the greater project audience. Instead, these intentions and decisions need to be crafted into a holistic message and communicated by the client or the project’s sponsoring organization team in the form of a project interface management strategy, procedure, and/or plan that is aligned with the project’s development approach and the sponsoring organization’s mandate. As will be discussed later in this chapter and also in Chapter 7, communicating the interface management approach (which is alternatively called the interface management policy, strategy, plan, or procedure) is accomplished through a variety of means with the interface management guiding document from the project sponsor (client) as the central element. In this book, we call the guiding interface management document the interface management plan (IMP). Just as important as preparing and providing the IMP document is ensuring proper planning and preparation prior to implementing the project’s interface management program. This planning helps to ensure smooth, effective, and efficient initiation of the interface management function during the initial phase of project execution. Building upon the interface analysis work described in Chapter 5, in this chapter we devise and establish the project’s IMP and prepare for its implementation.

123

124

Project Interface Management

As illustrated in Figure 6.1, an interface management program implies a holistic approach comprising several elements, including: • Determining the interface management strategy and defining it in an IMP or procedure document • Establishing lean interface work processes and routines to maximize efficiency and reduce interface action responses and agreement resolutions • Documenting the client’s interface guidance in a procedure to ensure consistent management throughout the project and over the life of the project • Identifying organizational and project resources and structure • Defining roles and responsibilities for personnel assigned to interface management • Identifying and implementing a standardized automated interface tool to manage the interface register • Planning and implementing techniques that ensure smooth interaction between interface parties and maintain alignment as the project progresses through the execution phase • Preparing for initial and follow-on training to ensure personnel with interface responsibility are properly informed as to how the interface program will operate and their roles and responsibilities in the management system In essence, the purpose of this chapter is to address planning, preparing, and developing the elements needed to build the necessary infrastructure to initiate an effective and efficient project interface management program.

Roles & Responsibility Inial & FollowOn Training

Interface Work Process

Planning & Implementaon Techniques

Automated Tools (Register) Figure 6.1  Project interface management elements

Documented Procedures

Organizaon & Structure

Interface Management Planning

125

6.1 ​THE PROJECT MANAGEMENT PLAN GOVERNS THE INTERFACE MANAGEMENT PLAN During early project planning, the sponsoring organization’s (client’s) project management team determines the principles and philosophy that support the development of subsequent project management systems. These project management systems address the many project and technical management functions needed to effectively manage the entire project—such as risk, project cost control, quality, changes, and interfaces among other management functions. Establishing these overarching project principles and philosophies is typically accomplished after the project manager receives the project mandate and has formed the core management team. This high-level guidance is documented in the project management plan or similarly titled document. In Chapter 5, the project execution plan (PEP) for Project Diamond, similar to a project management plan, was used to govern the interface analysis process. While the title, structure, and content of the document varies from project to project and organization to organization, the project management plan generally characterizes the main governing management principles, philosophies, and values necessary to executing the projects. This project management plan document provides information to subordinate project managers, functional managers, and others about aspects of managing the project and key information they need to consider when developing their subordinate plans and procedures. For example, the project management plan can include a high-level description of the project scope and development strategy, key milestone dates that are important for meeting final delivery of the project, how the sponsoring organization views risk, references to the sponsoring organization’s policies, etc. In many ways, the project management plan acts as a steering document for the project manager’s subordinate managers to aid in developing management systems for their respective management functions (risk, interface, quality, change, life-cycle information, description of main project tools, engineering management, and so on). In this way, this document serves a very useful function to ensure subordinate management systems used on the project comply with the sponsoring organization’s overarching policies, principles, and philosophies, while also remaining consistent with the project’s development approach. Much like the project management plan provides guidance about the project’s overall management approach, scope, high-level milestones, and the system to be developed, subordinate management plans and procedures rely upon and extend the project management plan into the guiding documents for their respective project and technical management domains. In essence, subordinate project managers and other managers of various project and technical management domain functions (risk, interface, quality, engineering, etc.) flow down guidance they receive from the project management plan into their respective plans, procedures, and processes. As expected, these subordinate plans and procedures delve into more detail about how the specific management function will be performed and provide the basis for how the project will operate for all entities contributing to or affected by the project during its development. In terms of the subordinate plan for interface management, the IMP described in the following section acts as the guiding document for the project’s interface management domain.

6.2 ​INTERFACE MANAGEMENT PLAN The IMP described in this book can also be called an interface management strategy or interface management procedure. Whatever we call it, the content of the document is most important. In this book, we use the term interface management plan to define the overarching, or governing, interface management document, which contains the description of the project’s interface management

126

Project Interface Management

approach and its guiding principles and philosophies so that all parties involved in the management of the project’s interfaces understand how interfaces are to be managed over the life of the project. Ownership of this document is typically assigned to the interface manager for the project’s sponsoring organization (client) and approved by the project manager. The input for the content within the IMP stems from the work completed during the interface analysis process that was discussed in Chapter 5. The IMP is the primary tool to communicate interface management guidance within the project and to entities beyond the project scope boundaries (i.e., to other projects, existing facilities, etc.). Communicating the content of this document is accomplished in many ways. It is common for the project sponsor to include this document as a governing document in commercial contracts to prime contractors or companies providing products and services during project development. It is also referenced in cooperation agreements where one project needs to integrate into another project or an existing facility. This document is also used to communicate with other departments or business units within the project sponsor’s organization, which helps these groups understand how they will participate in the project’s interface management. Remember, it is common for sponsoring organizations to provide free issue or company provided items (CPIs) to the organization’s projects. These free issue or CPIs can be proprietary (such as software) or unique product hardware (such as standard instrumentation packages, metering equipment, and specialty safety devices among others). As a document, the IMP can serve as an excellent communication tool, but of course, the usefulness of the communicated content is most important. The IMP contains the project sponsoring organization’s expectations of all parties regarding interface management during project execution. Large-scale complex projects require involvement by myriad internal and external organizations and entities with varying levels of interaction intensity. The IMP is the thread that binds all parties to ensure that management of interfaces is consistent and at a performance level that is expected by the client (project sponsor organization) to reduce the risk of interface problems manifesting as schedule delays, cost overruns, quality rework, and other issues that are harmful to the achievement of the project’s objectives.

6.2.1 ​Interface Management Plan Content Overview

The question of what information to include in an IMP is a source of near constant debate. In this book, we provide suggestions based on experience from projects across different industries. Since each project is unique, the content of the procedure will vary. Sometimes it may need more specific details because aspects of managing the interfaces require it, such as when projects are using proprietary technology or when projects contain areas under development that are classified in terms of information security. In other situations, the IMP may be quite general because the organization is using a well-established interface management procedure that was adapted from previous projects. In this book, we offer a practical approach that can be used as a starting point. From this starting point, those responsible for the development of the plans and procedures can adjust the content to the peculiar needs of their respective projects. An example of main content areas includes: • • • • • •

Overview of the project and its development Reference to organizational policies on interface management Key definitions and terms Description of interface networks Interface register Planned organization and structure of interface personnel

Interface Management Planning

127

• Roles and responsibilities of key interface positions • Description of the interface management process It is important to understand that the IMP is not about detailing specific interfaces—that is the purview of the interface register and related documents; rather, the IMP document focuses on how interfaces will be managed and on the project infrastructure that is necessary to facilitate efficient and effective collaboration among the relevant interface entities. More detail on each of the IMP content areas is provided in the following pages.

6.2.2 ​Overview of the Project and Its Development

It cannot be assumed that all personnel assigned with interface responsibilities have a firm grasp of the system to be delivered by the project and how the project is to be developed. Rather, the level of understanding will vary from person to person. Typically, individuals tend to focus solely on the scope for which their interface responsibilities apply. If a section is included at the beginning of the IMP that describes the project’s result (the final result), it will help to expand the perspective of the individual beyond the scope of that individual’s interface responsibilities. If possible, including a high-level conceptual rendering or illustration of what the project will look like when completed may also help the individual visualize the extent of the project boundaries—­especially when integrating with other projects or existing systems. In essence, it helps to provide context for where their individual interface responsibilities fit within the larger project architecture. This information is typically reused from other sources, such as the project management plan, project mandate, or other approved project document. Reusing information from previously approved sources ensures accuracy of the content. When duplicating content from other sources, it is important to represent the details exactly as those in the approved sources.

6.2.3 ​References to Governing Documents

It is important to reference sponsoring organization policies and practices where applicable. Very often, corporations undertaking large-scale projects have established project development organizations with mature policies and practices. Where applicable, the IMP should reference these documents to reflect that the content of the plan aligns with organizational policies and practices. As described in Chapter 5, applicable governing documents are assembled and reviewed during the interface analysis process. More important, these references provide material for those with interface management responsibilities to obtain deeper insight into why certain principles or practices are being applied to their project’s interface management program.

6.2.4 ​Key Definitions and Terms

Within the interface management community, terms and definitions are still being standardized— this is one of the main reasons for this book. In fact, one’s understanding of a term or definition related to interface management can differ substantially from project to project, organization to organization, and industry to industry. Using specific terminology and defining exactly what it means helps to ensure consistent understanding of important aspects of the project’s interface management program. This book includes terms and their definitions to explain what we are trying to communicate. It is likely that some readers will be familiar with some of these terms, but the definitions may be different, and others may be familiar with the concepts while the terminology may be different. This is exactly why it is important to include terms and their definitions in the IMP to

128

Project Interface Management

prevent any misunderstanding and confusion. Each term used in the IMP should be defined such that each diverse entity will clearly and consistently understand the term’s meaning. Commencing a new project, especially a large-scale project with high complexity, often means assembling many entities and literally thousands of people from diverse experiences, knowledge, backgrounds, cultures, etc. Their knowledge and experience concerning the application of interface management (if any) will also vary. Those with little or no experience in performing interface management will have minimal understanding of interface terms. This is not to suggest that the IMP be so detailed as to act as a training guide; but rather, that key philosophies and concepts must be included and clearly described. Training, discussed later in this chapter, will provide the muchneeded detail to familiarize and orient project personnel to the finer points of these concepts.

6.2.5 ​Description of Interface Networks

The IMP should identify and describe each interface network, including any unique aspect of managing the specific network. In many projects, the same person may be required to participate in more than one network based on their role and responsibility. Providing a description makes it easier to identify these people, and helps them to understand what aspect of the project interfaces the network is intended to address. These networks form the basis of interface management coverage across the project, including interfaces with external entities (i.e., other projects, existing facilities, or oversight and regulatory agencies, and the like). This part of the IMP describes the relationship among the parties in the interface network and the basics of how each interface network will operate. Descriptions of these networks, combined with the earlier overview of the project development and illustration of the project’s end result, help the reader better understand how to access and function as part of the other interface entities.

6.2.6 ​Interface Register and Use of Automated Tools

One of the most important aspects of managing interfaces is cataloging them within an automated interface register database. Large-scale complex projects generate large numbers of interfaces, which require thousands of agreements; each interface and subsequent agreement can involve significant associated data and information. The number of interfaces, the volume of data associated with each interface, and the timing for agreement on each interface can result in a complicated web of thousands of individual interfaces. Such a massive amount of interrelated information requires a database. Attempting to manage a large number of individual interfaces without a database will create interface problems, diminish the effectiveness of the interface program (which exists to reduce a common source of risk on complex projects), and thus will likely create other issues—such as negative cost and schedule impact. As in all fields in the modern information age, effectiveness of the management system is dependent upon the project team’s ability to manage information. Interface management is no different. The IMP should describe the automated tools that will be used to house the interface register. It is typical for the project’s sponsor to specify the automated tool that will house the interface register, which can range from an off-the-shelf commercial software tool to custom automated tools that were developed by the sponsoring organization. Along with the brief description of this tool, a statement about how access will be provided should be included in the IMP. Later in this chapter, we will cover the preparations needed to set up and establish the interface register prior to implementation.

Interface Management Planning

129

6.2.7 ​Planned Organizational Structure

The IMP should also include the organization and structure of key interface positions and entities that will be involved in managing project interfaces. This helps readers to understand the reporting structure and how the client’s interface personnel are aligned with contractors, other projects, and existing facilities, and with other entities and stakeholders. The authors discourage the use of individual names in the procedure. For obvious reasons, personnel can change in large-scale projects with execution phases extending for several years. It may also be necessary to include specific interface groups to be organized within an interface network. For example, when integrating with another project, it can be useful to identify specific technical (electrical, telecommunication, etc.) and management (commercial, procurement, etc.) interface groups that will be established between the two projects.

6.2.8 ​Roles and Responsibilities of Key Interface Positions

A number of key positions within the project’s interface management program require position descriptions, including but not limited to interface manager, interface leads, interface coordinators, and the relationship between the lead interface party (LIP) and the interface party. Depending on the involvement of the interface register software vendor, it may be worthwhile to explain their roles and responsibilities, which can include providing introductory and sustainment training on the software tool used to house the interface register and other administrative duties related to maintaining the interface register. The point is to highlight for the reader the main roles and responsibilities; in most cases it is not necessary to explain each and every duty that each position must perform. Individuals performing interface work should know whom to contact when they encounter situations or challenges; this can be documented in this section.

6.2.9 ​Overview of the Interface Process

It can be helpful to include a high-level process diagram to illustrate the basic interface process established for the respective project. Every project will employ some differences based on preferences, experiences from previous projects, uniqueness of organizational procedures, etc., that will naturally flow into the project interface management process. By process, we mean the steps necessary to matriculate one interface from inception through resolution. The process description and the accompanying process diagram provide those who are new to interface management and the project with an understanding of how the process operates within the project setting.

6.2.10 ​Other Information

As mentioned previously, there is a delicate balance between providing too much detailed information and not enough information, which leaves the reader with more questions than answers. On projects where information security is a priority, especially if some project information is subject to classification (Top Secret, Secret, Confidential, etc.), then certainly including this as part of the IMP is important. It could also be necessary to describe how interface management will evolve if the project has a unique development process or the respective project is part of another project’s interface management system.

6.2.11 ​Interface Management Plan Summary

The project’s IMP forms the basis for how interfaces, and interdependencies, will be managed within the project, and towards external entities. Based on output from the interface analysis process, the

130

Project Interface Management

plan describes important information about the principles, philosophies, and constraints that govern the project’s interface management. This document is developed by the project’s sponsoring organization and is likely led by the project’s interface manager and approved by the project manager. As a key management document, it is normal for the project sponsor to include the procedures as a contractual reference document as well as a governing document within the sponsoring organization and subordinate departments. While it is desired to obtain a document that remains stable throughout project development, it is highly likely that changes will be needed for a variety of reasons. Any changes to this document should be formally communicated to the affected parties using formal communication channels such as letters or document change notices.

6.3 ​ESTABLISHING THE INTERFACE REGISTER To maintain client visibility and traceability, monitor progress of interface activity, and maximize efficiency and timeliness in resolving large volumes of interfaces, an automated interface management tool is necessary to house the interface register. The register is a database where each interface item and its associated information are stored. This includes a history of the interaction between interface parties to reach agreement and all information exchanged between the parties leading to the agreement. In essence, it is the client’s evidence reservoir in the event of disputes between the interface parties at a later stage, or when one party fails to comply with agreements made earlier in the process. This register is crucial to documenting the formalities between independent parties. More important, the register is a chief source of status in developing interfaces and achieving agreements. As mentioned previously, interfaces are resolved through agreements between parties, not individuals. Interface personnel act on behalf of an entity, or interface party, and when an agreement is reached, it is expected that both parties will honor the agreement. As discussed later, verification and validation of these agreements are performed using a variety of techniques both by the respective parties and by the client. As a reference and archive tool, the interface register is critical to verifying compliance with interface agreements; failure to comply with agreements can result in problems for the project including delayed work, integration challenges, unexpected costs, technical integrity gaps, and the like. When this occurs—and the laws of probability suggest that it will on large-scale projects—the client has a basis for assessing the agreement from early interface activity to the current situation. As stated, a software tool is key to automating the interface register so that information about a specific interface item (a.k.a. an agreement) is retrievable quickly. Such tools allow for information searches based on a variety of criteria, which are simply not possible using manual methods, or at least not possible without significant effort and time. While some large, well-established companies have developed their own proprietary software tools to manage interfaces, several products are readily available in the marketplace. Among available products, this book uses Kongsberg’s Web Interface Register (WIR) to illustrate relevant concepts throughout specific chapters. Software and services company Coreworx has assisted us in replicating the concepts using the Coreworx Interface Management (CIM) software tool in Appendix B. Other options are also available and can be quickly located through an internet search. Selection of an appropriate tool, if one is not provided by the project organization, is outside the scope of this book. Regardless of the software tool used, it is important that interface personnel coordinate with the software tool representative (either the sponsoring organization’s representative if using a proprietary tool, or the vendor representative if using a software tool from the marketplace). Preferably, contact is made as soon as possible after project initiation to allow time to complete any administrative processing. Brief descriptions of both Kongsberg’s WIR and Coreworx’s CIM are provided below. More information can be found through an internet search or on their websites—www.kongsberg.com and www.coreworx.com.

Interface Management Planning

131

6.3.1 ​Kongsberg WIR

The Kongsberg WIR is a specialized interface management tool to structure, manage, monitor, and document the interface information exchange among different parties in a project. The initial version of the WIR software solution was created in 2003 as part of the development of a natural gas field on the Norwegian continental shelf called Ormen Lange. The intention of Kongsberg’s WIR interface tool was to create a web-based solution where all unnecessary manual administration could be eliminated to make interface communication and follow-up as efficient and effective as possible. As a web-based solution, WIR requires no software installation or download; enabling simultaneous users from all over the world to access and communicate directly using the application. This ensures that particular information and queries reach the right people at the right time during the entire project lifetime. The WIR solution gathers all interface information in one place and the information is managed centrally. This helps users easily obtain full control of interface items or project status. Access rights (write, read) are tailored based on the role and responsibility of the individual. The tool is equipped with a number of features that can be tailored by the interface network to correspond to the rules governing the interface network. It also contains general features, such as the minutes of meeting function, which helps to facilitate interaction between interface parties.

6.3.2 ​Coreworx CIM

The CIM software tool is provided as part of Coreworx’s Project Information Control (PIC) Suite of software built for the execution of large complex capital projects in the energy and civil infrastructure industries. Owners, operators, and contractors involved in the engineering, building, operation, and maintenance of industrial and infrastructure facilities use the Coreworx PIC Suite as an information management system to provide increased project execution certainty through good governance and information control for on-time and on-budget project delivery. The Coreworx PIC Suite provides functionality to enable document tracking and reporting, along with workflow practices indicating clear roles and responsibilities. It embeds the integration of project execution groups to a single, well-structured project information and project execution tool. CIM software is web-based and can be provided as a site-deployed solution or hosted through a software-as-a-service delivery model. CIM provides a simple, easy-to-use user interface tool, which has been developed in partnership with some leading oil and gas companies. Perspectives from owner operators and engineering, procurement, and construction (EPC) companies have resulted in a system for managing both internal and external project interfaces. Preconfigured work processes are delivered out-of-the-box as part of the standard solution and are estimated to provide a highpercentage fit. Alerts, notifications, and task-based actions are embedded in each work process to ensure that users are aware of task assignments and of any modifications or additions that were made to the interface register. The creation of interface documents is provided with prepopulated forms. All interested parties can be kept informed via automated notifications routed using the Coreworx Distribution Matrix. A roles-based security model ensures appropriate visibility levels and confidentiality requirements of interface activity.

6.3.3 ​Interface Register Setup

The interface register serves as the repository for interface information for the project, including detailed information about each interface area and issue, which parties are responsible for what, relevant documentation and diagrams, information flow between parties, and detailed interface status as the project progresses.

132

Project Interface Management

Referring back to Chapter 5 and Figure 5.4, an early output of the interface analysis process was the identification and description of interface networks and subsequent interface groups. The analysis process also identified relationships between LIPs and interface parties. This information serves as the basis for how the sponsoring organization will set up the register, which directly impacts how interfaces will be managed during project execution. Remember, these networks represent dividing various interface parties into logical groupings and each network must be managed within the project’s interface management system. Figure 6.2 shows the basic steps for establishing the interface register.

Iniate Interface Register

Establish Interface Networks

Assign Interface Groups

Define Interface Sengs

Figure 6.2  Establishing the interface register

6.3.3.1 ​Initiating the Interface Register

The first step in setting up the register is to contact the interface register software tool representative to initiate the interface register (either the company representative for proprietary tools or the commercial vendor representative when using market-based products). Initiating the interface register means the representative for the tool will perform administrative activities to establish an area of the interface tool for the respective project. During initiation of the register, the project organizers and the register tool representative discuss which settings to implement and which to exclude. Each software tool typically contains a number of features, which may or may not be applicable for the respective project. For example, some register tools allow for preliminary information settings to be established, which can be useful during the detailed engineering phase since most engineering activities are iterative and require multiple iterations to become finalized. In some cases, project sponsors allow an interface to be closed based on agreements from preliminary information versus final information. For example, detailed engineering is iterative because technical details about the system’s design mature with each iteration; several preliminary iterations of engineering documentation are generated before obtaining a final as-built state after construction. This results in numerous revisions of engineering documentation—such as process and instrument drawings (P&ID) depicting the flow of a process with relevant instrumentation equipment, general layout drawings showing where specific equipment will be located in a particular area, telecommunication topology illustrating an overview of a system’s communications architecture, etc. In some cases, the interface party requiring this information may not need the final information to reach agreement on a particular interface. This topic is discussed and illustrated more thoroughly in upcoming chapters, but it is important to recognize this aspect of interface management and how it affects the establishment of the interface register and the governing of the project’s interface management. These settings may also include features such as priority, which allows interface parties to designate specific interface items as high priority; indicating potential negative consequences to the project or subproject if not resolved. These settings can be global and applicable to all interface networks

Interface Management Planning

133

or tailored specifically for the conditions of each network. For example, when one project is integrating into another project, a formal agreement is normally established between the two projects that contains information about how the projects will interface. This may require some unique settings or features in the project-to-project (P2P) interface register (in the Project Diamond example) that is different from the settings or features for other interface networks being managed. Setting up the register also includes assigning various administrative rights to designated client (company) personnel and assessing the level of support needed to manage the interface register during implementation—such as estimates for the number of people who will have access to the interface register and planning to provide that access. During implementation of the system, it can be expected that a high number (perhaps hundreds) of personnel will need access (either read only or write) to the interface register. It should be noted that in this process, the roles and responsibilities between the owner of the interface register tool and the project should be explained. Whether using a proprietary tool or a commercial product, interface register setup nearly always requires assistance from the register tool representative. This is natural since they are the experts with the software register tool and how it operates. Thus, access to these setup functions is typically restricted. Once the tool is established, then the designated client personnel, such as the project’s interface manager, are given administrative rights to the project’s interface networks to perform some functions—such as deletions, access control, etc.

6.3.3.2 ​Establish Interface Networks

Once the interface register is initiated, the structure of the project interface management system can now be implemented by establishing interface networks in the interface register. In Chapter 5, interface network analysis resulted in a matrix identifying the networks and their constituent parties to be managed within the project’s interface management system—shown in Figure 5.4 and repeated here as Figure 6.3. The interface network matrix shown is a summary of Project Diamond’s proposed interface networks and the preliminary list of interface entities within each network. This matrix is essential for establishing the foundation and structure for the project’s interface register. The next task in structuring the interface register is to establish the interface networks to be managed in the WIR software tool as shown in Figure 6.4. In the column titled “Project”, each network name is listed, which is followed to the right by the name of the company owning the network. In the case of our Project Diamond example, ABC Corporation owns all networks and is responsible for managing these networks. To the right of the company column, the status of the interface network is provided to illustrate whether a network is still open and active, or closed and thus inactive. Regardless of open or closed, the final column illustrates the number of interfaces—0/0/0/0—(identified, open, closed, overdue), indicating how many interfaces are in each of the four statuses. The terms identified, open, closed, and overdue will be explained in more depth later in the chapter. However, these terms refer to the summary status of all interfaces generated in the network and provide a quick indication of each interface group’s progress in resolving their existing interfaces. Since these networks have only been established, they are active, but have not yet undertaken any activity; thus, the reason for no interfaces statistics shown in the interface status column. As discussed earlier in the book, these networks correspond to the segments of the final system architecture (see Figure 6.5), and the relevant players, or actors, involved in these various segments of the system architecture. As noted by Shuman and Twombly (2010) when discussing collaborative networks for organizations, “Organizing in collaborative networks is a dynamic process, requiring great agility and resourcefulness. In light of the global reach of today’s organizations, it is entirely realistic to expect that any organization may seek to satisfy different sets of customers’ needs, regardless of whether the organization is large or small. As such, it may require a different collaborative

Topside EPC Jacket EPC Transport & Install Living Quarters Hook-Up Drilling & Wells SURF

Client Prime Contractor (CPC)

Topside EPC Jacket EPC Transport & Install Living Quarters Hook-Up Drilling & Wells SURF Operaons

Client Internal Project (CIP)

Topside Engineering Topside Procurement Topside Construcon Topside SAS

Prime Contractor Internal (PCI)

Figure 6.4  Interface networks established in Seaflex WIR interface register

Figure 6.3  Project Diamond interface networks and parties

INTERFACE PARTIES

Project Diamond (ABC) Project Sapphire (XYZ) Project Oil Pipe (POL) Project Gas Pipe (PGP)

Project to Project (P2P)

DIAMOND PROJECT INTERFACE NETWORKS

ABC Corporaon XYZ Corporaon POL Industries PGP Incorporated

Organization to Organization (O2O)

Industry Safety (PSA) Project Diamond (ABC) Project Sapphire (XYZ) Project Oil Pipe (POL) Project Gas Pipe (PGP)

Project Sponsor to Industry (SPI)

134 Project Interface Management

Interface Management Planning

135

Figure 6.5  Project Diamond operational concept

network to address each set of needs. Thus, it is likely that an organization will participate in multiple collaborative networks concurrently. It will be the network organizer or choreographer as we refer to the role, in certain networks and a member firm in others. These networks may have competing purposes or be comprised of competitive firms.” In the case of Project Diamond, ABC Corporation is acting as the network choreographer. In essence, the collaborative networks to which Shuman and Twombly refer are analogous to a project’s interface networks. Without knowing specifically which entities are contributing to the architecture in Figure 6.5, it is reasonable to assume a vast array of independent companies and organizations acting as project owners, contractors and subcontractors, vendors and suppliers, oversight and regulators, and stakeholders seeking to obtain some benefit from the collaboration. It is typical to think of monetary benefit as the key unifying factor in motivating independent entities to collaborate, but other nonmonetary benefit factors include health, safety, and environmental protection. Yet, to realize the architecture (shown in Figure 6.5) through projects and to realize value or benefits from these projects, these individual entities need to collaborate (i.e., work together in the best interest of creating value for all involved). Regardless, the key principle in motivating entities to participate in these collaborative networks is that each participating entity will achieve a greater value than the effort and time allocated to actually participating in the network. The same can be said for the interface networks that may be established for any given project. Once the interface networks are established, the next step in setting up the interface register is to add the interface parties within each network and assign interface groups.

6.3.3.3 ​Assign Interface Groups (Within Each Interface Network)

Interface groups are established by identifying all the interface parties within a network and then determining which parties need to interface with which other parties based on identified interfaces. For each interface group, the relationship between the parties must be established; that is, we need to determine which party is the LIP as we described in Section 5.4.2. Identifying the LIP for each group allows us to produce an interface group matrix for each network (see Figure 5.7). The groups represented in the interface group matrix are then transferred to the interface register. Transferring the group matrix to the interface register is shown in Figure 6.6 for the Project Diamond Client’s Prime Contractor (CPC) network. Remember, this is the network to collaborate on interfaces across their respective scopes-of-work boundaries.

Figure 6.6  Interface register (Project Diamond, CPC network)

136 Project Interface Management

Interface Management Planning

137

As shown in Figure 6.6, the LIP is listed across the top row in the matrix, and is titled Lead Interface Contractor. Since all parties within this network are contractor companies responsible for providing goods and services to the project client, it is quite normal to list the LIP as lead interface contractor (LIC instead of LIP), and the interface party (non-lead) as the interface contractor (IC instead of interface party). The wording used is a personal preference; the main point is to identify who is the lead in the interface group relationship. The interface parties are listed in the first column on the left, starting with Jacket EPC, then Transport & Install, etc. Similar to the LICs, here the interface party has been designated as an IC. Again, this is a personal preference when setting up the project’s interface register. We also observe that Topside EPC is listed in the first column or the LIC column. An interface group is identified wherever a status indicator (in this case 0/0/0/0) is located in the intersection between the column and the row; for example, Jacket EPC and Transport & Install form an interface group with Jacket EPC as the LIC for the group. This process is repeated for each interface network shown in Figure 6.3 until all groups have been established within each network’s interface register. With the assistance of the vendor representative, establishing these networks as an organizing mechanism through which the people and entities that are members of the network come together and govern (manage) themselves is quite easy and simple. As we will discuss in the following chapters, ensuring these groups function effectively and efficiently is a much more daunting task.

6.3.3.4 ​Def ine Interface Network Settings

One can think of these interface network registers as communities even when they occur in a business situation, and thus, they involve a social element. Therefore, a network organizer establishes a governance structure for what members can and cannot do within the network, especially as it relates to information privacy and access control to these networks. A choreographed mechanism implies that the choreographer (the network organizer) selects participants, determines the criteria for participation, and organizes and guides the work of the network (Shuman and Twombly, 2010). Similar to the choreographed networks described by Schuman and Twombly, interface networks have formal governance principles that are agreed to by the potential network members (i.e., interface parties) before a member can participate. Governance is the system for managing the individual and joint work of the collaboration, and has both structural and behavioral components. The intention of the governance structure is to ensure effectiveness and efficiency during interface collaboration. In essence, interface network settings are rules that govern the interface register for each network. This provides flexibility to adapt the governance structure and rules of each interface network based on its members and the objectives of the constituent members. These rules include, among others, such decisions as: • Access control (which individuals can participate in the network) • Access level (which members can input data and information versus those who can only view activity in the register) • Use of priorities (or not) for individual interfaces to identify interface items with greater potential to create negative consequences • Process for identifying or inputting interfaces into the register • Conditions necessary to resolve and close interfaces This is why it is important to provide a description of how each network will operate in the IMP because the network settings in the interface register for the network will need to correspond. This will also become important during initiation of the network’s activities during the interface management implementation phase, which will be discussed in Chapter 7; the governance structure is explained during implementation (i.e., start-up) of the network.

138

Project Interface Management

How rules are determined, and the subsequent interface register settings, will differ based on the nature of the network. In some cases, the project client or sponsor will dictate the rules as is the case for the CPC network. In this example case, since these companies work directly for the project sponsor through a formal contract arrangement, the client can mandate the rules and governance system between subordinate interface contractors. In other cases, these rules will need to be negotiated as with a P2P network involving multiple different project teams. As illustrated in Figure 6.5, there are four different projects involved in integrating Project Diamond into the overall field architecture. It is unlikely that the Project Diamond client or prime contractors will dictate the terms of how this network is governed since these are independent projects that are sponsored by competing companies. Further, attempting to dictate the terms in such situations may not be the best way to begin a collaborative process and may undermine achieving the goal and objectives of the network later during collaboration activities. As we progress, we will illustrate how these rules that govern the interface networks are translated into interface register settings in the interface software tool. Regardless, after the procedures for how the network will operate are determined, the software vendor is typically required to translate procedural rules into interface register settings that align with the interface network’s agreed upon procedures.

6.3.3.5 ​Interface Register Setup Summary

Establishing the interface register for each interface network is a key activity in preparing to implement the project’s interface management system. As Shuman and Twombly (2010) note, “Myths about collaboration often result in managers and executives failing to understand that the success or failure of many endeavors hinge(s) on the ability of people to collaborate. All too often people are told to go collaborate, but they have little understanding of what that means and what they are supposed to do in a particular instance. Rarely do managers communicate how collaboration differs from one partner to another, one network to another. It is safe to say that most have not even thought about how it should differ based on the purpose and economic opportunity of the underlying network. Most important, managers do not take the time to build new mental models to reflect the nature of the relationships needed among network members and between the network members and the choreographer. As a result, it is hard to get around the ingrained mindsets and behaviors that have traditionally governed relationships between a firm and external entities” (Shuman and Twombly, 2010). Establishing the interface network and aligning the interface parties within those groups with agreed governance helps to unify the members of the network in achieving their intended goals.

6.3.3.6 ​The Boeing 787 “Collaborative Management” Lesson

In their article titled, “Collaborative Networks Are the Organization: An Emerging Role for Alliance Management,” Shuman and Twombly (2010) discuss Boeing’s 787 Dreamliner project as an example for collaborative management systems. More important, they describe Boeing’s underestimation of the amount of effort required to govern the alliance and choreograph alliance activities. This situation can provide a valuable lesson at this point in this book to reinforce the seriousness of planning and preparation activities to implement a project development model and its underlying management functions and systems. When Boeing decided in 2004 to make a new product for the mid-sized, long-range commercial jet market, it introduced many engineering and production innovations. “In an effort to control costs, reduce time to market, and access specialist expertise, Boeing assembled a global collaborative network of more than 50 partners, operating in over 130 locations around the globe” (Shuman and Twombly, 2010). To lower the $10 billion development cost, Boeing gave responsibility to these partner-suppliers to design and build components of the plane, which were then shipped aboard specially modified

Interface Management Planning

139

Boeing 747s called Dreamlifters to Boeing’s facilities in Everett, Washington, for final assembly. Boeing anticipated that this distribution of work to specialist firms would reduce the time to market from six years to four and shorten the time in the final assembly area from 30 days to three. To reduce its own costs and share risk, Boeing required the partners to invest a cumulative $4 billion. In many instances, the partners agreed to delay receipt of payment for their work until customers took delivery of the planes; Boeing at that time planned first delivery in 2008. In return for accepting this risk and delayed payment, the partners received long-term contracts, some of which are for the 30-year expected life of the program. The Dreamliner design and production network was an important step in achieving Boeing’s long-term strategic objective of transforming itself from a manufacturer to an integrator. The purpose of employing this collaborative or alliance approach is to spread risk by motivating the parties to work together in the best interest of the project. Each party not only is required to deliver high-quality products and services, but is expected to share equally in the rewards or failures resulting from project success or failure. As the integrator or network choreographer, Shuman and Twombly noted that a number of manufacturing practices were adopted by Boeing that have come to be associated with best practices in strategic alliances. “Boeing used the design architecture to establish a common set of goals that every partner had a part in achieving. Special attention was paid to ensuring that the partners’ roles and responsibilities were thoroughly identified, broadly communicated, and understood. Metrics and milestones were defined, aligned, and agreed upon. Boeing established a common electronic communication and data sharing platform, benefiting from the widely accepted business and technology standards that enable globalization. Recognizing that intercompany teams would govern and conduct much of the work, it invested in team-building and relationship-development activities” (Shuman and Twombly, 2010). Even given all of this innovation to support the approach, Boeing experienced significant problems with its alliance concept for the 787 Dreamliner; resulting in late deliveries, dysfunction between alliance parties, and ultimately affecting financial performance objectives for the project. Shuman and Twombly, who studied this case extensively, determined the underlying cause of the dysfunction was Boeing’s failure to appreciate that implementing Boeing’s engineering and production innovations would require significant changes in structure and ways of working on the part of its partners. Boeing failed in certain key aspects of its role as choreographer. It did not understand the complexity of interdependencies within its collaborative network and the amount of direct management the network would need. Specifically, Shuman and Twombly (2010) note, “They did not appreciate the intensity of the collaboration the network required. It underestimated the quality and richness of information needed across the network as well as the depth and breadth of the coordination required. Indeed, the company viewed the network too narrowly, failing to account for its partners’ networks. And Boeing overestimated the ability of its own and partner employees to carry out the technical aspects of their jobs in a network environment. It is not possible to say if all the difficulties could have been avoided had Boeing better managed the network.” The purpose of injecting this case study at this point is to highlight the need for new ways to collaborate to support modern project development models and methods, which are required to support the global marketplace and the multiple entities involved in such projects. The concepts of interface management—and specifically here, of interface networks—groups and registers are key elements for the alliance owner (choreographer) and its members to help them effectively perform and govern their collaboration and prevent the types of problems experienced by Boeing in the early years of the 787 Dreamliner. Equally important is ensuring transparency and auditability among collaborating parties. The notion of spreading risk is a myth in the sense that, ultimately, the project sponsor/owner assumes all consequences from risk events, regardless of where they occur. In the Boeing example,

140

Project Interface Management

the collaboration approach was intended to spread risk and provide incentive to succeed, yet Boeing ultimately subsumed all the consequences from the alliance’s failures, resulting in damage to the Boeing brand and failure to achieve financial targets. Interface management is one key function designed to support the growing trend of strategic and business alliances in new product development and complex capital development projects.

6.4 ​INTERFACE TRAINING Regardless of project development approach (i.e., agile, traditional, alliance, rapid development, waterfall, etc.), the scale and complexity of the project will influence the extent of project interfaces the degree to which interface management must be applied across the project and with external stakeholders and entities. Exacerbating the situation is the fact that not all entities governed by the project’s interface management system will be activated at the same time; rather they will be activated and deactivated at varying times across the project execution timeline. In addition, individuals with interface responsibilities across the project will join and leave the project, sometimes expectedly and other times unexpectedly. When planning for the implementation of interface management, these factors dictate the need for training, and thus the need to develop and deliver an interface training plan. Establishing the plan for interface management training is paramount to ensuring a smooth implementation of the project’s interface management system and ensuring that entities participating in the system are activated at the right time and efficiently integrated into the project interface management system. Certainly, in this environment, training is not just a one-time event; rather it must be tailored for the specific needs of the training recipient across time, and transition into and out of the project. There are many different objectives to be addressed by the training plan including: • Initiating various interface entities into the project’s system • Providing the framework for sub-entities (such as contractor and subcontractors) to establish their interface management programs • Preparing interface management personnel who will help govern the management system • Readying individuals who will participate in the management process, as well as those who are affected by the management function In general, there are three types of training to be considered as part of the project’s IMP: introductory, initial, and maintenance training (see Figure 6.7).

6.4.1 ​Introductory Training

Introductory training is completed early in project planning after most of the client’s project team has been assembled, and provides a general overview of the project’s interface management system. This training is intended to orient the client’s project team as to how interfaces will be managed across the project, and toward other entities if the project is integrating to existing facilities or other development projects. In essence, it is designed to orient and familiarize disparate groups directly or

Project Team Introductory Training Figure 6.7  Basis for interface training

Ini al Interface Training

Maintenance Interface Training

Interface Management Planning

141

indirectly affected by the project interface management—such as the client’s subproject management teams and organizational departments and units providing support to the project. Every project uses a variety of processes to manage risk, time, cost, quality, etc. For example, the project’s management of change process, also known as change management, is designed to manage changes to baseline scope. Another objective of this training is to ensure that the broader project team understands how interface management is connected to other project processes. The details are not necessary at this stage, but reference to other project procedures should be highlighted in order to identify where additional detailed information is located should the situation arise. Delivered by the client’s project interface manager or designee, this training requires considerable effort and time. However, it is important to do this well—to minimize miscommunication during implementation of the interface management system and prevent problems later during the project’s execution phase. Training will also put a face with a name for the interface manager. In large-scale complex projects with several hundred people representing the client, this training helps to translate a name within a box on an organizational chart into a person. Thus, when questions arise about the managing interface process, project people understand whom to contact. In some projects, it may also be necessary to provide introductory training sessions for each contractor or contractor team that will provide products or services in development of the project. Typically, after the client awards a contract, the contractor company or team is provided an initial period, for example, 60 days, to prepare initial deliverables consisting of management plans and other administrative documentation. It is during this period that the client’s interface manager should consider conducting introductory training with key members of each contractor or contractor team. In addition, it may be necessary to conduct introductory training with other projects or existing systems. In the Project Diamond example, the system architecture requires the project to integrate into another offshore oil and gas processing facility and two pipeline projects. In our example, the companies associated with these projects agreed to use Project Diamond’s interface management process. Thus, it would also be necessary to provide an introductory session for each of these projects for the personnel participating in the applicable interface networks. Generally, the interface networks derived during interface analysis and the entities listed within those networks serve as a guideline for who should receive this training. The challenge is to plan the training schedule such that each entity has formed its team—or mostly formed its team. As will be observed later in this book, the timing of when the entities will become active in the project creates a challenge in completing the introductory training, which is typically staggered over time as each entity enters the project.

6.4.2 ​Initial Interface Training

Initial interface training is intended specifically for those personnel who were assigned interface roles and responsibilities—those who have direct involvement in the process. The level of involvement will vary by individual and entity and can range from a full-time position focused solely on interface management to a secondary or tertiary responsibility requiring only minimal or part-time involvement. For example, an interface manager or lead position is typically full time, while for technical engineering disciplines, such as electrical or structural, interface management responsibilities are part time and performed as part of the engineers’ overall job responsibilities. Naturally, this training focuses more on the detailed processes that were designed to comply with the client’s IMP and the dynamics of how the rules governing the interface group and its associated network will be practiced. As personnel with interface responsibilities are directly involved in the interface management process, and thus represent various entities across the project, it is important that training be thorough to ensure that all individuals understand how to comply with the rules governing their interface networks.

142

Project Interface Management

6.4.3 ​Maintenance Interface Training

In every management system, there will inevitably be changes, updates, and modifications to account for lessons learned and to adjust the management process to the unique circumstances or phases of the project. Maintenance training includes planned changes to the interface management process to account for unique events occurring during project execution or to specific characteristics as the project moves across different phases. For example, interface management during the detailed engineering phase may be different from the process used during the system level integration process when components and subsystem are being combined to form the final system. Thus, steps in the interface management process may change when moving from one project phase to the other. Maintenance training in some cases will account for modifications or adjustments due to lessons learned from applying the interface management process. As stated earlier in this chapter, the client makes informed decisions about which aspects of interfaces to manage during project execution and develops the management system accordingly. However, it is natural to find more efficient ways of performing specific steps in the management process or to identify a need for a new step in the process to address a management gap. Maintenance training provides a mechanism to capture these adjustments and ensure they are communicated to appropriate management system participants; ensuring the system continues to operate as effectively and efficiently as possible.

6.5 ​INTEGRATION WITH OTHER PROJECT PROCESSES An unfortunate mindset sometimes exists within traditional management that allows silos to thrive. That is, a view that specific project management functions are independent of other management functions. In reality, every management function interacts with and exhibits a level of dependency on other management functions. The level of dependency and interaction varies from limited to intense, but planning for integration of interface management with other project processes is essential to effective interface collaboration. The main project management functions with which interface management is inextricably dependent include project change management and risk management so these are addressed in more detail in the following sections. Some other project management functions with which interface management is interdependent include: quality management (verification and validation), schedule and cost management, and document control and information management. As part of preparation and planning, the relationship between interface management and other project processes needs to be described in the project’s IMP after coordination with the owners of these processes.

6.5.1 ​Project Change Management

Arguably one of the most important project processes is managing change, especially on large-scale complex projects. Change management is focused on managing scope changes; in the case of complex projects, scope is subdivided among many different entities contributing products and services, and scope definitions collide at the interfaces, either gently or otherwise. Ideally, project scope is defined fully and clearly, early in the project. Unfortunately, “practitioners of project management realize that scope change is an inevitable reality for any project. Management of scope change is of vital importance because scope creep can assume horrendous proportions and may even force project cancellation. Scope creep is a term used to describe unauthorized scope changes. Unauthorized changes may creep into project scope as a result of verbal instructions, e-mail instructions, written instructions that have been issued without realizing the magnitude of change, etc.” (Khan, 2006). Therefore, each project maintains a formal process to raise, evaluate, and implement approved changes.

Interface Management Planning

143

Periodically, a change proposal is raised in one part of the project, but also affects a separate part of the project with a different part of the project’s scope of work. Such a situation explains why interface management needs to be incorporated into the change management process, which is to ensure each proposed change is evaluated in the context of the entire project to ascertain the extent to which the change will affect other parts of the project. The change management procedure needs to describe how changes affecting multiple scopes of work will be handled and what role the interface management system plays within the process. Typically, a project’s change management process requires initiation of a project change proposal (PCP) within the change management register; the PCP is normally prepared by the change manager or with the assistance of the change manager. It is worth noting that interface activity may be the source or object of a PCP; this will be discussed in more depth later in the book. The PCP includes all the information related to the change to support the change evaluation process. After initiation, the proposed change is placed on workflow for relevant project personnel to review and provide recommendations in preparation for the formal change board meeting. Upon completion of the workflow, the project’s change board will meet to evaluate the proposed change, review the recommendations and make a decision whether to implement or reject the change. If the change is approved, the results are communicated through a memorandum, which includes the decision and any actions assigned to various individuals as part of implementing the change. By ensuring that change management includes interface management, changes resulting from interface activity or that result in changes to interfaces will be included in the PCP workflow during evaluations. This inclusion provides an opportunity to assess the impact of each PCP across different parts of the project scope and technical architecture. Interface management must be involved in the process when changes are identified as interface-related—both to communicate the change across the affected entities and to verify that the approved interface changes were implemented by the various parties. This includes adding interface evaluation as part of the PCP workflow. In large-scale complex projects where the project development approach requires contributions from many entities across several scopes of work, changes can be even more difficult to control, implement, and verify. When the approved change affects multiple scopes of work, it is typical for the client’s subproject management teams affected by the change to draft a formal communication (e.g., letter) to their contractors directing the change to each relevant scope of work in the contract. In these cases, not only must the change be implemented in each of the scopes, but the change implementation must align between the scopes, which certainly affects interface management. As is evident in our Project Diamond example, implementing changes can be even further complicated when the project is required to integrate with another project or into an existing system. Thus, an internal change in one project can create a ripple effect on other external projects or existing systems. In these situations, implementing the change requires action by different projects and possibly different project sponsoring organizations. It is normal to think of project change in a generic sense, but the real-world application presents many unique situations and challenges. Understanding how interface management fits within the project’s change management system is important to ensure that approved changes are implemented across disparate scopes, and that the implementation actions align between the affected scopes. These are some reasons why there should be alignment between the project’s “change management” and “interface management” procedures/plans.

6.5.2 ​Project Risk Management

Every project is subject to risk and utilizes accepted risk management processes to minimize negative consequences. As noted by Ahmed et al., “In general, unexpected events occur in projects and may result in either positive or negative outcomes that are a deviation from the project plan. Positive outcomes are opportunities while negative outcomes generate a loss” (Ahmed, 2007). On large-scale

144

Project Interface Management

complex projects, costing billions of dollars and spanning several years, managing risk is a critical aspect of project management. On projects employing complicated contract strategies, or those requiring projects to integrate with other projects or existing systems, managing interfaces is a particularly important risk area. Several risk register software products are available on the open market that provide the capability to catalog each risk and also typically contains a workflow function. Each risk can be tagged using several different categories as shown in Figure 6.8. The figure shows an illustration of a notional risk register using the Omega Pims Risk Management module. More information about Omega Pims products can be found at https://www.omega.no/omega-services/software. Figure 6.8 shows an example format for a risk register for assessing an identified risk. This format is standard, but can be tailored for the specific circumstances of the project. As shown in the lowerright, boxed outline area of the illustration, each risk can be tagged, or selected, as an interface risk. If the risk is particularly critical to the project, additional tags, such as interface top 10 can be added to ensure management focus. The designation of interface top 10 is used in this case to indicate that this particular interface risk is of more importance than many of the other interface risks. This designation can represent the severity of the consequences should the risk occur and the probability of the risk occurring. Thus, an interface risk with serious consequences and a high probability of occurring would naturally warrant more management attention. Understanding how to integrate the project’s risk management and interface management processes is crucial for minimizing negative consequences resulting from project interfaces and interdependencies.

Figure 6.8  Cataloging interface risk—example

Interface Management Planning

145

6.6 ​REPORTING REQUIREMENTS AND KEY PERFORMANCE INDICATORS (KPIs) An important aspect of any management system (or program)—including project interface management—­is to ensure it is performing effectively and efficiently for the purpose for which it was created. That is, after implementation, data and information are collected about the management system’s performance and if measurements are outside expectations or set tolerances, then corrective actions are implemented to bring performance back within tolerance. This basic construct requires a clear understanding of which management system parameters to measure and what should be the performance targets; these parameters and target ranges allow performance to be measured and determined to be within or outside of acceptable expectations. A common approach is to establish KPIs. While KPIs are not new, they are defined widely and include: • A business metric used to evaluate factors that are crucial to the success of an organization (http://searchcrm.techtarget.com/definition/key-performance-indicator) • Key business statistics, such as number of new orders, cash collection efficiency, and return on investment, which measure a firm’s performance in critical areas (http://www .businessdictionary.com/definition/key-performance-indicators-KPI.html) • A set of quantifiable measures that a company or industry uses to gauge or compare performance in terms of meeting their strategic and operational goals (http://www.investopedia .com/terms/k/kpi.asp) • An actionable scorecard that keeps your strategy on track and enables an organization to manage, control, and achieve desired business results (http://barnraisersllc.com/2012/02/ experts-define-key-performance-indicators/) In essence, KPIs are key measures to monitor the health of a business process, especially aspects of the process that are critical to ensuring the process is performing well. KPIs are used as a proactive management technique to detect problems early so that performance can be maintained within acceptable levels. Accordingly, they are intended to monitor important and meaningful aspects of performance and are metrics directly associated with whether the process is performing well—or not. In many ways, KPIs are analogous to the four main vital signs that are routinely monitored by medical professionals and health care providers when people visit the doctor. Vital signs include the following: body temperature, pulse rate, respiration rate (rate of breathing), and blood pressure (blood pressure is not universally considered a vital sign, but is often measured along with the vital signs). Vital signs can provide an early warning of health problems, which can be verified through additional investigation and diagnostics. That is, they are early warning indicators of potentially more serious problems. KPIs serve a similar purpose for monitoring the health of business processes.

6.6.1 ​Interface KPIs

In preparing to implement the project’s interface management program, KPIs need to be identified to monitor and control performance. As part of the project control function, every performance of every management function will be monitored throughout the life of the project. Thus, KPIs serve as an important interface performance communication tool. As a general rule, these metrics should be selected based on the specific circumstances of the project, be easily calculated using relevant data or related statistics, and be consistently and regularly measured against performance expectations. Preferably, data and information needed to support KPI assessment should be kept to a minimum.

146

Project Interface Management

In the next section, we suggest some example KPIs. However, when selecting interface KPIs, the following guidelines are recommended: • • • •

Use quantifiable metrics to measure interface management performance Collect data and report regularly (i.e., weekly, monthly, etc.) Assess metric measurements against preset expectations Recommendation—use only what you need!

In establishing interface KPIs, there are two basic questions that need to be answered: (1) what is important to the health of our interface management system and (2) how do we know performance is meeting expectations? What is important to the health of our interface management system? An essential characteristic to monitor is interaction between interface parties; specifically, to monitor their effectiveness in planning interfaces—how well the parties align their interface planning dates to reach agreement on individual interfaces, including implementing the agreements; how well they are identifying and resolving important interfaces. How do we know performance is meeting expectations? Whatever KPIs are selected, the performance expectations need to be realistic and achievable. There has to be some consideration for unique circumstances. An all-or-nothing approach is simply not viable nor will it provide true indications of how interfaces are being managed. The all-or-nothing mentality leads to negative mindsets, or worse, finding ways of achieving the metrics that run counter to the purpose for which they were instituted. Setting KPIs with some performance tolerances allows for the unexpected circumstances that will inevitably exist in large-scale complex projects with dynamic project environments. Similar to our vital signs analogy earlier, establish a few KPIs to focus on vital signs. Again, these KPIs are indicators or early warning signs of potential problems in the management system. By collecting data and assessing these metrics regularly, the owner can determine whether performance is outside tolerances and investigate further, which is the intent of all KPIs, including interface KPIs.

6.6.2 ​Interface KPI Examples

While each project will determine the indicators that are essential for measuring their interface performance, most metrics will be based on basic status statistics. As shown earlier, each interface network, shown in Figure 6.4, and interface group within each network, shown in Figure 6.6, will maintain a real-time status summary in the interface register. Meaning, at any time, the process owner will be able to view the current status of all interface items (agreements) between interface groups and within an interface network. The status was shown in Figure 6.6 as 0/0/0/0 which equates to zero identified/open/closed/overdue status at this early stage: • Identified status: This status simply means that an interface party has entered an interface in the interface register. This interface remains in this status until both parties have convened an interface meeting and determined the interface to be valid. If it is valid, then the interface is planned and target dates are entered dates in the interface register for the interface item. If it is not a valid interface, then the item will be deleted from the interface register and noted in the meeting minutes. • Open status: An interface item in this status means that the interface group has determined that an identified item is valid and thus opened in the interface register by determining and entering planning dates to resolve the item. • Closed status: This is the best status for an interface item. This status means that the parties have reached an agreement on how to resolve the interface. Note—each project will need to define the specific conditions under which an item is closed. Some projects will close the

Interface Management Planning

147

item when the agreement is reached, while other projects require the agreement’s implementation to be verified before it is closed. • Overdue status: This status is meant to convey that the planned dates for resolving the interface item and reaching an agreement have passed. This is generally considered to be the least desirable status for an interface item. From these basic status indicators, summary statistics can be derived to show how many interfaces have been raised within an interface group and network and the distribution of their current status conditions. The primary goal of interface management is to identify and resolve each interface as quickly as possible. Thus, these summary statistics can show warning signs of developing problems within an interface group or network. Statistics showing high levels of identified items early in a project or immediately after forming and activating an interface group may be normal, but high levels after the group has been active for a period may indicate lack of activity, group dysfunction, or other problems. Regardless, interfaces in an identified status should be temporary and only between meetings. Statistics showing high levels of overdue interfaces can also be an indication of poor collaboration or planning, changing schedules, and delayed work. While it may be normal for overdue items to become late as a result of holiday periods, this can typically be addressed through the planning process. Thus, high levels of overdue items or any overdue high-priority or high-risk items should be investigated further to understand why this status condition exists.

6.6.3 ​Project Diamond KPIs

In our Project Diamond example, it has been decided to use the three interface KPIs noted in Figure 6.9. While these KPIs focus on identified and overdue interfaces, the reader will notice there are two different metrics for overdue. In Project Diamond, the client (project sponsor) has included a feature to identify high-priority interfaces in the interface register. Given the dynamic environment of the Project Diamond project and the number of different networks and interface groups, the client established this metric to allow the different parties to designate when interfaces, for whatever reason, become time critical. This designation is intended to imply impending negative consequences if the item is not agreed upon and resolved urgently. This metric recognizes, and attempts to account for, the dynamic nature and unpredictability of Project Diamond’s environment. Thus, it aids in focusing management attention on urgent priorities. Figure 6.9 shows the three chosen interface management KPIs, labeled in the # column as IM1, IM2, and IM3, followed by a description of each in the Indicator column, the performance target for each in the KPI column, and a measurement to be assessed for an example week in the Week 37 column. The reader will notice that in the KPI column, performance targets have been set for each

Interface Key Performance Indicator (KPI) #

Indicator

KPI

Week 37

IM1

Overdue "Normal Priority"

DG3)

This phase comprises the work needed to define and detail the selected field development solution and to prepare and issue the PDO documentation including the environmental impact assessment. An important part of the work in this phase is preparation for the execution phase. Issues to be considered include: • Subsurface (from top of well to hydrocarbon reservoir) ▶▶ In this phase, a further improvement of the geological and reservoir simulation model shall take place ▶▶ Detailed drainage strategy shall be described. The following shall be included: ■■ Recovery per well ■■ Integrated well deliverable study including artificial lift and well chemistry management ■■ Water management strategy ■■ Allocation and well testing philosophy ■■ Scale management philosophy ▶▶ Functional requirements for facilities and wells based on subsurface uncertainty assessment (P90 pessimistic assessment case, P50 likely assessment case, and P10 optimistic assessment case) shall be concluded ▶▶ Possible improved oil recovery (IOR) measures shall be described and the potential evaluated; a description of how this potential could be realized with the chosen concept/ strategy shall be included ▶▶ A description on how exploration potential can be implemented in the development plan shall be included • Field development solutions ▶▶ Normally, one field development solution is brought forward in this phase; however, if there are good commercial reasons for maturing alternative development solutions through the FEED phase, this can be performed after approval by the license management committee ▶▶ The principle shall be to keep competition between alternatives as long as possible without compromising the quality of the work; issues which may be important in this respect are availability and commercial terms for the use of third-party facilities for the processing and transportation of products

262

Project Interface Management

▶▶ Update and detail an area development strategy, as seen in the DG2 phase • Drilling and wells ▶▶ Establish a final drilling and well design on an individual well basis, including a plan for execution ▶▶ Establish and dimension a well life-cycle intervention program ▶▶ Update drilling expenditures (DRILLEX) estimates including cost uncertainty analyses ▶▶ Prepare tender for rig and other specified long-lead items • Facilities ▶▶ Implementation of results from site surveys including geotechnical investigations for the design of field installations, including surveys of pipeline routes ▶▶ FEED studies for field installations shall be performed to define the technical basis for further engineering work, and be the basis for tender packages in order to receive firm tenders ▶▶ Update design basis and functional requirements ▶▶ Perform value improvement process ▶▶ Requirements regarding operational regularity, reliability, and availability of essential equipment and systems to be concluded • HSE ▶▶ Detailed HSE assessments of the selected development solution including ALARP (as low as reasonably practicable) and BAT (best available technique) evaluations ▶▶ Prepare and issue environmental impact assessment ▶▶ Total risk analysis ▶▶ Authority applications • Quality ▶▶ Experience transfer ▶▶ Detailed quality planning ▶▶ Independent verification of key project items essential for project execution and project economics ▶▶ Establish project quality system for execution as required ▶▶ Prepare DG3 decision support package ▶▶ Establish project manual with governing documents and system for the execution project • Risk management ▶▶ Risk assessment of the selected development solution and implementation of risk reducing measures • Procurement ▶▶ Award of contracts for FEED studies ▶▶ Prequalification of tenderers for the various contract packages shall be performed in this phase if it is decided that prequalification through the Achilles system is not used ▶▶ Tender packages for major contracts and long-lead items (if relevant) shall be prepared in this phase ▶▶ Firm offers (bids) for the main project building blocks shall be secured before submittal of the PDO ▶▶ If relevant, project sponsor and partners agree on and issue contracts or purchase orders for long-lead items and obtain government approval—in the case of Norway, the Ministry of Petroleum and Energy (MPE)—to allocate funds for these items prior to approval of the formal project application; this reduces impact on schedule while awaiting delivery of such items

Appendix C  ABC Management of Project Development

263

• Commercial—tie-in and processing agreements ▶▶ Fully-termed agreement • Commercial—transportation agreements ▶▶ Gassco architecture study completed and presented to approval authority MPE (Gassco is the system operator for transporting gas from the Norwegian continental shelf to other European countries. The government of Norway oversees Gassco operations and its relationship to transport system owners) ▶▶ Fully-termed agreement for transportation and processing of oil and gas ▶▶ Participant agreement for new joint ventures (e.g. new gas/oil pipelines) • Commercial—unitization ▶▶ Complete unitization agreement • Project control ▶▶ Update WBS ▶▶ Prepare/update execution schedules and master schedules based on project assignment, premises, assumptions, scope of work, and experience ▶▶ Schedules shall be developed for each concept ▶▶ Schedule risk analyses shall be performed ▶▶ Establish cost estimates for CAPEX and OPEX based on case books ▶▶ Cost and schedule risk analysis shall be performed ▶▶ Establish project reserves ▶▶ Prepare work program and budget for the execution project including three years of investment and operation budgets ▶▶ Preparation for project execution by establishing: ■■ Organization charts and manpower plans ■■ Procedures for cost control and cost baseline updates ■■ Procedures for progress reporting and schedule baseline updates ■■ Authority matrix in connection with variation order handling ■■ Project reserve handling

C.4.5 ​Execution Phase (DG3 -> DG4)

The execution phase starts after DG3 when the license has approved the PDO submission. It comprises drilling and completion of production wells and construction, installation, and commissioning of all field installations. Issues to be considered are: • Subsurface—the main activity in this period is to develop the first long-range reservoir management plan based on the PDO. The main elements to be included are: ▶▶ Field overviews and brief reservoir descriptions with references to detailed descriptions ▶▶ Overview of in-place hydrocarbon volumes and associated recoverable volumes including resource classification and uncertainties ▶▶ Data acquisition and reservoir monitoring strategy including plans for mitigating remaining key uncertainties ▶▶ The strategy shall be cross-disciplinary covering all data types relevant for monitoring and further development of the field, including IOR ▶▶ Plans for geophysical reservoir monitoring ▶▶ Production management strategy ▶▶ Long-term water management strategy (including discharge of produced water) ▶▶ Future reservoir development strategies throughout total field life, including specific strategies for IOR

264

Project Interface Management

• •

•

•

• •

• •

•

▶▶ Identification of current and future exploration/business opportunities and their impact on reservoir information needs and reservoir development ▶▶ Long-term production and injection plan, including forecasts of yearly deliveries of oil, gas, and natural gas liquids with uncertainty ranges and assumptions ▶▶ Long-term drilling and well work-over plans ▶▶ Pore pressure development and the impact on future drilling ▶▶ Late field-life considerations Support drilling and wells in detailing the production drilling and completion program Drilling and wells ▶▶ Prepare detailed drilling procedures and main completion program and issue to authorities ▶▶ Prepare individual well programs ▶▶ Start predrilling of production/injection wells Facilities ▶▶ Detailed design ▶▶ Construction and installation of facilities ▶▶ Mechanical completion ▶▶ Commissioning ▶▶ Handover to operations Preparation for operation ▶▶ Establish the organization for operation personnel to project activities as planned; operations personnel shall be involved in precommissioning and commissioning activities ▶▶ Establish document system for life-cycle information (LCI), if required ▶▶ Develop maintenance and inspection programs for equipment, systems, and structures; define and procure all required spare parts and consumables ▶▶ Perform training of operational personnel as required according to authority and internal requirements; participation in project activities is considered an important part of personnel training ▶▶ Execute all other required preparations for facilities start-up (establish agreements/­ contracts required for operation; establish on-shore base functions/agreements, etc.) HSE ▶▶ HSE follow-up on construction sites and installation operations ▶▶ Prepare and issue authority applications Quality ▶▶ Experience transfer ▶▶ Review of contractors’ quality plans ▶▶ Quality follow-up on construction sites Risk management ▶▶ Risk assessments during construction and installation ▶▶ Follow-up implementation of risk-reducing measures Procurement ▶▶ Award of major contracts and purchase orders for field development ▶▶ Contracts and purchase order expediting and follow-up ▶▶ Change order management Project control ▶▶ Update schedules based on project mandate, premises, assumptions, scope of work, and experience ▶▶ The main schedule and detailed schedule shall be frozen and issued as the master control schedule

Appendix C  ABC Management of Project Development

265

• The master control schedule shall be the schedule for project follow-up during execution ▶▶ Schedule and cost risk analyses shall be performed ▶▶ Master control estimate to be established based on FEED information—master control schedule and contingency from risk analyses—project reserves to be defined ▶▶ Project change management process with approved authority matrix for execution shall be established • Commercial ▶▶ Operational type of appendices to be finalized (e.g., metering and allocation)

C.4.6 ​Project Completion and Closing

The project is completed when the project has accomplished delivery of all agreed deliveries; i.e., all facilities, wells, etc., are completed, commissioned, and delivered to operations—including documentation. The project manager is responsible for ensuring that the project closeout is performed according to agreed project procedures. This includes demobilization of project personnel, closeout of contracts and project accounts, filing of project documents, controlled and systematic conveyance of lessons learned, and arranging completion of any remaining work, tasks, and services.

C.5 ​DEFINITIONS Definitions can be found in Table C.1. Table C.1  Definitions for ABC management of project development Asset owner

The asset owner is the person in ABC executive management responsible for managing ABC’s ownership interest in the project/ license.

Benchmarking

Comparison of selected indicators for a project against corresponding indicators for compatible facilities, normalized for relevant parameters, e.g., resource basis, capacities, product(s) etc.

Completion

Completion is a generic term covering mechanical completion, installation, and commissioning.

Decision gate (DG)

A predefined point in the project model where ABC and the license partners have to make appropriate decisions whether to move to the next phase, make a temporary hold, or terminate the project.

FEED (Front-end engineering design)

Equivalent to the term “pre-engineering.”

Life-cycle information (LCI)

Life-cycle information: Information required by the company for engineering, preparation for operations, start-up, operation, maintenance, repair, modification, and decommissioning of an installation. LCI includes both information submitted to the company and retained by the supplier on behalf of the company. LCI includes what has previously been termed documentation for operations (DFO).

Mechanical completion

Mechanical completion of an installation means that the installation is built in accordance with relevant drawings and specifications. All relevant LCI shall be quality checked. All specified tests and inspections are carried out and documented in a uniform way. The installation is ready for handover to Commissioning.

266

Project Interface Management

Project control basis

Plans, estimates, and commercial assumptions that form the basis for control and follow-up of a project in the execution period.

Project manager and project management team

Management group of a project team given the responsibility for planning and realizing an investment project.

Project mandate

Document accepted by the project owner defining the project frame, scope, deliverables, schedule, and budget to the project manager.

Project owner

The project owner is the person in ABC executive management responsible for bringing the project to the next DG.

Project review

A technical and readiness review of the documented decision basis to evaluate whether status/condition in a project is in accordance with ABC requirements at a DG.

Self-assessment

Review performed by the project to confirm that project requirements have been met at defined stages of project planning and execution (DG1, DG2, DG3, DG4).

Stakeholder

Person, group, or authority having an interest in the activities, performance, or success of an organization.

Stakeholder analysis

Method of identifying and evaluating internal and external stakeholders that have an interest in and that can influence the project in a negative or positive direction. Such stakeholders may be owners, authorities, environmental organizations, land-owners, fishermen, internal ABC units, and others. The preparation of strategies with respect to the stakeholders for the different phases of the project is part of the analysis.

Technology qualification program

Document containing activities, acceptance criteria, and DGs needed to qualify new products or new technologies to ensure they are fit for purpose.

Appendix

D

Project Diamond Mandate for Execution Phase This project mandate document covers the responsibilities for the execution of Project Diamond with regard to: • • • • • • •

Objectives Governance requirements Success factors Principal scope of work Main deliverables Key milestones Organization

D.1 ​PROJECT OWNERS The Senior VP–Projects is the project owner and has the overall responsibility for Project Diamond. The daily planning and running of the project activities is assigned to the project director in close cooperation with the project management team. This version of the document covers the period between two specific decision gates (DGs): DG3 approval and the DG4 milestone.

D.2 ​PROJECT OVERVIEW Project Diamond encompasses a 20 km area within the DL 0072 and DL 0046 development licenses. ABC Corporation (65%) is the operator for the Diamond Project, while TDN, Inc. (25%) and Waverly Exploration (10%) are partners. This project mandate document covers the development of Project Diamond with a fixed offshore platform, pdQ (partly processing, drilling, and quarters), and with a subsea development to transfer the Project Diamond wells stream to the Project Sapphire platform for final processing and export of stabilized oil and rich gas.

267

268

Project Interface Management

D.3 ​OBJECTIVES AND SUCCESS FACTORS FOR PROJECT DIAMOND D.3.1 ​Business Objectives

• Develop the resources in the Project Diamond field in accordance with the scope and framing defined by the Project Diamond plan for development and operation (PDO)

D.3.2 ​Project Objectives

• Execute the project in accordance with national laws and regulations • Execute the project according to health, safety, and environmental (HSE) and quality objectives • Deliver first oil October 1, 20xx • Enable a first year Project Diamond injection and production regularity of 96.6% • Execute the approved project scope within the overall and approved execution budget and schedule • Plan, develop, manage, and document the project activities according to ABC Corporation’s governing documents • Deliver the facilities at DG4 that can be operated according to design-basis requirements and functional requirements • Prepare for operation so that the facility may be put straight into operation at DG4 with all personnel and operating procedures in place

D.3.3 ​Project Success Factors

The following success factors have been identified for the project execution phase: • Strong HSE commitment within the project management team, zero target • Utilize best business practice to achieve a safe, aligned, predictable, and cost-effective project delivery; lessons learned; and benchmarking from similar projects • Experienced, competent, and sufficient internal and external resources • Motivated team, aligned with common goals • No change philosophy • Proactive interface, risk, and contract management • Integrated team execution model; build team culture

D.3.4 ​Project Priorities The project priorities shall be 1. 2. 3. 4.

HSE Quality Schedule Cost

These priorities thus support the optimized net present value of the project.

Appendix D  Project Diamond Mandate for Execution Phase

269

D.4 ​GOVERNING DOCUMENTS The main documents governing Project Diamond are listed hierarchically as follows: 1. 2. 3. 4. 5.

National laws and regulations Joint operating agreement and PDO ABC management system Project mandate and project execution and overall procurement strategy HSE program, design basis, functional requirements, and project-specific processes and procedures 6. Technical and contractual requirements 7. Standards and guidelines

D.5 ​PROJECT EXECUTION FRAMING DOCUMENTS The key documents for execution of the project are: • • • • • • • • • • • • • • • • •

Project design basis Project functional requirements Project concept selection report Case books and economy analysis for DG3 Master control estimate and schedule for the project execution phase Project execution work breakdown structure Project organization charts for project execution HSE strategies and HSE program Risk management plan, risk summary, and mitigation plans Interface management and control plan Quality control plan Front-end engineering design reports for Topside, Jacket, and subsurface umbilical, risers, and flowlines (SURF) Recommendation on contracts for Topside, Jacket, and SURF Recommendation on contract for transport and installation Long-lead item list and purchase order status Commercial agreements, such as nonbinding Heads of Agreements with potential buyers at DG3 with third party for oil and gas export (commercial) Conditions for governmental approval of the PDO

D.6 ​PROJECT ORGANIZATION The Project Diamond organization for the execution phase, reflecting the integrated team philosophy, is shown in Figure D.1. The asset owner for the Project Diamond development is the COO. The asset owner is responsible for planning and stewarding the license activities and for securing the coordination with the Project Diamond partners, the Ministries, and the Petroleum Directorate (PD). The project owner for the Project Diamond development is the Senior VP–Projects. The Project Diamond director (project manager) is responsible for delivering Project Diamond from DG3 (sanction) into DG4 (the production phase) and together with the integrated Project Diamond team by: • Ensuring optimization of Project Diamond value throughout the duration of the development

270

Project Interface Management

• Ensuring that the field’s development plan is clearly outlined and communicated to all stakeholders • Making sure all the key objectives and drivers are clearly communicated and understood by the Project Diamond team and other stakeholders • Ensuring that the Project Diamond team is focused on a timely delivery of the project planned milestones in an effective and efficient manner while adhering to safety and environmental goals of the ABC Corporation

ABC Executive Management

Asset Owner (COO)

Project Owner (SVP-Projects)

License Management Committee

ABC Steering Committee

Project Manager

Project Control

Project Support

Contract/ Procurement

HSE

Commercial

Quality

Subsurface

Drilling & Wells

Facilities

Figure D.1  Project Diamond organization for execution phase

Preparation for Operation

Appendix D  Project Diamond Mandate for Execution Phase

271

• Making sure that a continuous improvement process is applied using an integrated discipline approach to reduce and manage project uncertainties • Ensuring that a risk management and contingency planning system is in place and updated on a continuous basis • Making certain that preparation for operation is conducted such that the facility may be put straight into operation at DG4 with all personnel and operating procedures in place • Exercising strict project control with respect to actual and planned budgets, schedule planning, and product quality • Overseeing selection and training of employees to meet project and operations milestones • Overseeing planning and updating of long-term production capacity, capital investments, and long-term drilling

D.7 ​STAKEHOLDER MANAGEMENT A separate stakeholder management plan has been developed. In addition, responsibility for external communication with investors/media and other interested parties rests with the investor relations manager and the communication manager.

D.8 ​INTERFACES The Project Diamond operational concept is illustrated in Figure D.2. As an offshore partial-production facility, Project Diamond will recover hydrocarbons, process out bulk water, and export its hydrocarbons to Project Sapphire for further processing through the oil pipeline project and gas pipeline projects to onshore facilities and markets. Project Diamond must coordinate activity to tiein physically to Project Sapphire and ensure its pipeline and hydrocarbon compositions meet export requirements by the various pipeline projects. In addition, Project Diamond will receive 110 kV power (to power the Project Diamond offshore facility) through a subsea power cable. This power cable also includes two fiber cables so that Project Diamond and Project Sapphire can operate safely and manage combined production, and finally, to help Project Diamond start wells and maintain reservoir pressure and gas lift (which is used to aid in Project Diamond’s production process). In addition, Project Diamond has undertaken a complicated contract strategy to deliver its project, which is illustrated in Figure D.3. This contract strategy creates several interfaces between main entities that are delivering products and services to Project Diamond.

Figure D.2  Project Diamond operational concept

Commissioning

Installation and Hook-up

Transportation and Heavy Lift

EPC

FEED

NA

Reimbursable

Rig Contract

NA

NA

Reimbursable and Lump Sums

Service and equipment contracts

Reimbursable

Lump sum and Reimbursable

EPCI

FEED contract Reimbursable

Concept study contract

ABC Corporaon

Reimbursable

Norms and rates for construction. Target sum for engineering & procurement Lump Sum for preliminaries and Living Quarter

EPC

FEED contract Reimbursable

Study contract

Study contracts as relevant

pdQ Topside

Concept Development

Services & equipment

Subsea Flowlines and Power Cables ABC Corporaon

Drilling

Project Management

Rig

Figure D.3  Project Diamond contract strategy

DG4

DG3

DG2

Diamond Project “Phases”

NA

EPCI Lump Sum

EPC Lump sum

FEED Contract Reimbursable

Study contract

Jacket

NA

NA

EPCI Lump sum

Study Contract under Topside FEED

Transportation and Installation

NA

Flotel Contract Reimbursable

NA

Flotel

272 Project Interface Management

Appendix

E

Project Diamond Execution Plan This appendix contains the sample Project Diamond execution plan that governs the project during execution after decision gate (DG) 3 and up to DG4.

E.1 ​INTRODUCTION TO THE DIAMOND PROJECT EXECUTION PLAN FOR DG3 TO DG4 E.1.1 ​Purpose

The purpose of this document is to outline how Project Diamond is planned to be executed from DG3 to DG4. This document describes project targets, strategies, and the management and control systems established to meet the project objectives within the given project framework. The project execution plan (PEP) is a part of the project governing documents for Project Diamond. The document outlines the most important elements in the project execution phase, along with how the project intends to handle these in order to achieve a timely, cost effective, and safe development of the project.

E.1.2 ​Responsibility

In the sample organization, the field director is responsible for the preparation and maintenance of the PEP with support from relevant representatives in the project team. The field director is also in charge of the facility and the 500-meter zone around the facility. This includes operations, resupply, helicopter operations, and transiting in and out of the surrounding safety zone. The PEP is approved by the Project Diamond owner/director. In the sample organization, the project director is also the Senior VP–Projects, to whom the project manager reports.

E.1.3 ​Governing Documents

The Project Diamond governing documents are listed hierarchically as follows: • • • •

National laws and regulations Joint operating agreement and plan for development and operation (PDO) ABC Corporation management system Project Diamond mandate and PEP 273

274

Project Interface Management

• Project Diamond health, safety, and environmental (HSE) program, design basis, functional requirements, and project specific processes and procedures • Project technical and contractual requirements • Project standards and guidelines

E.1.4 ​Definitions and Abbreviations CAPEX CCE CCS CRA DG DRILLEX EIA EPC FEED HAZID HAZOP HSE HUC KPI LCI LoI MC MCE MCS OPEX PDO pdQ PEP PEOPS VO VOR

capital expenditure current control estimate current control schedule cost risk analysis decision gate drilling expenditure environmental impact assessment engineering, procurement, and construction front-end engineering design hazard identification study hazard and operability analysis health, safety, and environmental hook-up and commissioning key performance indicator life-cycle information letter of intent management committee master control estimate master control schedule operational expenditure plan for development and operation partial processing, drilling, and living quarters [platform] project execution plan project execution and overall procurement strategy variation order variation order request

E.2 ​PROJECT OVERVIEW E.2.1 ​Description of the Project

Project Diamond encompasses a 20 km area within the DL 0072 and DL 0046 development licenses. The development license is an authorization from the government that allows an entity the access rights to a specific and defined area for developing hydrocarbon resources. The percentage of ownership is mandated by the government as part of licensing rounds conducted by the government’s petroleum directorate. Development licenses describe, govern, and specify the percentage of interest to each licensed firm. ABC Corporation (65%) is the operator for Project Diamond, while TDN, Inc. (25%) and Waverly Exploration (10%) are partners.

Appendix E  Project Diamond Execution Plan

275

ABC’s main business objective for Project Diamond is to develop the resources in the DL 0072 and 0046 license fields in accordance with the scope and framing defined by the Diamond PDO. The reserves are estimated to be 280 million barrels of oil equivalent (BOE). BOE is a measure to quantify crude oil, natural gas liquids, and natural gas amount using the same metric to determine the amount of energy available to a firm. The development is based on a pdQ platform. The wells on Project Diamond will be drilled by a jackup rig (self-elevating hull with legs) from the pdQ. In order to tie-back to future third-party fields, the pdQ will be equipped with spare J-tubes. (Tiebacks are additional risers that are connected to the original platform. They allow drilling of surrounding marginal fields in addition to the main field, without the significant investment required for the main platform. Risers are subsea pipelines used to transport produced hydrocarbons and other materials. J-tubes are conduits for risers.) Diamond is coordinated with the Sapphire development with partial processing on Diamond (first-stage separation and injection of water) and final processing on Sapphire. The wells are drilled by a jack-up rig. Diamond’s integration with the Sapphire pdQ is outlined below:

E.2.1.1 ​Diamond • • • •

A 20-slot wellbay area First-stage separation at Diamond Boosting of oil and gas streams at Diamond before they are co-mingled and sent to Sapphire Treatment of produced water and reinjection of produced water mixed with sea water at Diamond

E.2.1.2 ​Sapphire

• Pressurized gas for gas lift and electric power from Sapphire to Diamond • The oil will be exported from Sapphire through the Oil Pipeline Project and further on to the onshore terminal system for processing • The gas will be exported from Sapphire through the Gas Pipeline Project to onshore terminal facilities for further processing and transport to market

E.2.2 ​Background

The Diamond and Sapphire license groups signed an agreement for a coordinated development of the field in March 20xx. This implied a pdQ at the Diamond field center with final processing of the dewatered hydrocarbon fluids on Sapphire before exporting the combined hydrocarbon stream (combined oil and gas, minus the water) onshore to processing terminals. In March 20xx, the Diamond license group gave the Diamond operator (ABC Corp.) approval to start FEED studies for pdQ topside, jacket, and pipelines. Further, the management committee approved the Diamond project DG2 work (define) leading toward a DG3/PDO decision (execute). Evaluations and FEED studies were performed for nearly one year to ascertain the best option to develop discoveries in the license area. These studies led to the development and submission of the PDO, which was submitted to the government for approval. Based on recent approval of the PDO by the government, the execution phase of Project Diamond will commence with an estimated project development cycle of five years and an operational life of 25 years. A conceptual rendering of the entire field development is provided in Figure E.1.

276

Project Interface Management

Figure E.1  Conceptual illustration of Project Diamond and Project Sapphire field development

E.3 ​PROJECT DEVELOPMENT PLAN AND CONTRACT STRATEGY Project Diamond will utilize a contract strategy that maximizes expertise in the marketplace while providing best value to the sponsoring organization. Accordingly, the project has been segmented to deliver the offshore facilities. Major contract components include: Topside, Living Quarters (LQ), Jacket, Subsea, and Drilling and Wells (D&W). Figure E.2 conceptually illustrates the major systems comprising Project Diamond.

Figure E.2  Conceptual illustration of Project Diamond major subprojects

Appendix E  Project Diamond Execution Plan

277

E.3.1 ​Topside EPC

The Topside facility provides the main function of recovery of hydrocarbons from the reservoir— partially processing the hydrocarbons to remove water content and transferring the partially processed hydrocarbons to Project Sapphire through pipelines. This contract includes all work necessary to design, procure, and construct the Topside facility, consisting of the utility module, processing module, wellbay module, and flare boom. In addition, the Topside EPC will be responsible for system technical integrity—that is, the integrity of the entire system comprising Project Diamond—and will ensure standardization and alignment across the entire project.

E.3.2 ​LQ EPC

The LQ is the part of the facility that will provide accommodation, food, recreation, and utility services to personnel to support a comfortable habitat for personnel performing work on the facility. The LQ EPC contract will include all work necessary to design, procure, and construct the living quarters to house facility personnel during operations. The LQ EPC contract will also include a helipad to support helicopter operations to and from the LQ.

E.3.3 ​Jacket EPC

The Project Diamond jacket will be a steel support structure that provides support for the offshore facility. Steel jackets are vertical sections made of tubular steel members that will be piled into the seabed. The Jacket EPC contract will include work necessary to design, procure, and construct the jacket.

E.3.4 ​Subsea Engineering, Procurement, Construction, and Installation (EPCI)

Project Diamond must send its partially processed hydrocarbons to Project Sapphire for further processing and transport to onshore processing facilities. Transfer of Project Diamond’s hydrocarbons will be accomplished through subsea pipelines connected to both projects. The Subsea EPCI will include all work necessary to design, procure, construct, and install the pipeline between the Diamond and Sapphire projects (estimated to be 10.3 kilometers in length).

E.3.5 ​Transportation and Installation (T&I)

A separate contract will be established for T&I of the Topside modules, LQ, and Jacket from their construction locations to the offshore installation location and include the scope needed to install the Topside, LQ, and Jacket systems and modules offshore. This contract will include all work necessary to design for transportation including all lifting, loading, and securing for transport.

E.3.6 ​D&W

The D&W department is an ABC Corporation organizational asset and will manage the D&W subproject. As a result, the D&W department will contract for all hardware, services, and support required for drilling and completing wells for the Diamond project. D&W contracts will be managed by the D&W department, but their contractors need to interface with Project Diamond to ensure physical, logical, and functional alignment during project integration.

278

Project Interface Management

E.3.7 ​Project Diamond Completion Team

ABC Corporation takes responsibility for completion of the offshore facility. Completion is defined to mean physical hook-up between various components after installation. After hook-up is completed, the facility will undergo system validation as part of the commissioning process. Commissioning ensures that the facility is ready to deliver required system functionality. Upon successful commissioning, the facility will be turned over to the Diamond operations group who will be responsible for starting up and operating the facility.

E.4 ​PROJECT EXECUTION PLAN E.4.1 ​Project Execution Principles

In order to meet the project objectives and secure the project execution phase, ABC Corporation applies the following project execution principles. The project priorities are: • • • •

HSE Quality Schedule Cost

E.4.1.1 ​HSE Principles • • • •

Clear HSE commitment from project management and throughout the project organization Clear HSE commitment from contractors and suppliers Adherence to Project Diamond’s overall HSE program Ensure that HSE issues are addressed both in design and execution

E.4.1.2 ​Quality Management Principles

• Ensure high-quality performance in the execution phase by following ABC Corporation’s project quality management system • Ensure a well-functioning change control system • Further develop and follow the risk management system to reduce, mitigate, and eliminate potential project execution risks • Establish reporting routines satisfying the requirements set down by the authorities, license agreements, and ABC Corporation’s internal requirements

E.4.1.3 ​Schedule Principles

• Early placement of LoI for major contracts • Identify need and place order(s) for long-lead items (LLI) early in order to secure project execution schedule • Arrange for float in the execution schedules to secure a robust plan • Minimize carryover scope from onshore to offshore (Carryover work is work that was planned to be conducted onshore, but was not completed and is thus rescheduled as offshore work. Onshore work is generally faster and less expensive than offshore work—thus the need to minimize carryover work.)

Appendix E  Project Diamond Execution Plan

279

E.4.1.4 ​Commercial Principles

• A thorough prequalification and tender evaluation process for all major contracts was carried out by ABC Corporation • International competition for all major contracts • Balanced compensation strategy; ABC Corporation to take risk on scope and contractors to take risk on productivity • Apply well-known technology • Attention to life-cycle costs toward contractors and subcontractors • Front-end loading of design activities and thereby optimize maturity of design and minimize changes during execution • Close follow-up with selected vendors to achieve defined quality of the product, documentation, and schedule • Strict management of change process • High commercial awareness during project execution including development of commercial follow-up strategies for all subprojects • Introduce incentives to contractors in order to achieve first oil

E.4.1.5 ​Organizational Principles

• Employ experienced ABC Corporation project teams for controlling and monitoring the EPC contractors during the execution phase • ABC Corporation project teams are to be integrated with their respective contractor teams, even collocated, in order to secure alignment and good communication • Employ highly qualified and motivated project team members in all phases of the project • Utilize consultants where ABC Corporation needs additional resources • Key operation personnel to be included in the execution team in order to secure operational requirements into the design/execution • Ensure cultural understanding as well as experience from multidiscipline projects and operation experienced • Continuity advantages will be ensured by transferring personnel that have been involved during the DG2/FEED phase into the execution phase, including hook-up and commissioning

E.4.2 ​Project Success Factors • • • • • •

Strong HSE commitment within the project management team Utilize best industry practice through lessons learned and benchmarking Experienced, competent, and sufficient internal and external resources No-change philosophy Integrated team execution model Proactive collaboration with EPC contractors to meet project milestones

E.5 ​PROJECT ORGANIZATION AND RESOURCES E.5.1 ​Project Governance

Project Diamond will closely adhere to ABC’s governing documents and the governance system established for the project. The Project Diamond owner/director from DG3 to DG4 is the Senior VP–Projects. The project owner is responsible for contributing to alignment internally and with the Project Diamond partners and key external stakeholders (e.g., the Ministry of Petroleum and

280

Project Interface Management

Energy and the Petroleum Directorate). On behalf of the CEO, the project owner is responsible for ensuring that ABC’s values are maintained and that the project’s business objectives are met. The project director is responsible for completing the project from DG3 to handover to operations at DG4 according to the approved PDO, project mandate, and the Diamond authority procedure. The responsibility is governed by the Project Diamond mandate. Change management is strict to prevent delays in first production. A strict management of change process is applied in the project in order to secure first oil at the earliest possible date.

E.5.2 ​Project Organization

The project director is responsible for adequate manning of the project organization with competent resources, ensuring that the project can be executed as agreed within the approved baseline cost and schedule.

E.5.3 ​Key Roles and Responsibilities

The upcoming subsections describe the principal roles in the project management team’s organization and their main responsibilities.

E.5.3.1 ​Project Director

Has overall responsibility for execution of the project according to approved plans and governing documents. This position is also directly responsible for facilities (the entire offshore platform), including Topside, Jacket, Subsea, completion, and T&I.

E.5.3.2 ​Field Director

Has overall responsibility for the field preparations including the Petroleum Technology (PETEK) department, the D&W department, operations, and coordination with Project Sapphire. The field director and the project director share responsibility for effective project execution.

E.5.3.3 ​Subproject Teams

Each subproject (Topside, Jacket, LQ, Subsea) will be managed by a subproject team representing the project sponsoring organization, ABC Corporation. Their responsibilities include: • • • • • •

Delivery of the subproject scope of work within the agreed quality, cost, and time HSE for subproject Lead and manage the subproject team Manage resources allocated to the project Report cost, progress, and any areas of concern Contribute to good cooperation and communication between project team members

E.5.3.4  PETEK Department

• Prepare and be ready for operational phase • Document the resource basis (for the project and for the area) including uncertainties • Develop and update geological model(s) and dynamic reservoir assessments including uncertainties • Establish reservoir development solutions with production strategy and production/injection forecasts including uncertainties • Develop and update data acquisition strategy

Appendix E  Project Diamond Execution Plan

281

E.5.3.5 ​D&W Department

• Prepare and be ready for operational phase • Develop and update well design for optimum production performance, reflecting reservoir uncertainties • Develop and update well cost estimates • Plan and perform safe and efficient D&W operations • Secure control of the interfaces toward other disciplines • Develop optimum execution schedules with regard to preparation and actual drilling and completion operations • Follow-up construction of jack-up rig

E.5.3.6 ​Facility Operations • • • •

Prepare and be ready for operational phase Establish onshore and offshore organization of operation and maintenance Establish systems for operations and maintenance Support engineering, procurement, and commissioning with operation personnel

E.5.3.7 ​Project License and Support

• Ensure that all necessary actions with Project Sapphire are handled in a timely manner • Secure Project Diamond’s interests in the coordination, development, and operational agreement with Project Sapphire (XYZ Corporation) • Contribute to good cooperation and communication with XYZ Corporation (Project Sapphire) • Handle day-to-day license issues

E.5.3.8 ​HSE Department • • • • •

Identification of applicable legislation, regulations, and codes Establishment, implementation, and follow-up of the HSE Management Systems Provision of HSE program HSE audits and surveillance of the performing organizations Identification of nonconformities to HSE and closure of corrective actions

E.5.3.9 ​Qff ice of Administration/Information Management/Risk • • • • • •

Establishment, implementation, and follow-up of the project management system Project audit and verification plans Project risk register Project manual (on intranet) Information processes Procurement of information and communications technology (ICT) systems for operations (those who will take custody of the platform and operate it)

E.5.3.10 ​Project Control • • • • • •

Establishment and implementation of best practices, methods, and systems for project control Estimating, cost control, and reporting Planning and progress reporting Budget and schedule updates and forecasting Monthly status reporting Project change management

282

Project Interface Management

E.5.3.11 ​Procurement, Contracts, and Logistics • • • • • • • •

Overall contract strategy Specific contract strategies and prequalification of bidders Contract and procurement plans Competitive tendering Issues invitations to tender and performs bid evaluation and negotiations Purchase order (PO) preparations PO administration Review of correspondence with contractors—monitor EPC contractors and follow-up of critical subcontractors • Implement, as needed, incentive programs on subcontractor level • Insurance and guarantee handling • Systems and methods for logistics

E.5.3.12 ​Human Resources

• Recruitment of permanent staff and the hiring of consultants • Establishing competency requirements and a training plan for offshore personnel as part of PEOPS • Ensuring that local administrative standards are in place at each site regulating administrative-­ and personnel-related issues for expatriate personnel • Contact person toward suppliers with regards to hiring of consultants • Relocation of personnel and, if applicable, their families

E.5.3.13 ​Marine Coordinator

• Acquire and manage all necessary permissions for marine operations • Coordinate all vessel movements and maintain marine calendar and weekly planning during offshore completion operations toward the end of project execution • Solve marine operations interface issues, monitor vessel schedules, and act as general advisor in marine operations (such as when multiple ships are operating in the same area at the same time) • Advise and recommend priorities among different activities offshore

E.5.4 ​Stakeholders

The project will perform stakeholder analysis to identify relevant stakeholder needs and requirements and develop a communication plan to address stakeholder concerns. The purpose of the stakeholder management plan documents is to contribute to a systematic, effective, and well-­coordinated dialogue with Project Diamond stakeholders.

E.6 ​PROJECT STRATEGY, MANAGEMENT, AND CONTROL E.6.1 ​Project Management

ABC Corporation’s execution model is based on an integrated team. This will ensure the quality of the overall project and ensure a seamless transition from project to operation. ABC Corporation is managing the project from its headquarters in London, United Kingdom. In addition, ABC will establish local project offices at contractors’ offices to manage the work on a daily basis.

Appendix E  Project Diamond Execution Plan

283

ABC will control Project Diamond activities by: • Ensuring a high standard of quality, health, safety, and environment throughout the project implementation and at all project locations • Ensuring that the project delivers on budget and schedule and with the right quality • Ensuring that project deliverables meet the requirements of international laws and regulations as well as ABC’s own requirements ABC Corporation will, in general, seek to reduce risks and in particular interface management risk to reduce/limit the project’s exposure. The project has implemented a project information management system (PIMS) for project monitoring and reporting.

E.6.2 ​Interface Management

Interface management will be performed according to the Project Diamond interface management procedure. ABC Corporation maintains overall responsibility for ensuring that interface management is being performed effectively in Project Diamond while contractors are responsible for managing interfaces within their scope of work and interfaces with other contractors. Unless specified by ABC Corporation, contractors will use their respective interface management systems to manage interfaces within their scope of work to their subcontractors, suppliers, and vendors. During the project execution phase, the Topside EPC contractor will have the primary lead interface coordination responsibility toward other execution phase contractors. Lead interface coordination responsibility for interface groups not involving the Topside EPC is designated by ABC Corporation in the interface management procedure. ABC Corporation internal interfaces and all formal interface requirements between ABC subproject teams will also be managed through the interface management system; this system will provide a formal communication channel to all other ABC teams to transmit/receive/process internal interface requirements. Interfaces shall be managed in the interface procedure in accordance with the following principles: • ABC has the overall project interface responsibility and will be headed by an ABC interface function in the project • ABC Corporation representatives shall be invited to all interface meetings and receive copies of all interface correspondence • Topside EPC contractor shall be the lead interface coordinator toward the other main contractors • Interface issues shall be resolved directly between the interface parties at the relevant level in the organization • All interface information between contractors shall be documented and continuously updated as a best practice within interface management • Each interface party is responsible for ensuring that required interface information is made available with sufficient detail and in accordance with an agreed upon schedule • All interface parties shall establish an interface coordinator position • All interfaces and agreements shall be documented in the interface register • Interface responsibilities will be clearly defined in each of the EPC contracts

E.6.3 ​Information Management

Information management includes all activities and systems related to information transfer, including document control and LCI. The project managers are responsible for supplying information according to project requirements, and the information management team is responsible for

284

Project Interface Management

establishing systems and procedures and supporting the organization in using them. Interface documentation needed to support scopes of work and areas of responsibility shall be identified as part of the initial interface group kick-off meeting through an exchange of Master Document Registers (MDRs). Each contract contains a list of document deliverables. These are listed in an MDR that is included in the contract. These documents shall be identified and flagged within respective document control and distribution systems to ensure that interface parties receive the latest revision of interface documents.

E.6.4 ​Document Control

The client and each contractor maintains a document control system at the kick-off meeting, each contractor provides their MDR to each of the interface parties to review and vice versa. Each interface group reviews the other’s MDR to identify documents they need to support their scope of work. For document control, each document on the contractors’ MDR is delivered to the client via a document control system to show formal delivery of the document to the client. In addition, because many documents undergo numerous revisions, the contractor sends the document to each of the relevant interface parties.

Appendix

F

Project Diamond DG3 Interface Control Document

F.1 ​INTRODUCTION This document represents the interface control document (ICD) for Project Diamond.

F.1.1 ​Purpose

This interface control document describes and tracks the necessary information required to effectively define the Project Diamond system’s interfaces as well as any rules for communicating with them in order to give the development team guidance on the architecture of the system to be developed. The purpose of this ICD is to illustrate and describe primary hardware, software/logic, and mass (oil, gas, water, etc.) interfaces between Project Diamond and Project Sapphire and define the high-level internal interfaces between the various project scopes of work. This ICD was created during the conceptual engineering front-end engineering design (FEED) phase and approved as part of the DG3 process. Its intended audience is Project Sapphire, along with the entire Project Diamond team including the project manager, project team, development team, and stakeholders interested in interfacing with the system. This ICD has been developed by ABC Corporation and devised in alignment with the conceptual design for the Diamond system and the project’s approach for development of Project Diamond to ensure the main interfaces. Accordingly, the ICD serves as the documented interface baseline between the two projects and between the various parties contributing to Project Diamond’s development.

F.1.2 ​Responsibility

In the sample organization, the Project Diamond interface manager is responsible for the preparation and maintenance of the ICD with support from relevant technical, commercial, and management representatives in the project organization.

285

286

Project Interface Management

F.1.3 ​Governing Documents

The Project Diamond governing documents are listed hierarchically as follows: • • • • •

National laws and regulations Joint operating agreement and plan for development and operation (PDO) ABC Corporation management system Project Diamond mandate and project execution plan (PEP) Project Diamond health, safety, and environmental (HSE) program, design basis, functional requirements, and project specific processes and procedures • Project technical and contractual requirements • Project standards and guidelines

F.1.4 ​Definitions and Abbreviations CAPEX CCE CCS CRA DG DRILLEX EIA EPC FEED HAZID HAZOP HSE HUC KPI LCI LoI MC MCE MCS OPEX PDO pdQ PEP PEOPS VO VOR

capital expenditure current control estimate current control schedule cost risk analysis decision gate drilling expenditure environmental impact assessment engineering, procurement, and construction front-end engineering design hazard identification study hazard and operability analysis health, safety, and environmental hook-up and commissioning key performance indicator life-cycle information letter of intent management committee master control estimate master control schedule operational expenditure plan for development and operation partial processing, drilling, and living quarter [platform] project execution plan project execution and overall procurement strategy variation order variation order request

F.2 ​PROJECT OVERVIEW Project Diamond is an offshore oil and gas processing facility, which is to be developed and operated by ABC Corporation. Project Diamond will recover hydrocarbons, process hydrocarbons on the facility by removing water, and then export the hydrocarbons to Project Sapphire for further processing. Project Sapphire is a separate independent offshore oil and gas processing facility project being developed by XYZ Corporation. In addition to recovering, processing, and exporting hydrocarbons

Appendix F  Project Diamond DG3 Interface Control Document

287

Figure F.1  Conceptual illustration of Project Diamond and Project Sapphire field development

within their licensee area, Project Sapphire will also receive Project Diamond’s hydrocarbons, further process the hydrocarbons, combine with the Project Sapphire stream, and export to the market via the Project Gas and Project Oil Pipelines. A conceptual rendering of the entire field development is provided in Figure F.1.

F.2.1 ​Description of the Project

Project Diamond encompasses a 20 km area within the DL 0072 and DL 0046 development licenses. The development license is an authorization from the government that allows an entity the access rights to a specific and defined area for developing hydrocarbon resources. The percentage of ownership is mandated by the government as part of licensing rounds conducted by the government’s petroleum directorate. Development licenses describe, govern, and specify the percentage of interest to each licensed firm. ABC Corporation (65%) is the operator for Project Diamond, while TDN, Inc. (25%) and Waverly Exploration (10%) are partners. ABC’s main business objective for Project Diamond is to develop the resources in the DL 0072 and 0046 license fields in accordance with the scope and framing defined by the Diamond PDO. The reserves are estimated to be 280 million barrels of oil equivalent (BOE). BOE is a measure to quantify crude oil, natural gas liquids, and natural gas amount using the same metric to determine the amount of energy available to a firm. The development is based on a pdQ platform. The wells on Project Diamond will be drilled by a jackup rig (self-elevating hull with legs) from the pdQ. In order to tie-back to future third-party fields, the pdQ will be equipped with spare J-tubes. (Tiebacks are additional risers that are connected to the original platform. They allow drilling of surrounding marginal fields in addition to the main field, without the significant investment required for the main platform. Risers are subsea pipelines used to transport produced hydrocarbons and other materials. J-tubes are conduits for risers.) Diamond is coordinated with the Sapphire development with partial processing on Diamond (first-stage separation and injection of water) and final processing on Sapphire. The wells are drilled by a jack-up rig. Diamond’s integration with the Sapphire pdQ is outlined here.

F.2.1.1 ​Diamond

• A 20-slot wellbay area • First-stage separation at Diamond • Boosting of oil and gas streams at Diamond before they are comingled and sent to Sapphire

288

Project Interface Management

• Treatment of produced water and reinjection of produced water mixed with sea water at Diamond

F.2.1.2 ​Sapphire

• Pressurized gas for gas lift and electric power from Sapphire to Diamond • The oil will be exported from Sapphire through the Oil Pipeline Project and further on to the onshore terminal system for processing • The gas will be exported from Sapphire through the Gas Pipeline Project to onshore terminal facilities for further processing and transport to market

F.2.2 ​Background

The Diamond and Sapphire license groups signed an agreement for a coordinated development of the field in March 20xx. This implied a pdQ at the Diamond field center with final processing of the dewatered hydrocarbon fluids on Sapphire before exporting the combined hydrocarbon stream (combined oil and gas, minus the water) onshore to processing terminals. In March 20xx, the Diamond license group gave the Diamond operator (ABC Corp.) approval to start conceptual design FEED studies for pdQ topside, jacket, and pipelines. Further, the management committee approved the Diamond project DG2 work (define) leading toward a DG3/PDO decision (execute). Evaluations and concept FEED studies were performed for nearly one year to ascertain the best option to develop discoveries in the license area. These studies led to the development and submission of the PDO, which was submitted to the government for approval. Based on recent approval of the PDO by the government, the execution phase of Project Diamond will commence with an estimated project development cycle of five years and an operational life of 25 years.

F.3 ​PROJECT DEVELOPMENT PLAN F.3.1 ​Contract Strategy

Project Diamond will utilize a contract strategy that maximizes expertise in the marketplace while providing best value to the sponsoring organization. Accordingly, the project has been segmented to deliver the offshore facilities. Major contract components include: Topside, Living Quarters (LQ), Jacket, Subsea, and Drilling and Wells (D&W). Figure F.2 conceptually illustrates the major systems comprising Project Diamond.

F.3.1.1 ​Topside EPC

The Topside facility provides the main function of recovery of hydrocarbons from the reservoir—­ partially processing the hydrocarbons to remove water content and transferring the partially processed hydrocarbons to Project Sapphire through pipelines. This contract includes all work necessary to design, procure, and construct the Topside facility, consisting of the utility module, processing module, wellbay module, and flare boom: • Utility module: is designed to provide water (potable), air, and electrical services across the facility (platform) • Processing module: contains all equipment necessary to recover, process out water from the hydrocarbons, and export the fluids to Project Sapphire • Wellbay module: contains the central location for drilling production wells • Flare boom: is used to burn off unneeded or small amounts of natural gas

Appendix F  Project Diamond DG3 Interface Control Document

289

Figure F.2  Conceptual illustration of project Diamond major subprojects

In addition, the Topside EPC will be responsible for system technical integrity—that is, the integrity of the entire system comprising Project Diamond—and will ensure standardization and alignment across the entire project.

F.3.1.2 ​LQ EPC

The LQ is the part of the facility that will provide accommodation, food, recreation, and utility services to personnel to support a comfortable habitat for personnel performing work on the facility. The LQ EPC contract will include all work necessary to design, procure, and construct the living quarters to house facility personnel during operations. The LQ EPC contract will also include a helipad to support helicopter operations to and from the LQ.

F.3.1.3 ​Jacket EPC

The Project Diamond jacket will be a steel support structure that provides support for the offshore facility. Steel jackets are vertical sections made of tubular steel members that will be piled into the seabed. The Jacket EPC contract will include work necessary to design, procure, and construct the jacket.

F.3.1.4 ​Subsea Engineering, Procurement, Construction, and Installation (EPCI)

Project Diamond must send its partially processed hydrocarbons to Project Sapphire for further processing and transport to onshore processing facilities. Transfer of Project Diamond’s hydrocarbons will be accomplished through subsea pipelines connected to both projects. The Subsea EPCI will include all work necessary to design, procure, construct, and install the pipeline between the Diamond and Sapphire projects (estimated to be 10.3 kilometers in length).

290

Project Interface Management

F.3.1.5 ​Transportation and Installation (T&I)

A separate contract will be established for T&I of the Topside modules, LQ, and Jacket from their construction locations to the offshore installation location and include the scope needed to install the Topside, LQ, and Jacket systems and modules offshore. This contract will include all work necessary to design for transportation including all lifting, loading, and securing for transport.

F.3.1.6 ​D&W

The D&W department is an ABC Corporation organizational asset and will manage the D&W subproject. As a result, the D&W department will contract for all hardware, services, and support required for drilling and completing wells for the Diamond project. D&W contracts will be managed by the D&W department, but their contractors need to interface with Project Diamond to ensure physical, logical, and functional alignment during project integration.

F.3.1.7 ​Project Diamond Completion Team

ABC Corporation takes responsibility for completion of the offshore facility. Completion is defined to mean physical hook-up between various components after installation. After hook-up is completed, the facility will undergo system validation as part of the commissioning process. Commissioning ensures that the facility is ready to deliver required system functionality. Upon successful commissioning, the facility will be turned over to the Diamond operations group who will be responsible for starting up and operating the facility.

F.3.2 ​Other Relevant Project Development Plan Information Insert other relevant information here as needed.

F.4 ​PROJECT DIAMOND/PROJECT SAPPHIRE INTERFACE OVERVIEW As required by the field development, Project Diamond will export its partially processed hydrocarbons to Project Sapphire. To support Project Diamond operations, Project Sapphire will provide 110 kV of power to Project Diamond through a subsea power cable and gas lift through an eight inch subsea flowline to support the start up of Project Diamond’s production wells. To safely manage the exchange of fluids, power, and gas lift, both projects will exchange a variety of safety and process signals including: emergency shutdown (ESD), process shutdown (PSD), power management system (PMS), power distribution and control system (PDCS), and process control system (PCS). In addition, interface activity includes the work to integrate Project Diamond to Project Sapphire and includes working locally at Project Sapphire to install, physically connect/terminate, and test flowlines and the power cable. This forms the basis for interface activity between the two projects as shown in Figure F.3.

F.4.1 ​Project Diamond/Sapphire Interface Control Working Groups (ICWGs)

Given the cooperation agreement terms and conditions between the two projects and the technical complexity associated with aligning interfaces between the projects, ICWGs will be established for

Appendix F  Project Diamond DG3 Interface Control Document

291

Figure F.3  Main interfaces conceptual illustration of Project Diamond and Project Sapphire field development

the interface areas shown in Figure F.4. These ICWGs provide an integrated forum to discuss the full breadth and depth of issues spanning into other organizational and project domains. These groups will be comprised of specific technical, management, and commercial personnel to ensure that as technical solutions are agreed upon and are checked for compliance against cooperation agreements and terms. These groups will also work to align deliveries of associated interdependencies such as procedures, tie-in equipment, support requirement, etc.

EICT Group

SURF Group

Electrical Sub-Group

Marine Operations Group

Telecommunication Sub-Group

Intergrated Schedule Group

Control/Process Sub-Group

Commissioning/RFO Group

Instrument Sub-Group

Environmental Group

Technical Safety Group

Production Chemicals Group

Figure F.4  Project Diamond/Sapphire ICWGs

292

Project Interface Management

F.4.2 ​Project Diamond Internal Interfaces—Responsible, Accountable, Consulted, and Informed (RACI) Matrices

The scopes of work described previously in Section 4 provided the basis for establishing RACI matrices between scopes that share interface boundaries. The RACI matrix defines which interface party is responsible for what activity across the EPC phases of the project. The RACI provided as part of the contract to each party is intended as a baseline and is subject to interface coordination between the parties after initiating the interface group. Changes to the respective RACI matrices are acceptable to find cost savings and to ensure technical integrity and project efficiencies, but all changes must be handled through the project’s management of change processes. In addition to the scope of work, the RACI matrix shall also act as a key interface driver during project execution between the interface groups. As a result, the RACI matrix will be utilized to assist interface verification activities and to confirm system interface issues have been resolved and incorporated into the respective scopes of work. As shown in Figure F.3, Project Diamond is to be integrated into Project Sapphire including the project’s safety automation system (SAS).

F.4.3 ​Project Diamond/Sapphire SAS RACI Matrix

The Project Diamond/Sapphire SAS RACI matrix has been provided in Figures F.5 through F.8 to illustrate the SAS. This RACI matrix illustrates major interface areas across engineering, procurement, fabrication/construction, and installation and commissioning activities, and serves as the mechanism to establish battery limits, or interface responsibility boundaries, between the two projects for design, development, and integration of the two SASs. Figure F.5 shows the major interface areas with respect to engineering. #

Engineering Activity

Project Diamond

Project Sapphire

1 2

Update ESD/PSD block line diagram (BLD)

C

RA

Update/Develop new Project Sapphire system control diagrams (SCD)

C

RA

3

Update Project Sapphire fire and gas (F&G) cause and effects (C&E)

C

RA

4

Develop Project Diamond SAS philosophy document

RA

C

5

Develop Project Diamond SAS functional design specification (FDS)

RA

C

6

Develop new Project Diamond ESD and PSD BLD

RA

C

7

Develop new Project Diamond SCD

RA

C

8

Develop new Project Diamond F&G C&E

RA

C

9

Test Project Sapphire SAS interface

I

RA

10

Update Project Sapphire safety requirements specification (SRS) document

C

RA

11

Develop Project Diamond SRS (technical safety deliverable)

RA

C

12

Develop Project Diamond network drawings for extension to Project Sapphire

RA

C

13

Develop Project Diamond FDS for remote testing of wells

RA

C

14

Develop Project Diamond FDS for virtual metering software

RA

C

Figure F.5  Diamond/Sapphire SAS RACI matrix—engineering activity

Appendix F  Project Diamond DG3 Interface Control Document

293

Figure F.6 shows the major interface areas with respect to procurement. #

Procurement Activity

Diamond Project

Project Sapphire

1

Procurement of Project Diamond SAS equipment (cabinet, controllers, IO)

RA

I

2

Procurement of SAS license extension

RA

I

3

Procurement of virtual metering server and required software/license

RA

C

4

Procurement of temporary test system/simulator to be used for testing

RA

C

5

Procurement of engineering tools and licenses for test system/simulator

RA

C

6

Procurement of simulator services

RA

C

Figure F.6  Diamond/Sapphire SAS RACI matrix—procurement activity

Figure F.7 shows the major interface areas with respect to fabrication and construction. #

Fabrication and Construction Activity

1

Programming of Project Diamond SAS nodes

2

Project Diamond

Project Sapphire

RA

C

Programming of modification in nodes at Project Sapphire

C

RA

3

Develop new Project Diamond HMI F&G overview display

RA

C

4

Perform initial or internal acceptance test (IAT)/factory acceptance test (FAT) of new Project Diamond logic in SAS supplier location

RA

C

5

Perform IAT/FAT of modified logic for Project Sapphire facility

C

RA

6

Dynamic/interface testing on simulator (remote testing of wells, slug control, well control, gas lift, chemical injection, diesel, fresh water, etc.)

RA

C

7

Perform system site acceptance test of the control system at the Project Diamond construction yard

RA

I

8

Loop testing of instruments and valves at the Project Diamond construction yard

RA

I

Figure F.7  Diamond/Sapphire SAS RACI matrix—fabrication and construction activity

294

Project Interface Management

Figure F.8 shows the major interface areas with respect to installation and commissioning. #

Installation and Commissioning Activity

1

Integrate Project Diamond SAS into Project Sapphire system (post temporary installation system removal)

Diamond Project

Project Sapphire

C

RA

2 3

Patching of SAS network on Project Sapphire

C

RA

Patching of SAS network on Project Diamond

RA

C

4

Commissioning of Project Diamond nodes

RA

C

5

Commissioning of Project Sapphire nodes

C

RA

6

Loop testing of new instruments and valves at Project Sapphire

I

RA

7

Integration testing and dynamic commissioning offshore (systems that not have been tested on simulator)

C

RA

Figure F.8  Diamond/Sapphire RACI matrix—installation and commissioning activity

F.4.4 ​Project Diamond/Sapphire SAS Signal Interfaces

The main SAS interface between Projects Diamond and Sapphire relate to ESD and PSD scenarios. Figure F.9 identifies the primary ESD signals to be exchanged between the projects. The ESD signals ensure that if an unsafe consideration is identified on either offshore facility, then a corresponding action will be generated with the other facility. Figure F.10 identifies the PSD signals, which are used to guide an expected shutdown of the facilities.

F.5 ​SUMMARY This example ICD illustrates one method to construct an interface control document, but the aim of an ICD-like document is to describe the system interfaces between interface parties to a level that is adequate to maintain control of those interfaces during project development. This example serves as a template from which other interface areas between the two projects will be defined, monitored, and controlled. There is no standard format or template for an ICD. Rather, each project and situation will vary with respect to the kinds and amount of information required. For information technology projects, ICDs may be heavily weighted with signal or data exchange tables. Other projects may use more illustrations and text. Regardless, the main intent is to communicate main interface areas between interface groups. In addition, development of an ICD will align with the project development phase and the maturity of the system concept. Early in project development, the system concept may only be illustrated as a high-level system architecture. Thus, an ICD will not likely be overly detailed. As the system concept becomes mature and further defined during later project development phases, the ICD likely will be updated to reveal more details about the interfaces that are internal to the project and to external systems.

NA

NA

NA

NA

NA

NA

NA

NA

Link 5

Link 5

Link 5

Link 5

Link 5

Link 5

Link 5

Link 5

79NXI4430

79NXI0032

79NXI0034

79NXI0033

79NXO4402A

79NXO2002A

79NXO1000A

79NXO0002A

Tag

ESD

ESD

ESD

ESD

ESD

ESD

ESD

ESD

System

NA

NA

NA

NA

NA

Link 6

Link 6

Link 6

Link 6

Link 6

87NXI0007

87NXI0006

87NXO0005

87NXO0004

87NXO0003

Tag

PSD

PSD

PSD

PSD

PSD

System

Figure F.10  Diamond/Sapphire PSD Signals

Area

LINK No.

Figure F.9  Diamond/Sapphire ESD signals

Area

LINK No.

1 second

1 second

1 second

1 second

1 second

Frequency

1 second

1 second

1 second

1 second

1 second

1 second

1 second

1 second

Frequency

NA

NA

NA

NA

NA

Unit

NA

NA

NA

NA

NA

NA

NA

NA

Unit

P0?

P01

P01

P03

P03

Source

E01

E01

E01

E01

E01

E01

E01

E01

Source

PSD 4.27.3 SIGNAL FROM DIAMOND

PSD 3,1 SIGNAL FROM DIAMOND

PSD 5.13.8 DIAMOND GAS LIFT PIPELINE

PSD 5.13.5 DIAMOND IMPORT 2

PSD 5.13.4 DIAMOND IMPORT 1

Description

MEI from DIAMOND trip 80EH300+04 CB

APS SIGNAL FROM DIAMOND

ESD 2 SIGNAL FROM DIAMOND

ESD 1 SIGNAL FROM DIAMOND

EL.TRIP 4 DIAMOND, 80EH0500=E02 CB

ESD 2.2 SIGNAL TO DIAMOND

ESD 1 ALARM TO DIAMOND

APS SIGNAL TO DIAMOND

Description

DIAMOND

DIAMOND

SAPPHIRE

SAPPHIRE

SAPPHIRE

Platform

DIAMOND

DIAMOND

DIAMOND

DIAMOND

SAPPHIRE

SAPPHIRE

SAPPHIRE

SAPPHIRE

Platform

XYZI0007

XYZI0006

XYZO0005

XTZO0004

XYZO0003

Tag no

ABCI4430

ABCI0032

ABCI0034

ABCI0033

ABCO4402A

ABCO2002A

ABCO1000A

ABCO0002A

Tag no

To be determined

XYZ-001-I-XL-87-00002

XYZ-001-I-XL-87-00002

XYZ-001-I-XL-87-00002

XYZ-001-I-XL-87-00002

Cause&Effect

XYZ-001-I-XR-00006.001

XYZ-001-I-XR-00004.001

XYZ-001-I-XR-00011.001

XYZ-001-I-XR-00005.001

XYZ-001-I-XR-00006.001

XYZ-001-I-XR-00010.001

XYZ-001-I-XR-00007.001

XYZ-001-I-XR-00004.001

Cause & Effect

Appendix F  Project Diamond DG3 Interface Control Document 295

Appendix

G

Example Interface Management Closeout Report

G.1 ​INTRODUCTION G.1.1 ​Purpose

The purpose of this closeout report is to document key aspects of Project A’s interface management system during the project execution phase from the first quarter of 2013 through the fourth quarter of 2016. Primarily, this document provides a record for decisions driving the project’s approach to managing interfaces as well as documenting lessons learned to serve as a useful reference for future projects.

G.1.2 ​Header Information

Often the reports will contain header information that names the document, revision number, and other relevant information as shown in Table G.1. Table G.1  Header information about report Doc No: Interface Management Closeout Report—Project A

Rev: Date: Page:

G.1.3 ​Definitions

• External interface: an interface requiring coordination along common boundaries between two independent entities or interface parties with no controlling, contractual, or organizational relationship • Interface group: a group consisting of two (or more) independent parties who share a common boundary but have a relationship with limited or no direct control over one another’s activities 297

298

Project Interface Management

• Internal interface: an interface occurring within an entity (e.g. organization, project, department, etc.) scope of work, or area of responsibility, within the same project for the same client contract, including any derived subcontracts • Interface network: a group of interface parties established to coordinate interface issues associated with specific types of project stakeholders • Interface register: a database where each interface item and its associated information are stored • Lead interface contractor : a contractor assigned with additional interface responsibility (mostly administrative) for an interface group by the owner of the project’s interface management system.

G.1.4 ​Abbreviations CPI DG D&W OP E-IDR ENS EPC ESD FEED IDR KoM LQ MDR MoM PDCS pdQ PFS PMS PSD SAS SURF T&I TQ UHGP WIR

company provided item decision gate drilling and wells Project B Oil Pipeline extended integrated design review engineering number system engineering, procurement, and construction emergency shutdown front-end engineering design integrated design review kick-off meeting living quarters master document register minutes of meeting power distribution and control system production, drilling, and quarters power from shore power management system process shutdown safety automation system subsea, umbilical, riser(s) and flowline(s) transportation and installation technical query Utsira High Gas Pipeline web interface register

G.1.5 ​Referenced Project Documents

Often, other project documents are referenced in interface management closeout reports. In this case, we reference the interface management procedure for the project as shown in Table G.2. Table G.2  Project documents Document Number

Title

Revision

XXXX-XX-X-XXX

Interface Management Procedure—Project A

02M

Appendix G  Example Interface Management Closeout Report

299

G.2 ​PROJECT A: OVERVIEW With completion of DG3, Project A formally entered the execution phase in the first quarter of 2013. As a result, the project’s FEED interface management procedure (DN02-DN-Z-KA-0011) was updated (02M) to govern management of the project’s interface throughout the project execution phase, which remained active through first oil (12/24/2016). The foundation for establishing the project’s philosophy toward interface management was derived from the assessment of interface and interdependency complexity and risk areas associated with the project’s operational concept, project development approach, and contracting strategy. A key aspect of the project’s interface management philosophy mandated that Project A establish a system for managing external interfaces between various scopes of work (e.g., between various contractors, between Projects A and B, etc.) and areas of responsibility (e.g., between Project A subproject teams and organizational departments), through a series of interface networks. The interface management procedure allowed internal interfaces to be managed using the respective contractor’s management system and processes. However, Project A clients reserved the right to prescribe an internal interface management system in case the internal systems proved to be ineffective.

G.2.1 ​Operational Concept

Project A consists of discoveries 13/2-6 and 13/2-7. The field is located in the northern North Sea. Development of Project A included a pdQ platform with a steel jacket and a separate jack-up rig for drilling and completion. The platform has spare slots for possible additional wells. The platform is equipped for tie-in of a subsea template planned for the future development of local areas and for possible development of other nearby discoveries. First-stage processing is performed on Project A—and the partly processed fluids are transported to Project B for final processing and export. In addition to receiving, processing, and exporting Project A hydrocarbons, this concept requires Project B to provide power and gas lift to Project A. Thus, interface and integration with Project B included physical tie-in of a 110 kV subsea power cable containing two fiber cables (24 fiber pairs in each cable), two 12-inch flowlines, and one 8-inch gas lift flowline. In addition, logical interfaces ESD, PSD, PDCS, and PMS signal exchange formed a significant area of interface between the two projects.

G 2.2 ​Contract Strategy

A simplified representation of the contract strategy for development of Project A is depicted in Figure G.1 and illustrates the project’s use of multiple contract types to support Project A’s facilities development from concept development through commissioning. The EPC, Transportation and Heavy Lift, Installation and Hook-Up, and Commissioning sections represent the project’s execution phase and are the subject of this closeout report. Note: Project A’s LQ was initially included in the Topside contract. However, the LQ portion of the Topside contract was removed and awarded as a lump sum EPC contract. This included a provisional sum on critical packages (HVAC and life boats) and areas with too great of uncertainty to include in the lump sum (i.e., commissioning assistance and construction and installation of packages, such as company-provided electrical, instrumentation, control, and telecommunications, etc.). Not depicted in the contract strategy were significant wellbay (module M20) interfaces toward the client’s D&W organization, such as Christmas trees, well operations equipment, etc. The client’s D&W department, through a network of specialized companies, managed D&W related products and services to Project A. To facilitate interface activity to Project A, the client D&W provided onsite

Commissioning

Installation and Hook-up

Transportation and Heavy Lift

EPC

FEED

NA

Reimbursable

Rig Contract

NA

NA

Reimbursable and Lump Sums

Service and equipment contracts

Reimbursable

Lump sum and Reimbursable

EPCI

FEED contract Reimbursable

Concept study contract

ABC Corporaon

Reimbursable

Norms and rates for construction. Target sum for engineering & procurement Lump Sum for preliminaries and Living Quarter

EPC

FEED contract Reimbursable

Study contract

Study contracts as relevant

pdQ Topside

Concept Development

Subsea Flowlines and Power Cables ABC Corporaon

Services & equipment

Project Management

Rig

Drilling

Figure G.1  Project A development project contract strategy

DG4

DG3

DG2

Diamond Project “Phases”

NA

EPCI Lump Sum

EPC Lump sum

FEED Contract Reimbursable

Study contract

Jacket

NA

NA

EPCI Lump sum

Study Contract under Topside FEED

Transportation and Installation

NA

Flotel Contract Reimbursable

NA

Flotel

300 Project Interface Management

Appendix G  Example Interface Management Closeout Report

301

representation to the Project A Topside EPC team during the engineering phase (FEED and detailed engineering) to assist with D&W related design interfaces.

G.3  PROJECT A: INTERFACE MANAGEMENT ORGANIZATION/STRUCTURE To support the project development strategy, the client established subproject management teams to oversee work being accomplished by Topside, LQ, SURF, Jacket, T&I, Flotel, and D&W contractors. Within each of the client’s subproject teams, personnel were assigned with either primary or secondary interface responsibilities depending on the complexity and intensity of expected interface interaction. This interface structure maintained adequate company oversight of interface activity by the corresponding contractor teams and ensured interface performance in accordance with Project A’s interface procedure throughout Project A’s execution. To support interface activity toward Project B, a number of interface working groups were established. These groups consisted of relevant technical personnel from the Project A and Project B engineering and management teams to coordinate and align interfaces for their technical or project management domain. In addition, Project A provided technical representation to the Project B Oil Pipeline and Gas Pipeline projects as needed. However, this interface activity was not part of Project A’s interface management system and not a subject of this closeout report.

G.4  INTERFACE MANAGEMENT APPROACH To manage Project A’s interface complexity, six interface networks were established to compartmentalize project interfaces into groups of related parties and the interface interests they commonly share. A brief description of each network is provided in the following sections, but this approach helped to decompose (break down) interface complexity into more manageable parts. Over 3,000 interfaces were identified and resolved across the project during Project A’s development. Project A utilized Kongsberg’s Seaflex WIR as the web-based automated tool to house all interface information, including supporting documentation, interface sheets describing responses and agreements between interface parties, and MoMs for each interface group. An information archive from each interface network has been downloaded and stored at the project archive.

G.4.1 ​Project A/B: Network

This network served to conduct interface activity related to tie-in, integration, and commissioning of Project A to Project B (operated by a separate company). While initially activated during Project A FEED in 2012, this network remained active and transitioned into Project A’s execution phase in early 2013 and remained active through Project A first oil. Interface activity within this network was restricted to company-to-company interaction between the two project sponsoring companies who acted on behalf of their respective contractors. While interfaces toward Project B were successfully resolved, two major factors detracted from the effectiveness and efficiency in managing interfaces between the two projects: (1) offset in project development timelines and (2) lack of direct involvement by the respective projects’ engineering contractors.

G.4.1.1 ​Project Development Timelines

Project A and B’s developments, while having similar durations and development approaches, were offset by approximately one year. Specifically, Project B’s development remained one year ahead of

302

Project Interface Management

Project A. This resulted in a constant offset in design and development activities, which created difficulty for each project to provide key engineering design interface information when required by the other project. While it is understandably not realistic to mitigate timeline offsets between different project developments, this offset issue could have been mitigated through the utilization of a small colocated integrated team.

G.4.1.2 ​Lack of Involvement by Engineering Contractor

Interface activity between Project A and Project B was performed directly by the project’s sponsoring companies as a company-to-company interaction. Interaction did not include the direct participation of the respective engineering contractors. Rather, each company coordinated directly with one another, then returned to their respective projects and coordinated separately with their respective contractors and then repeated the cycle. This created an unnecessarily elongated process requiring significant time and effort. For similar future project-to-project tie-in developments, it is recommended an agreement be obtained to allow contractors (engineering especially) to be part of the project-to-project interface network. Direct participation by engineering contractors with project sponsor oversight will increase common understanding of interface issues and reduce the time frame to align and resolve interfaces.

G.4.2 ​Project A: Contractor Network

Comprised of 43 interface groups, this extensive network consisted of all contractors contributing products and/or services to Project A, including D&W contractors. This network provided a transparent communication mechanism to formally coordinate interfaces along Project A contractors’ respective scope of work boundaries. As expected, this network accounted for approximately 66% of all interface activity across the project with the Topside EPC contractor assigned as the primary lead interface contractor. In general, this network performed well. However, misalignments between the various contractor subproject plans created difficulties in aligning dates for resolving interfaces and interdependencies, such as the delivery of CPIs. The semiannual project re-baseline process exacerbated this challenge. While the re-baselining process rarely affected project milestones, it did result in numerous schedule adjustments to individual subproject activities. As expected, schedule adjustments to some of the subproject activities impacted interfaces; requiring replanning and resulting in more interface planning misalignments. Ultimately, the inability to maintain alignment of the respective subproject schedules resulted in several variation order requests due to out-of-phase engineering, especially from the LQ subproject, which were attributed to delayed interface resolution and delivery of CPIs. As the lead interface contractor, Topside EPC represented the central interface party against most other contractors. The Topside engineering subcontractor was assigned interface management responsibility on behalf of the Topside EPC prime contractor. However, while Topside Engineering performed admirably in its interface management role, topside design progress and quality hampered the team’s ability to meet time-critical interfaces and interdependencies toward key interface parties, including the LQ and SAS contractors.

G.4.3 ​Project A: Company Internal

This network allowed the client’s subproject management teams and various company departments to interface and document agreements-related changes across scope boundaries, functional requirements issues, and to clarify operational requirements and other matters extending across multiple subproject

Appendix G  Example Interface Management Closeout Report

303

boundaries. While used sparingly through Project A development, the network did provide a useful forum to coordinate and align interface issues between subproject management teams and various organizational departments including operations and D&W before engaging the affected contractors.

G.4.4 ​Client D&W Network

Established as a means for the client’s D&W department to interface on issues related to integrating the jack-up drilling rig (JUR) with the Project A pdQ, this network included interface activity related to installing, hook-up, and commissioning of the primary and secondary bridges to the Project A pdQ. While only utilized for a brief period, this network aided in preparation and work leading to a successful integration of the JUR to Project A’s pdQ. However, this network could have been expanded and used more extensively by D&W with their respective contractor network. Instead, a manual technical query system was established between D&W and its contractor network using an Excel spreadsheet on Projectplace resulting in overly timeconsuming activities that elongated timelines to resolve issues.

G.4.5 ​Topside EPC Internal (Engineering)

Findings from the E-IDR identified a highly bureaucratic and ineffective TQ process between the Topside Engineering and SAS contractor resulting in excessive administrative work, long process time frames, and delays to critical SAS development scope. Established after the E-IDR, this network facilitated control node interfaces (fire and gas, ESD, PSD, Process Control, and PDCS) between the Topside Engineering subcontractor and the SAS contractor. While only utilized for a short duration (November 2015–July 2016), implementation of this network greatly improved transparency and traceability of the SAS design information requirements between the two parties.

G.4.6 ​Project A: (Subsea Team)—Project B: (Maintenance Contractor)

To accommodate Project A’s power cable pull-in, hang-off, and installation, this interface network served as the forum for direct interface between Project A’s subsea team, who were responsible for subsea cable installation, and Project B’s maintenance contractor, who was assisting with the activities. While only used for the power cable pull-in, hang-off, and termination period, this network was nevertheless very valuable in resolving related interface issues quickly and with transparency to both project organizations.

G.5 ​INTERFACE LESSONS LEARNED Several lessons learned were documented during Project A’s execution. These lessons vary from those directly related to interface management to indirect lessons that affected interface management effectiveness. Interface lessons learned have been compiled in the project’s “Lessons” module and are identified with the word “Interface” as the first word in the title. Highlights of the lessons learned are provided here for convenience to the reader.

G.5.1 ​Interface Control Document (ICD)

The lack of a project-level ICD at the beginning of Project A’s execution hampered interface management activity between the interface parties. An ICD describes the system interface boundaries that reflect the system’s operational scenario and expected system behaviors (e.g., normal and abnormal

304

Project Interface Management

conditions). At a minimum, the ICD should identify the expected interactions between major systems (or subsystem, package, component) to the control boundaries of external systems and structured to align with the project development’s expected work breakdown structure (e.g., scopes of work and contract strategy). With the absence of an ICD, Project A’s interface parties expended unnecessary effort initially attempting to clarify battery limits (e.g., discrete control boundaries) instead of focusing on the technical effort to resolve interfaces. An output of the FEED phase should include a document describing, graphically and textually, the interfaces between the various systems and across scope boundaries, and by interface object (e.g., system, subsystem, component, etc.). This ICD should fundamentally align with scopes of work and areas of responsibility (responsibility matrices) and focus especially on high-risk or technically complex aspects of the system. This type of document (e.g., ICD) at the beginning of the project execution phase provides a meaningful starting point and allows interface parties to identify any scope or technical integrity gaps, overlaps, or misalignments. In addition, the ICD should address interdependencies provided from one entity to another. These interdependencies manifest in many forms, but can include CPIs (e.g., safety automation system material), material to verify procedures (e.g., pipe pieces to validate welding procedures, perform destructive testing, etc.), and others. Interdependencies can delay project work if not delivered by the required on-site date. Thus, the ICD should also identify when critical interdependencies are required if known.

G.5.2 ​Interface Priority Process

During the project, several hundred interfaces were open at any given time, but the interface register lacked a mechanism to identify which interfaces were priorities at any given time. Due to varied circumstances, individual interfaces would suddenly become important and need more management attention. For example, after the semiannual re-baseline process, some activities within the subprojects became rescheduled. In turn, some of the rescheduled activities affected interfaces requiring interface-planning dates to be adjusted, which created misalignments. A system to identify critical interfaces helped focus attention and resources on specific interface items that could negatively affect (risk) ongoing work, cost, or schedule. As a result, a priority feature using a red-light system implemented in the interface register tool allowed interface parties to highlight critical interfaces. This feature became very important after the re-baseline process when activities (affecting interfaces) shifted. Typically, after a re-baseline process, a number of interfaces became misaligned between interface parties. This priority feature helped to highlight these misalignments and allowed the company to align its efforts to the most urgent interface issues.

G.5.3 ​Interface Documentation Policy

Early in the interface management process, a widespread misunderstanding existed regarding the use of the Seaflex WIR—specifically, how this tool aligned to the document control process. Project A’s contractors were using the interface management tool, Seaflex WIR, as a document control tool to exchange interface documentation. A significant portion of interface information consisted of contractor design documentation, controlled according to the project’s ENS. However, it became impractical to manage control of these documents in Seaflex since the iterative engineering process produced several revisions. As a result, an interface documentation policy was established and formally communicated to all parties. This policy required the exchange of MDRs between interface parties to identify relevant interface documentation. Agreed-upon MDR documents were added to the distribution matrix within

Appendix G  Example Interface Management Closeout Report

305

each contractors’ document control system; and any future updated revisions would be pushed to interface parties through a formal document control transmittal. Implementation of this lesson learned resulted in better monitoring and control of interface documentation exchange.

G.5.4 ​Interface Management Forums

Given the number of different interface parties, scale and scope of Project A and the changes affecting the project as it progressed through the project life cycle, it became difficult to maintain interface-planning alignment. Further, alignment was complicated by the project’s re-baseline process, which created numerous micro changes that rippled into interfaces. As a result, an interface forum was created to plan ahead for the next six months. An example interface forum package is provided in the lesson learned and forum timeline illustrated in Figure G.2. Project A convened three interface forums over an 18-month period to deconflict schedule misalignment that was associated with interdependencies and interfaces between respective parties. Conducted as a face-to-face meeting, these forums focused on the next six-month period and highlighted significant issues resulting from the rebaseline process between interface entities. As an integrated event, the forum was attended by the client’s interface personnel across the project. While the event proved a valuable tool in maintaining interface alignment among company representatives, the event should have been expanded to include primary interface representatives from each contractor.

G.5.5 ​Interface Kick-Off Meetings

During implementation of the interface management system for Project A, interface management KoMs were sponsored and hosted by the client with each Project A contractor and then with each interface group. This was a positive experience and helped to set expectations, align interface management processes, and establish the foundation for quickly starting interface activity. However, the interface group KoM could have been improved by having the interface parties exchange scopes of work (in lieu of an ICD). To initiate each interface group, the client’s interface manager conducted an interface group KoM with each interface group within each network. These meetings included the respective contractors and their client representatives. While these KoMs required significant effort, they were extremely important toward establishing interface momentum, especially given the initial uncertainties regarding specific interfaces between parties (e.g., lack of an ICD).

G.5.6 ​Integrated Design Reviews

A requirement in the Topside EPC contract was responsibility for technical integrity, of which interface management served a primary function and was primarily verified through model reviews. However, it became apparent that typical model reviews (e.g., 30%, 60%, and 90%) were not adequate to verify technical integrity and functionality across scope boundaries. To address this deficiency, several IDRs were conducted by the client to evaluate system functionality from reservoir to Project B, inclusive of the JUR. Figure G.3 shows Project A’s integrated design review timeline. In essence, these IDRs served as integrated interface verification events covering the entire operating environment. Through the IDR process, and by focusing on the safety and effectiveness of system functionality, these reviews provided a logical and thorough assessment of the overall design across combinations of scopes of work, systems, subsystems, and areas of responsibilities. The outcome of the IDR process was the identification of numerous gaps and deficiencies affecting system functionality that were subsequently addressed through engineering efforts preventing potential late-stage integration, hook-up, commissioning, and start-up problems.

01.01.2016

Figure G.2  Project A interface forums

04.29.2016 Interface Forum #2

07.01.2016

01.01.2017

02.07.2017 Re-baseline

04.01.2017

02.01.2017 – 03.28.2017 90% Model Review

11.19.2016 Interface Forum #3

10.01.2016

08.24.2016 Re-baseline

05.09.2016 – 07.03.2016 60% Model Review

04.01.2016

02.02.2016 Re-baseline

11.26.2015 Interface Forum #1

10.01.2015 09.01.2015

09.30.2015 – 10/09.2015 30% Model Review

07.01.2017

10.01.2017

01.01.2018

04.01.2018 04.16.2018

306 Project Interface Management

01.01.2016

07.01.2016

04.29.2016 Interface Forum #2

04.01.2016

05.09.2016 – 07.03.2016 60% Model Review

Figure G.3  Project A integrated design reviews

11.26.2015 Interface Forum #1

10.01.2015 09.01.2015

09.30.2015 – 10/09.2015 30% Model Review

01.01.2017

11.19.2016 Interface Forum #3

10.01.2016

04.01.2017

02.01.2017 – 03.28.2017 90% Model Review

10.01.2017

- Recover HCs - Export HCs - Process HCs - Utilities - Global Start-Up - Global Safety - Accommodate Personnel

04.01.2018 04.16.2018

- Wellbay Functions - Hatches (Wx/Inter) - Utility Station - Material Handling - Well Start-Up / Clean-Up - Jack-Up Rig

03.01.2018 – 03.31.2018 D&W IDR Process

01.01.2018

08.18.2017 – 09.30.2017 IDR Process

07.01.2017

11.01.2017 – 11.20.2017 E-IDR Process

- ESD (Node E11) - PSD (Nodes P41, P42) - PCS (Nodes C31-C34) - PDCS (Node L01) - Electro (Nodes M120, M140, L0)

- Fire & Gas (Nodes F21, F22)

Appendix G  Example Interface Management Closeout Report 307

308

Project Interface Management

G.6 ​SUMMARY While difficult to quantify, anecdotal evidence suggests that the application of interface management as part of Project A’s management system contributed to reducing the realization of negative consequences and contributed to the project’s on-time and within budget success. By implementing a lean, yet comprehensive interface management system, the client increased its ability to (1) ensure efficient collaboration, (2) effectively monitor cooperation between key entities contributing to project development, and (3) proactively influence interface activity when required, reducing the number of late-stage integration issues. While comprehensive, the interface management system remained flexible incorporating lessons learned while adapting to specific circumstances of the project and the needs of those participating in the interface process. Yet, notable deficiencies prevented maximum effectiveness of the system. The lack of an ICD to define interfaces and interdependencies detracted from the effectiveness of the interface management process, especially during project execution start-up. An ICD is key to managing technical integrity, especially in large-scale complex projects with complicated contract strategies and extensive CPIs. An ICD should be developed during FEED and delivered at DG3. In addition, Topside’s scope of work was a central element to delivery of the facilities’ value functions (recover, process, and export hydrocarbons) and ensuring technical integrity. Yet, the Topside EPC internal interface management system was nonexistent, particularly between the Topside Engineering and SAS contractors. The lack of an internal Topside EPC interface management system created carryover interface problems with other contractors (e.g., LQ) resulting in numerous variation order requests. The project’s interface management system should extend into the contractor’s internal team (subcontractors, key suppliers, and vendors, etc.) when their scopes of work are central to system functionality or technical integrity. Doing so provides the client with the transparency needed to intervene when warning signs begin to emerge, enabling the client to mitigate problems before they become severe. As of this report, all interface issues have been resolved and there are no open items in the interface register. Information in the interface register (Seaflex WIR) database has been downloaded by Kongsberg and is archived locally. A copy of the relevant Project A/Project B interfaces archive has been transferred to Project B’s organization. In addition, Projects A and B have agreed on as-built interface documentation and these documents have already been transferred between the projects.

Index Note: Page numbers followed by “f ” indicate figures. Acceleration of societal change, 3–5 impact on project management, 10, 19, 23 implications, 4–5 Agricultural Revolution, 2–3 Alice’s Adventures in Wonderland, 5 Asset integrity, 209, 211, 218, 218f, 220f, 225–226, 230–231 Assurance integrity, 58, 212 B/MA. See Business or mission analysis (B/MA) Baber, P. S., 93 Baccarini, D., 26 Battery limit. See Common boundary/Common boundaries Benefits management, 10–11 Beta, Toba, 49 Big Dig project, 11–12, 14 Boeing 787 Dreamliner project, 138–140, 152, 160 Bronze Age, 2 Business or mission analysis (B/MA), 43–44 California High-Speed Rail (CHSR), 12 CAPEX. See Capital investment costs (CAPEX) Capital investment costs (CAPEX), 20 Capital investments, 14, 20, 22 Carroll, Lewis, 5, 209 Central Artery Tunnel project. See Big Dig project Chen, Peter, 107–108 China-Pakistan Economic Corridor, 13 CHSR. See California High-Speed Rail (CHSR) CI. See Contractor Internal (CI) CIM. See Coreworx Interface Management (CIM) CINs. See Communication Interaction Networks (CINs) CIP. See Client internal project (CIP)

Client internal project (CIP), 74–75, 101f, 102, 106f, 134f Client’s prime contractor (CPC), 74–75, 101f, 102, 106f, 108–111, 116f, 189, 191, 192f, 193f, 194 interface network, 74, 105, 108, 108f, 109, 110–111, 111f, 115, 134f, 135, 136f, 138 Cognitive Revolution, 2–3 Collaborative management systems, 138–140. See also Boeing 787 Dreamliner project Commissioning, 8, 17, 64, 81, 112, 167, 167f, 209, 211, 213–214, 218, 220, 223, 225 Common boundary/Common boundaries, 35, 36, 51–58, 55f, 61, 64, 66, 74, 78, 79, 82 Communication, 1, 4, 18, 19, 28, 29, 36, 43, 49, 51, 52. See also Interactions; Telecommunication Communication Interaction Networks (CINs), 73, 74 Company provided items (CPIs), 51, 58, 63, 65, 74, 75, 101, 104, 115, 126, 168 Completion, mechanical, 8, 17, 81, 211, 225 Complex systems, 10, 18–20, 27, 31, 37, 49, 84, 119, 120, 164, 177, 182, 183, 230 Complexity, 1, 2, 9. See also Interactions; Interdependencies; Interface(s) behavior of systems and, 18 communication, 74 complicated versus, 26–27 definitions, 26–28 development approaches, 31–32 emergence versus reduction, 27–28 environment, project, 30–31, 36 factors influencing, 33–34, 46 interaction, 29, 50, 77, 109 interdependencies, interfaces, and interactions, 34–37 interface, 56, 93, 94, 100, 102, 105, 117, 119, 185, 194 309

310

large-scale projects, impact of, 10, 11, 14, 23, 29–30, 32 layers of, 4–5 organizational, 26, 161 project management, influence of, 28–30 stakeholder, 37–45. See also Stakeholder(s) system, 32–34. See also System complexity systems engineering (technical management), impact of, 28–29 technological, 26, 32 Conceptual design, 8, 63, 78, 112, 167–168, 172 Construction, 8, 17, 53, 76, 167, 170, 186, 217, 230. See also Engineering, procurement, and construction (EPC) Contract strategy, 1, 20, 21, 22–23, 39, 50, 54, 62, 78, 79, 101, 105, 111, 115, 168, 207 Contractor Internal (CI), 74, 76, 102, 105, 106f, 115, 116f, 134f, 187, 189 Contracts, 20–23, 51, 55, 66, 82, 91, 105, 111, 126, 139, 152, 159, 163, 211, 231 awarding of, 39, 42, 50, 71, 79, 81, 152, 153, 155 contracting strategy, 20, 21, 22–23. See also Contract strategy interdependencies, 22 types, 20–23 Coreworx Interface Management (CIM), 130, 131, 176–177 Cost plus incentive fee, 21 Cost reimbursable contracts, 21, 22 CPC. See Client’s prime contractor (CPC) CPIs. See Company provided items (CPIs) DAU. See Defense Acquisition University (DAU) Decision gates (DG), 15, 17, 18, 78, 96–97, 149 DG2, 16f, 167, 167f DG3, 16f, 17, 97, 98, 99, 149, 167, 167f, 168, 170, 172 DG4, 16f, 17, 97 Defense Acquisition University (DAU), 7–8, 15 Department of Defense (DoD), 7–8, 15–17 acquisition framework, 168 Concept of Employment (COE), 40 ICDs, 168–169 ICWGs in, 171 System Acquisition Framework, 15–16, 16f Design structure matrix (DSM), 117, 119–120, 121f activity-based/schedule, 120 component-based/architecture, 119

Project Interface Management

parameter-based/low-level schedule, 120 resources, 120 team-based, 120 Detailed engineering, 8, 17, 63, 91, 112, 132, 142, 153, 165–167, 170, 172, 186, 197, 198, 205, 209, 213, 214, 222, 228 DG. See Decision gates (DG) DoD. See Department of Defense (DoD) DSM. See Design structure matrix (DSM) Emergence, 27–28 Engineering, procurement, and construction (EPC), 8, 22, 94, 104–105, 106f, 110–111, 149–150, 186, 209, 211, 223 drilling and wells (D&W) jack-up rig (JUR), 80f, 81, 108f, 109, 111, 111f flotel, 80f, 81 hook-up, 80f, 81, 111, 111f, 149 jacket, 80f, 81, 105, 108f, 109, 137, 191, 199f living quarters (LQ), 80f, 81, 105, 108f, 109, 111, 111f, 228 Subsea, 104, 105 topside, 80f, 81, 105, 108f, 109, 115, 152–153, 187, 188f, 198, 199f transportation and installation (T&I), 80f, 81, 111, 111f, 137 Engineering, procurement, construction, and installation (EPCI), 80f, 81, 104, 105, 108f, 109, 152 jacket, 111, 111f, 152f subsurface umbilical risers and flowlines (SURF), 80f, 81, 108f, 109, 111, 111f, 152–153, 152f, 156f EPC. See Engineering, procurement, and construction (EPC) EPCI. See Engineering, procurement, construction, and installation (EPCI) Expert judgment, 41 Fabrication, 8, 76, 167, 170, 186, 217, 230 FEED. See Front-end engineering design (FEED) Fixed price contracts, 20–21, 22 Front-end engineering design (FEED), 167, 172 Greiman, Virginia, 11, 12, 14 Harari, N. H., 2–4 HDD. See Hierarchical decomposition diagram (HDD) Heraclitus, 69

Index

Hierarchical decomposition diagram (HDD), 117–119, 118f Hill, Napoleon, 123 Horton, Douglas, 25 ICD. See Interface control document (ICD) ICWGs. See Interface control working groups (ICWGs) IDRs. See Interface design reviews (IDRs) IER. See Interface entity relationship (IER) IMP. See Interface Management Plan (IMP) INCOSE. See International Council on Systems Engineering (INCOSE) Influence/impact grid, 41 Information Age, 1, 34, 40, 128, 169 Infrastructure projects, 12–14, 19–20, 38 Installation, 8, 17, 64, 81, 83, 112, 118f, 131, 152, 164, 186, 197, 209, 211, 213, 218 Integrity, 160, 204, 205, 207, 212–213, 217–219, 221–223, 226–231, 227f. See also Technical compliance Interaction networks. See Interface networks Interactions, 18–19, 25, 27, 36–37, 40, 46, 52, 73, 77, 93, 111, 120, 177, 180, 186, 212 basis for, 176–177 intensity, 36, 126 interface group, 177–182, 179f minutes of meeting (MoM) function, 178–182, 179f, 181f Interdependencies, 22, 26, 27, 29, 35–37, 40, 42, 46, 52, 57, 63, 94, 95, 109, 115, 121, 129, 139, 144, 149, 163–165, 172, 175–177, 180, 211, 214, 219, 232 challenges, 151 complexity, 93, 99, 102, 111, 123 conflicts, 166 risk, 95 Interface/Interfaces, 16, 34–37, 40, 42, 46. See also Interface management agreement. See Interface agreements analysis. See Interface analysis area. See Interface areas artifacts, 210, 231 categories, 62–66. See also Interface categories clashes, 72, 86 definitions, 35, 52–53, 53f explicit, 10, 18, 22 external, 18, 35, 61, 66–67, 67f, 155, 160, 187 group. See Interface groups implicit, 10, 22

311

information archive, 233 intensity, 36–37, 56, 57, 70, 78 internal, 35, 61, 66–67, 66f, 74–76, 95, 105, 155, 160, 171, 186–187, 188f issue. See Interface issues item. See Interface items network. See Interface networks parties. See Interface parties types, 66–67 value creation by, 219–221, 220f Interface activities, 56, 57, 62, 69, 70, 72–73, 79, 82–91, 117, 130, 143, 213, 214, 219, 225, 229, 231, 232 emphasis of, 115 initiation, 151, 153, 155, 158, 161, 162–163, 170, 177, 189 key performance indicators (KPIs), 88, 89–91. See also Key performance indicators (KPIs) objective monitoring, 87, 88–89 objective of, 209 performance reporting, 90–91 subjective monitoring, 87–88 Interface agreements, 57–58, 72, 86, 91, 92, 117, 130, 163, 180, 183, 196–197, 205, 209, 213–214, 225, 229, 231 Interface analysis, 25, 26, 33, 34, 37, 46, 55, 56, 57, 58–59, 59f. See also Project Diamond application in interface management, 94–95, 94f familiarization, 98 orientation and onboarding, 98 preparation, 97–99 process, 99–121 steps, 100, 100f top-down approach, 94 Interface areas, 56–60, 56f, 57f, 60f, 70–73,70f, 71f, 79, 82–84, 89, 91, 92, 94f, 95, 100 analysis, 111–115 approaches, 113–115 disciplines, 112, 114f examples, 83, 116f, 120 identification, 71, 71f, 72, 82–83, 83f predetermined, 113 resolution, 73, 82 specified, 113, 115 systems, 112–113, 114f Interface categories industry, 63, 65, 104 organizational, 61, 63, 65, 112

312

project, 63–64, 112 technical, 62–63, 62f, 72, 112, 177 Interface control document (ICD), 160–161, 163, 166–172, 196, 207, 211, 213, 225 application, 169–170 development, 167–168, 167f and interface register, 184–188, 196–197 and IVTM, 196–197 Project Diamond, 171–172 in project execution, 185–186 purpose, 167 style, content, and format, 169 U.S. DoD, 168–169 Interface control working groups (ICWGs), 170–172, 182–184 establishment, 171 interface groups versus, 171 management, 182–184 Project Diamond, 171–172 U.S. DoD, 171 Interface design reviews (IDRs), 204–207, 206f Interface entity relationship (IER), 107–111, 108f, 115 Interface groups, 54, 54f, 60f, 70–72, 77–82, 135–137. See also Interface parties analysis, 78–79 closeout, 231–232 designation, 78–79 ICWGs versus, 171 initiation, 56–58, 71–72 interactions between, 177–182, 179f KoM, 162–166, 177–178 matrix, 79–82, 80f, 107, 107f, 109, 110–111, 111f, 121, 135 meeting content, 182 objective, 57, 58 template for matrices, 107, 110, 110f Interface issues, 56–60, 56f, 57f, 60f, 61, 68, 70f, 74, 75, 77 analysis, 115–121 determination, 70f, 71, 71f, 72, 84–85, 84f resolution, 72, 91–92 Interface items, 56–60, 56f, 57f, 60f, 70f, 71f, 72, 83 closed, 88, 92, 146–147, 191, 196–197 high-priority, 90 identification, 71f, 72–73, 84–87, 84f, 85f “identified,” 89, 146, 147 open, 88, 89–90, 92, 146, 191, 197

Project Interface Management

“overdue,” 89–90, 147, 191, 194 planning, 85–87, 198–200, 199f resolution, 72, 86, 91–92 Interface management, 11, 26, 32, 34, 49–51, 59–61, 60f. See also Interface(s) aim/purpose, 9, 25 basic process model, 69–71, 70f bottom-up synthesis, 72–73 closeout process, 209–210, 231–233 common boundaries in, 51–58. See also Common boundary/Common boundaries contract strategy and, 22–23. See also Contract strategy definition, 51 driving factors, 1 forums, 203, 204f, 205, 206f, 207 goals, 50 implementation. See Interface management implementation interface analysis application in, 94–95, 94f internal, 160 in large-scale projects, 50–52, 61, 62, 64, 65, 126, 162, 170, 203, 204 link between SE and project management, 50–51, 68 planning. See Interface Management Plan (IMP) project phases, 71–73, 72f project sponsors, visibility by, 52 stakeholder analysis and, 45–46 systems approach to, 10, 213 top-down analysis, 72–73 Interface management implementation challenges to, 150–154 client/contractor interface kick-off meeting (KoM), 155–159. See also Kick-off meeting (KoM) contract award timing, 152–153, 152f contract terms, conditions, or scopes of work, 153–154 contractor transition period, 153 integration with other projects/existing systems, 151–152, 151f letter of intent (LOI), 154, 157 Interface Management Plan (IMP), 123–130, 141 documents, 125–126, 127 interface process, 129

Index

interface register, 124, 126, 127, 128, 129. See also Interface register organization and structure of entities, 129 overview, 123–127 project management and, 125, 142–144 roles and responsibilities of key interface positions, 129 Interface management procedure. See Interface Management Plan (IMP) Interface management strategy. See Interface Management Plan (IMP) Interface networks, 37, 42, 58, 61–62, 61f, 70–77, 133–135, 134f, 137–138 analysis, 76–78, 100–107, 100f, 101f determination, 71, 71f, 72, 73–77 examples, 74–76. See also Client internal project (CIP); Client’s prime contractor (CPC); Contractor internal (CI); Organization-to-organization (O2O); Project Diamond; Project sponsor-to-industry (PSI); Project-to-existing system (P2ES); Project-to-project (P2P) in large-scale capital projects, 74, 77 multiple, 103 output of analysis, 76–77 overview, 73–74 role of, 73–74, 77 Interface parties, 35, 52, 54f, 56–58, 61, 63, 64, 66, 70f. See also Interface groups analysis, 107–111 development schedules, 165 identification, 71, 71f, 72, 77–82 KoM, 159–162 LIP and, 129, 132, 161, 162. See also Lead interface party (LIP) tools and techniques for analysis, 107, 107f Interface points. See Interface areas Interface register, 82, 103, 124, 126, 127, 129, 130–140, 146, 147, 156f, 161–162, 176, 178 closeout, 232–233 database, 128, 130 establishment, 132, 132f functions, 130 ICD and, 184–188, 196–197 initiation, 132–133 interface groups, 135–137 interface networks, 133–135, 134f, 137–138, 193f

313

internal, 186–187 planning dates, 198–200, 199f priority process, 201, 202f setup, 131–140 tools, 95, 121, 130, 133, 180, 187, 201. See also Coreworx Interface Management (CIM); Web Interface Register (WIR) Interface training, 95, 121, 140–142, 161–162 initial, 140f, 141 introductory, 140–141, 140f maintenance, 140f, 142 Interface verification, 72, 167f, 196–197, 205, 207, 209, 211, 212–219, 225, 226, 228–230, 233 definition, 215 independence levels, 217 necessity for, 213–214 philosophy document, 214 purpose, 215 and quality, 214–215, 217 technical compliance and integrity, 212–213, 217–219, 218f, 221–224 techniques, 216 Interface verification traceability matrix (IVTM), 196, 204, 207 International Council on Systems Engineering (INCOSE), 17–18 Complex Systems Working Group, 25–26 interface verification purpose, 215 Organizational Project-Enabling Processes, 65 SE and stakeholder analysis, 42–43 system architecture, 73. See also System architecture technical interfaces, 63 IVTM. See Interface verification traceability matrix (IVTM) Kamensky, John, 27 Kerzner, Harold, 8 Key performance indicators (KPIs), 72, 88, 89–91, 145–148, 147f interface, 145–147, 147f Project Diamond, 147–148 Kick-off meeting (KoM) client/contractor interface, 155–159 client-sponsored meetings, 158–159 interface group, 162–166, 177–178 interface party, 159–162

314

internal meetings between client and contractor, 157–158 project sponsor structure/organization, 155–157, 156f sequence, 155, 155f KoM. See Kick-off meeting (KoM) Kongsberg WIR, 130, 131, 176 KPIs. See Key performance indicators (KPIs) Large-scale capital projects, 11–14, 19, 25, 130, 141, 146. See also Project Diamond challenges, 11, 18, 32, 177 change management, 142 complexity, impact on, 10, 11, 14, 23, 29–30, 32 infrastructure, 12–14. See also Infrastructure projects interaction intensity, 36 interface management, role in, 50–52, 61, 62, 64, 65, 126, 162, 170, 203, 204 interface networks in, 74, 77 monetary waste, 12 performance, 12 risk management, 143–144 Lead interface contractor (LIC), 137, 191, 196, 228 Lead interface party (LIP), 102, 178, 194, 196 establishment, 77–82, 107, 109–111, 111f, 135, 137 interface parties and, 129, 132, 161, 162 roles and responsibilities, 82 LIC. See Lead interface contractor (LIC) LinkedIn, 73, 100 LIP. See Lead interface party (LIP) London Crossrail project, 13 Mastering Project Portfolio Management, 5–6 McGrath, Rita Gunther, 27 Merrow, Edward W., 1, 11, 221 Miscommunication, 32, 50, 77, 141 Multiple contracts, 21–23 O2O. See Organization-to-organization (O2O) Oil and gas industry, 8, 16–17, 16f, 19, 34, 50, 75, 79–81, 80f, 95, 165. See also Project Diamond OPMT. See Organization politics mapping tool (OPMT) Organization politics mapping tool (OPMT), 41

Project Interface Management

Organization-to-organization (O2O), 74, 76, 101f, 102, 104, 106f, 110, 134f, 189, 194, 195f P2ES. See Project-to-existing system (P2ES) P2P. See Project-to-project (P2P) Panama Canal expansion project, 13 PCP. See Project change management (PCP) Peters, Tom, 149, 150, 154 PGL. See Project Gas Pipeline (PGP) PMBOK®. See Project Management Body of Knowledge (PMBOK ® Guide) PMI. See Project Management Institute (PMI) PMOs. See Project, Program, or Portfolio Management Offices (PMOs) POL. See Project Oil Pipeline (POL) Portfolio management, 1, 6–8, 65. See also Project portfolio management (PPM) Power/influence grid, 41, 41f Power/interest grid, 41 PPM. See Project portfolio management (PPM) Prehistory, 2 Prime Contractor Internal (PCI). See Contractor Internal (CI) Procurement, 8, 17, 39, 53, 64. See also Engineering, procurement, and construction (EPC) Profile analysis meetings, 41–42 Program Management Improvement and Accountability Act (2016), 7 Project assurance, 210–212, 213, 217, 226 Project change management (PCP), 143, 184, 203 Project charter, 39 Project complexity. See Complexity Project development process, 14–17. See also Stage-Gate model capital investments, 14 decision points/decision gates, 14, 15, 16, 17 definition, 8 oil and gas project, 16–17, 16f phases, 14–15 types, 15 U.S. DoD, 15–17, 16f. See also Department of Defense (DoD) Project Diamond, 95–97, 141, 143 contract award timeline, 152–153, 152f ICD, 171–172 ICWG, 171–172

Index

integration with other projects, 151–152, 151f interface areas, 116f, 120 interface group matrices, 110–111, 111f interface networks, 103–107, 106f, 112, 115, 133–135, 134f, 137–138, 190f, 192f interface performance overview, 189–196, 190f, 192f, 193f KoM sequence, 158–159, 158f KPIs, 147–148 overview, 96–97 project execution plan (PEP), 97, 99, 101, 101f, 111, 125 structure/organization, 155–157, 156f technical compliance and integrity (TCI) model, 226–231, 227f topside EPC, 108f, 109, 111, 187, 188f, 193f, 195f Project documents, 99, 101, 109, 125, 127 Project Gas Pipeline (PGP), 96, 104, 114f, 115, 116f, 158, 194 Project management, 1, 7–11. See also Interface management accelerating pace of change and, 10, 19, 23 benefits management, 10–11 complexity, influence on, 28–30 definition, 8 dynamic, 12, 21, 22, 30 emergence, 7–8 goal, 9 IMP and, 125, 142–144 project constraints, balancing of, 9 scope certainty, 9 stakeholder analysis process, 39–42. See also Stakeholder analysis systems engineering and, 18–19, 45–46 Project Management Body of Knowledge (PMBOK® Guide), 39, 40, 46 Project Management Institute (PMI) benefit definition, 11 knowledge areas, 63–64, 112 PPM definition, 7 primary goal, 8 project definition, 32 Pulse of the Profession survey, 11, 12 stakeholder analysis, 39–42. See also Stakeholder analysis Project managers, 28, 29, 32–33, 76, 125–126, 130, 156f, 221, 229, 230

315

Project Oil Pipeline (POL), 96, 104, 114f, 115, 116f, 158, 194 Project plan offsets, 197–201 Project portfolio management (PPM), 6–7 Project, Program, or Portfolio Management Offices (PMOs), 8, 76 Project Sapphire, 96, 104, 106f, 115, 116f, 134f, 151, 158, 158f, 171, 189, 194, 227f, 229, 230 Project sponsors accelerating change, impact on, 10 contracting strategies by, 20–22 effect on project management, 20, 29, 32 goals, 50 interface groups, identification by, 54, 78 interface management by, 52, 78, 93 organization, 94, 100, 101, 125, 126 project development review by, 14–15 stakeholder analysis and, 42 structure, 155–157, 156f Project sponsor-to-industry (PSI), 74, 101f, 102, 104, 106f Project-to-existing system (P2ES), 74, 75, 101f, 102, 194 Project-to-project (P2P), 74, 75, 76, 101f, 102, 104, 106f, 110, 115, 116f, 133, 134f, 138, 158, 158f, 171 PSI. See Project sponsor-to-industry (PSI) RACI (responsible, accountable, consult, inform) matrix. See Responsibility matrix Reduction, 27–28 Responsibility matrix, 78, 82, 161, 211 Risk, 9, 18, 20–22, 183 execution, 82 integration, 82 interdependency, 95 management, 11, 55, 59, 61, 64, 99, 142, 143–144, 144f mitigation, 27, 52, 64, 105, 112 reduction, 209, 233 register software products, 144 white space, 82 Riyadh Metro, 13 Safety automation system (SAS), 105, 106f, 108f, 115, 134f Salience model, 41 Sargut, Gökce, 27

316

SAS. See Safety automation system (SAS) Scientific Revolution, 2–3, 7 Scope certainty, 9, 20 SE. See Systems engineering (SE) Seaflex WIR, 134f, 176, 178, 179f, 181f, 188f, 198–199, 200 SEBoK. See Systems Engineering Body of Knowledge (SEBoK) Shuman, J., 133, 135, 137, 138–139 Societal evolution, 2–3 SoI. See System-of-interest (SoI) Sphere of influence, 30, 34, 37, 38 Stage-Gate® model, 15, 15f Stage-gate process, 14–15, 15f, 39, 63. See also Decision gates (DG) Stakeholder analysis, 39–45 architecture framework views for identification, 40 inputs, 39–40 interface management and, 45–46 outputs, 42, 46 project management, 39–42 systems engineering and, 38, 39, 42–46. See also Business or mission analysis (B/MA) tools and techniques, 40–42, 41f Stakeholder(s), 6, 8, 11, 18, 25, 29 analysis. See Stakeholder analysis classes, 37–39 complexity, 37–45 entities, 30, 38, 38f, 41 external, 30, 38, 39 interface, 50 internal, 30, 38, 39 needs and requirements (SNR), 44–45 primary/business actors, 30 register, 39, 42 regulators, 30 relationships, 28, 40–41 secondary/nonbusiness, 30, 38 Strategic planning/Strategic plan, 6, 7 Strategy development/Strategic development, 5–6 System, 32–33. See also System complexity System architecture, 19, 34, 57, 58, 59f, 60f, 73, 74, 79, 81, 84, 92, 95, 110, 119, 133, 141, 172, 184–186, 207, 212, 222, 225, 230, 231 System complexity, 32–34, 49, 119, 169 System integrity, 18, 115, 204, 211, 218, 218f, 220f, 224–225, 229–230

Project Interface Management

assurance, 58 responsibility, 79, 105, 229 System-of-interest (SoI), 43, 44 Systems engineering (SE), 1, 15, 17–19, 166. See also Interface management complexity, impact on, 28–29 definition, 17 project management and, 18–19, 45–46 stakeholders and, 38, 39, 42–46. See also Business or mission analysis (B/MA) uses, 18 Systems Engineering Body of Knowledge (SEBoK), 39, 43–46, 61, 63, 217 Systems engineers, 17–18, 28, 119 Systems thinking, 17–18 Technical compliance, 204, 205, 207, 209, 211, 212–213, 217–219, 220f, 221–223, 226–231, 227f. See also Integrity Technical integrity, 17, 58, 130, 211, 218, 218f, 220f, 223–224, 228–229 Technology, 27, 28, 30, 112, 139, 169, 178, 194, 221 advancement in, 3–5, 9–10, 19–20, 23, 115, 185, 233 disruptions, 89 information, 65, 95 proprietary, 126, 168 Telecommunication, 12, 14, 33, 83, 95, 114f, 129, 132, 165, 178 Transportation, 8, 13, 17, 19, 81, 83, 176, 211 Turnkey approach, 22 Twombly, J., 133, 135, 137, 138–139 Uncertainty, 20, 27, 29, 32, 77, 213 U.S. Department of Defense (DoD). See Department of Defense (DoD) Value/Values creation, 14–15, 20, 29, 32, 96, 219–221, 220f organizational, 6 Web Interface Register (WIR) Kongsberg, 130, 131, 176 Seaflex, 134f, 176, 178, 179f, 181f, 188f, 198–199, 200 WIR. See Web Interface Register (WIR)