Project Management Project Scope

User Generated


Business Finance


Option #1: Case Study Process: Project Scope

The purpose of this assignment is to help you to understand how to analyze and produce a report on a case study.

First, read the 5-step process on “How to Analyze a Case Study” found on the following Pearson website:

Next, read the case study: “Project Anatomy” on pp. 92-98 of your textbook, Case Studies in Project, Program, and Organizational Project Management (Attached). Apply the 5-step case study analysis process from the Pearson website and write a 2- to 3-page case study report. Be sure to address the organization’s environment, the organization’s stakeholders, and the strategic options. Relate your analysis to the questions listed at the end of the case and justify your conclusions with references to the case.

Your case study report should meet the following requirements:

  • Your complete report should be 3-4 pages long.
  • Format your paper per the APA Guidelines
  • Cite at least three current scholarly resources, to support your assertions. One of the sources may be your textbook (Attached).

Unformatted Attachment Preview

CASE STUDIES IN PROJECT, PROGRAM, AND ORGANIZATIONAL PROJECT MANAGEMENT Dragan Z . Milosevic, Peerasit Patanakul & Sabin Srivannaboon Copyright 02010 by John Wiley & Sons, Inc. All rights reserved. CASE STUDIES IN PROJECT, PROGRAM, AND ORGANIZATIONAL PROJECT MANAGEMENT CASE STUDIES IN PROJECT, PROGRAM, AND ORGANIZATIONAL PROJECT MANAGEMENT DRAGAN Z. MILOSEVIC PEERASIT PATANAKUL SABIN SRIVANNABOON John Wiley & Sons, Inc. This book is printed on acid-free paper. Copyright © 2010 by John Wiley & Sons, Inc. All rights reserved. Published by John Wiley & Sons, Inc., Hoboken, New Jersey Published simultaneously in Canada No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600, or on the web at Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at Limit of Liability/Disclaimer of Warranty: While the publisher and the author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor the author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages. For general information about our other products and services, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. For more information about Wiley products, visit our web site at “PMI”, the PMI logo, “OPM3”, “PMP”, “PMBOK” are registered marks of Project Management Institute, Inc. ( For a comprehensive list of PMI marks, contact the PMI Legal Department. Library of Congress Cataloging-in-Publication Data: Case studies in project, program, and organizational project management / [edited by] Dragan Z. Milosevic, Peerasit Patanakul, Sabin Srivannaboon. p. cm. Includes index. ISBN 978-0-470-18388-5 (pbk.) 1. Project management--Case studies. 2. Project management--Standards. I. Milosevic, Dragan. II. Patanakul, Peerasit. III. Srivannaboon, Sabin, 1977HD69.P75C375 2010 658.4⬘04--dc22 2009045965 Printed in the United States of America 10 9 8 7 6 5 4 3 2 1 To Dragana, Jovana, and JR —Dragan Z. Milosevic To my parents, Arun and Soisalinee; my wife, Severine; and my children, Ananya and Yanat —Peerasit Patanakul To my father, Sabieng, my mother, Songsee, and my lovely wife, Jany —Sabin Srivannaboon Contents Preface xv Structure of the Book xvii The Principles of Management Acknowledgments xxii xxi PART I: CASE STUDIES IN PROJECT MANAGEMENT CHAPTER 1 INTRODUCTION 3 ● AaronSide Goes to Teams 5 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon ● Cocable Inc. 7 Jovana Riddle ● A RobustArm Global Industries’ Sledgehammer 10 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon ● Another Trojan Horse Stevan Jovanovic ● Call a Truck 15 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon ● The Project Hand-off Method 17 Dragan Z. Milosevic, Russ J. Martinelli, and James M. Waddell CHAPTER 2 12 CULTURAL ASPECTS OF PROJECT MANAGEMENT 19 ● Engineering Culture at Beck 21 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon ● The Jamming 26 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon vii viii CONTENTS CHAPTER 3 PROJECT MANAGEMENT PROCESSES ● Special Session 31 Sabin Srivannaboon ● Waterfall Software Development Osman Osman ● Extreme Programming Mani Ambalan ● Do You ZBB? Rabah Kamis CHAPTER 4 36 42 49 PROJECT INTEGRATION MANAGEMENT ● The Abacus Project 57 Peerasit Patanakul and Jospeph Genduso ● The Ticketing System Mathias Sunardi ● WRQ Software Development 73 Peerasit Patanakul and Michael Adams CHAPTER 5 29 55 69 PROJECT SCOPE MANAGEMENT 83 ● Workshop: Project Definition 85 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon ● Work Breakdown Structure as a Skeleton for Integration Wilson Clark and Dragan Z. Milosevic ● Project Anatomy 92 Joakim Lillieskold and Lars Taxen ● Rapid Prototype for Fast Profits Stevan Jovanovic CHAPTER 6 89 99 PROJECT TIME MANAGEMENT 103 ● How Long Does It Take to Catch a Fish—TAD? Ferra Weyhuni ● Workshop: The Jogging Line in Action 111 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon ● Sequencing 114 Art Cabanban ● The Rolling Wave Dan Itkes 121 105 ix Contents ● Schedule Accuracy 128 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon ● AtlasCom 130 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon ● Workshop: The Milestone Chart 133 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon CHAPTER 7 PROJECT COST MANAGEMENT 137 ● The Court House Disaster 139 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon ● Bad Metrics for Earned Value Don Hallum ● The Museum Company Jovana Riddle ● Workshop: Parametric Estimate 152 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon ● No Bottom-up Estimate, No Job! 155 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon ● Earned Tree Analysis Dragan Z. Milosevic CHAPTER 8 141 149 158 PROJECT QUALITY MANAGEMENT 161 ● Robots Fail Too Ferra Weyhuni ● The Peaceful Black Belt Marie Ann Lamb ● Workshop: Project Quality Program 172 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon CHAPTER 9 163 167 PROJECT HUMAN RESOURCE MANAGEMENT 175 ● The Bully, Subversive, Prima Donna, Etc. Diane Yates ● Startups Born with Conflicts Priya Venugopal ● We Do Not Speak the Same Language Diane Yates 177 183 185 x CONTENTS ● My Job Was to Integrate Two Cultures 190 Dragan Z. Milosevic, Russ J. Martinelli, and James M. Waddell ● Rate and Rank Rabah Khamis 192 CHAPTER 10 PROJECT COMMUNICATIONS MANAGEMENT ● The Russians Join Us Late at Night 205 Dragan Z. Milosevic, Russ J. Martinelli, and James M. Waddell ● Quest for Clear 207 Mathias Sunardi ● Electronic Medical Record 213 Mathius Sunardi and Abdi Mousar ● Improving Public Health Informatics Abdi Mousar ● A Simple Metric Goes a Long Way Art Cabanban ● Executive Project Metrics 225 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon CHAPTER 11 217 223 PROJECT RISK MANAGEMENT ● Risk Policies in Project Russia Dragan Z. Milosevic ● Risk under the Microscope Ferra Wayahuni ● Monte Carlo in Italy Meghana Rao ● Probability and Impact Jovana Riddle 203 229 231 237 242 245 CHAPTER 12 PROJECT PROCUREMENT MANAGEMENT ● The $30,000 Frigidaire Dragan Z. Milosevic ● Mountain of Iron, Mountain of Dollars Dragan Z. Milosevic 249 252 247 xi Contents PART II: CASE STUDIES IN PROGRAM MANAGEMENT CHAPTER 13 THEMES OF PROGRAM MANAGEMENT 257 ● KUPI 259 Sabin Srivannaboon, Dragan Z. Milosevic, and Peerasit Patanakul ● The Bounding Box Boxes You Sabin Srivannaboon 261 CHAPTER 14 PROGRAM INITIATING PROCESS 269 ● Business That Operated Without Knowing Where Its Profits Came From 271 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon ● Mega Security® 273 Sabin Srivannaboon CHAPTER 15 PROGRAM PLANNING PROCESS 277 ● Quick Release 279 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon ● The Budica Program 281 Diane M. Yates and Dragan Z. Milosevic ● Best Practices Overview—Program Scheduling 289 Sabin Srivannaboon, Dragan Z. Milosevic, and Peerasit Patanakul ● Expect the Unexpected Sabin Srivannaboon 291 CHAPTER 16 PROGRAM EXECUTING PROCESS 297 ● The Program Strike Zone 299 Sabin Srivannaboon, Dragan Z. Milosevic, and Peerasit Patanakul ● The Program Map 302 Sabin Srivannaboon, Dragan Z. Milosevic, and Peerasit Patanakul ● Using Tools on a Mercedes 305 Sabin Srivannaboon and Dragan Z. Milosevic CHAPTER 17 PROGRAM MONITORING AND CONTROLLING PROCESS 313 ● I Have Only Three Minutes a Month! 315 Dragan Z. Milosevic, Russ J. Martinelli, and James M. Waddell xii CONTENTS ● OSSOP! 317 Sabin Srivannaboon ● That Which Is Not Earned Is Never Valued Sabin Srivannaboon 324 CHAPTER 18 PROGRAM CLOSING PROCESS AND PROGRAMS IN ACTION 327 ● A Checklist 329 Sabin Srivannaboon, Dragan Z. Milosevic, and Peerasit Patanakul ● General Public Hospital 331 Peerasit Patanakul and Dragan Z. Milosevic ● American Shogun 341 Bjoern Bierl and Andrea Hayes-Martinelli ● Planet Orbits 348 Peerasit Patanakul and Dragan Z. Milosevic ● ConSoul Software 357 Andrea Hayes-Martinelli and Dragan Z. Milosevic PART III: CASE STUDIES IN ORGANIZATIONAL PROJECT MANAGEMENT CHAPTER 19 ALIGNMENT AND PORTFOLIO MANAGEMENT 375 ● LorryMer Information Technology 377 Sabin Srivannaboon and Dragan Z. Milosevic ● Who Owns the Portfolio? 385 Dragan Z. Milosevic and Peerasit Patanakul ● Our Portfolio Stinks 387 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon CHAPTER 20 STANDARDIZED METHODOLOGIES 389 ● Standardized Program Risk Management Peerasit Patanakul ● Go With the Template Always Murugappan Chettiar ● We Do Not Need Standard Methodology 400 Peerasit Patanakul, Sabin Srivannaboon, and Dragan Z. Milosevic ● Joy Knows How to Defend 403 Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon 391 395 xiii Contents CHAPTER 21 COMPETENCIES OF PROJECT MANAGERS AND THE PROJECT MANAGEMENT OFFICE ● They Are Business Leaders at Spotlight Corporation Peerasit Patanakul and Dragan Z. Milosevic ● The Program Management Office 417 Sabin Srivannaboon and Dragan Z. Milosevic ● Progress—One Step at a Time 425 James Schneidmuller and Peerasit Patanakul 407 409 CHAPTER 22 INFORMATION SYSTEMS, ORGANIZATION, AND METRICS 435 ● Is It Information Systems That We Need? Peerasit Patanakul and Sung Han ● Spreadsheet Is Everything 445 Peerasit Patanakul, Sabin Srivannaboon, and Dragan Z. Milosevic ● R&D and Operations: How to Make Them Talk Priya Venugopal ● Bluedogs USA 453 Nicolas Charpenel ● Point of Contact 465 Peerasit Patanakul, Sabin Srivannaboon, and Dragan Z. Milosevic 437 448 CHAPTER 23 ORGANIZATIONAL CULTURE AND PROGRAM CULTURE 467 ● What Helps Us Come This Far? Peerasit Patanakul ● Is It Standard Methodology That We Need? Peerasit Patanakul 469 475 CHAPTER 24 ORGANIZATIONAL PROJECT MANAGEMENT IN ACTION 481 Index ● Let’s Go All the Way 483 James Staffan and Peerasit Patanakul ● Are We Ready for Portfolio Management? Peerasit Patanakul 499 493 Preface Traditionally, the use of case study has been largely emphasized in many disciplines. People use cases in different manners from theory building, to theory testing, to description, or even to simple explanation. Nevertheless, learning is always one ultimate goal in which we center our attention on the gravity of the problems and issues in the case, regardless of any purpose. In particular, the learning occurs when we dissect the case, identify issues or problems in it, and then discuss or solve them. In the field of project management, case studies as well have been one of the main sources and tools used for professional development and higher education. Over the years, the Project Management Institute (PMI) has attempted to get a large number of authors to contribute to case studies in project management. The idea is to use these cases as a means to accelerate the project management learning. This is also similar to academia where a number of cases are integrated into textbooks. A few standalone case books dedicated to project management are also available. However, what is critically missing is a comprehensive case study book where it meets diverse needs of the readers at large. To be more specific, there is no book that has project management cases arranged in an orderly fashion that comprehensively addresses various knowledge areas, different process groups, and the global best practice standards. In particular, there are very few cases in program management and organizational project management, even though the two areas are now recognized as two standalone disciplines, and officially standardized by PMI. We believe this book is the first of its kind to deal with the management of projects from a hierarchy perspective: project, program, and organization. The purpose of this book is to maximize the readers’ learning experiences through the use of case studies, which we believe will allow our readers to carefully think and enrich their understanding of the concepts and practices in project management. In attempting to capture various aspects of project management, we have written 90 cases, each of which was triangulated by professionals with xv xvi PREFACE different expertise varying from engineers to industrial psychologists, to quality computer experts, to software programmers, to businesspersons’ service providers, and to organization specialists. These cases are factual from real people and actual companies in different industries, settings, or cultures with diverse sizes and types of projects, although we used fictitious names to conceal their identities. Our goal is to highlight the applications and practices of project management, program management, and organizational project management in real-world settings. The book is designed to address multiple groups of people with different needs that include but are not limited to: ● ● ● Executives, program and project managers: This book will help executives and program and project managers improve their management knowledge regarding projects, programs, and organizations. We present cases that discuss many best practices and lessons learned from such management in actual companies across industries. Academics and consultants: For academics, this book is a good resource of project management, and a recommended accompanying reading for their project management, program management, and organizational project management classes. The students may use this book as a reference or as a required text since the cases can well support any basic textbooks of the class, whether it is a project management, program management, or organizational project management class. For consultants, this book provides many real-world stories in which the frameworks for project and program management as well as organizational project management were implemented. They can easily incorporate a number of cases in this book, or use the entire book for their in-class trainings. CAPM®, PMP®, and PgMP® candidates: This book perfectly aligns with the standards created by PMI, and provides important details necessary for the CAPM® (Certified Associate in Project Management), PMP® (Project Management Professional), PgMP® (Program Management Professional) certification exam preparations. For each individual, excellence in project management comes from both theoretical knowledge and practical experiences. Either one of these alone would not be sufficient in today’s era of hypercompetition. After reading this book, we believe that our readers will gain such knowledge and learn from experiences shared by other project management practitioners. All in all, this book just captures small stories. We hope, however, that these stories will serve as building blocks to drive excellence in project management, which is undoubtedly one of the fastest growing disciplines today. Structure of the Book This book offers a number of case studies that demonstrate effective use of project and program management methodologies, as well as organizational project management practices. Drawn from a variety of industries and regions, the case studies capture real-world situations, challenges, best practices, and lessons learned both from successful and not-so-successful perspectives. In order for our readers to best learn project management, we have categorized and arranged our cases into two different dimensions: case types and parts. CASE TYPES We classify our cases into three different types: critical incidents, issue-based cases, and comprehensive cases. The three case types differ in length and specificity, which are described as follows: ● ● ● Critical incidents are written in the form of short stories that illustrate an issue or a problem related to project, program, and organizational project management. Issue-based cases provide more information than critical incidents. They handle two or more issues either in project management, program management, or organizational project management. Comprehensive cases are the longest in length. They feature multiple issues or the entirety of the project, program, or organizational project management. The purpose of these different levels is to offer the reader different categories of the learning skills, contingent on their experience. This way they can use this book to customize learning needs. In addition, the book has both open-ended cases, where we don’t show the final outcome of the story, and close-ended cases, where the final outcomes are presented for further discussion. xvii xviii STRUCTURE OF THE BOOK While the case types are different, their structure across different parts is similar. Each case includes an introduction, main body, conclusion, and discussion items. PARTS In addition to the case types, we adopt the standards created by PMI, the leading global association for the project management profession, to arrange our cases. Namely, these standards are “A Guide to the Project Management Body of Knowledge” (the PMBOK® Guide), “The Standard for Program Management,” and “The Organizational Project Management Maturity Model (OPM3®).” We follow these standards, and organize our cases and chapters into three different parts: Project Management (Part I), Program Management (Part II), and Organizational Project Management (Part III), (see Figure i). ● ● ● We organize Part I based on the PMI’s PMBOK® Guide, which addresses the introduction, project life cycle, and organization (Chapter 1), project management processes for a project (Chapter 3), and the nine knowledge areas (Chapters 4 to 12). Added to that are the cultural aspects of project management (Chapter 2), in which we strongly feel that culture, whether it is corporate, project, or regional, plays a significant role in achieving project goals. In sum, Part I has a total of 52 cases. We structure Part II based on the process groups of the PMI’s Standard for Program Management, including the Initiating, Planning, Executing, Monitoring and Controlling, and Closing processes (Chapters 14 to 18). We also offer cases about the themes of program management (Chapter 13), and program management in action (Chapter 18) for further discussion. There are a total of 19 cases in Part II. Part III focuses on issues in organizational project management, which address some of the best practices in the Organizational Project Management Maturity Model (OPM3®). This part presents cases related to strategic alignment and project portfolio management (Chapter 19), standardized methodologies (Chapter 20), and competencies of project managers and project management office (Chapter 21). We also present cases on information systems, organization, and metrics (Chapter 22) and organizational and project or program culture (Chapter 23). Cases on organizational project management in action are presented in Chapter 24. There are a total of 19 cases in Part III. xix Structure of the Book Figure i Structure of the Book Part I Project Management Part II Program Management Part III Organizational Project Management Cases are organized based on the PMBOK Guide. Cases are organized based on the Standard for Program Management. Cases are connected to Organizational Project Management Maturity Model (OPM3). Case 3 Case 1 Case 2 Case 3 Case 1 Case 2 Case 3 ... ... Case 19 Chapter 19 – Chapter 24 Case 2 Chapter 13 – Chapter 18 Case 1 .......... Chapter 1 – Chapter 12 Cases are designed with specific management outcomes and based on realworld information and actual companies. Case 19 Case 52 Read and understand the cases for specific management outcome. The Principles of Management EQUIFINALITY Equifinality, a term from systems science, refers to the principle through which multiple means (different inputs and processes) may lead to a same end in open systems. CONTINGENCY Contingency, in management terms, refers to one of several approaches one might take in dealing with a condition, situation, or set of circumstances involving uncertainty. In other words, after examining alternatives to find the most appropriate solution, another possible solution might be considered if the first one doesn’t work out (a “Plan B,” so to speak). xxi Acknowledgments To complete the book, we owe gratitude to many people. First, we’d like to thank our co-authors who helped us in writing a number of the outstanding cases or provided many valuable inputs for the case write-ups. These people are: Abdi Mousar, Andrea Hayes-Martinelli, Art Cabanban, Bjoern Bierl, Diane Yates, Don Hallum, Ferra Weyhuni, James M. Waddell, James Schneidmuller, James Staffan, Joakim Lillieskold, Joseph Genduso, Jovana Riddle, Lars Taxen, Mani Amabalan, Marie-Anne Lamb, Mathius Sunardi, Meghana Rao, Michael Adams, Murugappan Chettiar, Nicolas Charpenel, Osman Osman, Priya Venugopal, Rabah Kamis, Russ J. Martinelli, Stevan Jovanovic, Sung Han, and Wilson Clark Our sincere thanks to many of our colleagues, co-workers, and previous organizations or those we have been involved with in the past for the knowledge and information we gained and used for this book. Finally, we are deeply grateful to our institutions, namely the Department of Engineering and Technology Management (Portland State University, USA), Wesley J. Howe School of Technology Management (Stevens Institute of Technology, USA), and Sasin GIBA of Chulalongkorn University (Thailand) for their support and environment, which enabled us to complete this book. xxii CASE STUDIES IN PROJECT, PROGRAM, AND ORGANIZATIONAL PROJECT MANAGEMENT Dragan Z . Milosevic, Peerasit Patanakul & Sabin Srivannaboon Copyright 02010 by John Wiley & Sons, Inc. All rights reserved. Part I CASE STUDIES IN PROJECT MANAGEMENT WHAT IS PROJECT MANAGEMENT? It is well recognized that project management has been practiced since early civilization. The evidences from past history to the present are abundant: the construction of the Great Pyramids of Giza in the ancient world, the Great Wall of China construction in the 16th century, and the London Millennium Bridge in the globalization era. Without project management, these structures would not have existed. With a competitive business environment, many organizations nowadays use projects not only to build structures, to implement changes, or to introduce new products, but also as a way to put strategies into action. Despite multiple meanings of a project, the one defined by Project Management Institute (PMI) is perhaps the most widely known definition. According to PMI, a project is a temporary endeavor undertaken to create a unique product, service, or result.1 With its temporary nature, a project is often perceived as standing on the opposite spectrum of business as usual; it is often referred to as an “operation” by project management scholars. As projects differ from operations, managing projects therefore 1 A Guide to the Project Management Body of Knowledge, 4th ed., Project Management Institute, 2008, p. 5. 1 2 CASE STUDIES requires a discipline2 of planning, organizing, and managing resources to bring about the successful completion of specific goals and objectives. This discipline is referred to as project management. The discipline of project management has evolved from different fields of application. The work of Frederick Winslow Taylor on theories of scientific management is considered to be the foundation of project management tools, such as the Work Breakdown Structure. The Gantt chart, developed by Henry Gantt, is recognized as a forefather of project management planning and control techniques. And the work of Henri Fayol on management functions is the foundation of project and program management body of knowledge. However, it wasn’t until the middle of the 20th century that project management was recognized as a formal discipline3; emerging from the construction of the first atomic bomb during World War II (the project known as the Manhattan Project). Since then, more and more new processes and disciplines have emerged that support the use of project management, including Time Quality Management (TQM) in 1985, concurrent engineering in 1990, and reengineering in 1993, just to name a few. As a result, more and more project management tools and techniques have emerged, including the Critical Path Method (CPM) and Program Evaluation and Review Technique (PERT) in the 1950s, and the Critical Chain Project Management in 1997. As the discipline of project management has grown, the standards governing the field have also evolved. While each organization practicing project management may develop its own criteria, several national and international organizations have proposed project management standards. These standards are, for example, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) from the Project Management Institute in the United States and PRINCE2: 2009 Refresh (PRoject IN Controlled Environment) from the Office of Government Commerce in the UK. Among these standards, the PMBOK Guide receives strong recognition from project management communities. The PMBOK Guide suggests nine knowledge areas of project management: integration management, scope management, time management, cost management, quality management, human resource management, communication management, risk management, and procurement management. These knowledge areas are used as skeletons for organizing case studies in Part I. 2 David I. Cleland and Roland Gareis, Global Project Management Handbook, McGraw-Hill Professional, 2006. 3 Aaron J. Shenhar and Dov Dvir, Reinventing Project Management: The Adaptive Diamond Approach, Harvard Business School Press, 2007. CASE STUDIES IN PROJECT, PROGRAM, AND ORGANIZATIONAL PROJECT MANAGEMENT Dragan Z . Milosevic, Peerasit Patanakul & Sabin Srivannaboon Copyright 02010 by John Wiley & Sons, Inc. All rights reserved. Chapter 1 INTRODUCTION Chapter 1 presents examples of organizations that have recognized the importance of projects as an engine of their growth or a survival mechanism during economic turbulence. Various efforts of these organizations in response to the need for project management, therefore, were initiated. In this chapter, there are six case studies: five critical incidents and one issue-based case. The cases generally discuss a number of concepts (e.g., organizational structures), that can be found in Chapters 1 (Introduction) and 2 (Project Life Cycle and Organization) of A Guide to the Project Management Body of Knowledge (the PMBOK® Guide). 1. 2. 3. 4. 5. 6. AaronSide Goes to Teams Cocable Inc. A RobustArm Global Industries’ SledgeHammer Another Trojan Horse Call a Truck The Project Hand-off Method These cases demonstrate different situations where companies made the transition from non-project-oriented organizations to project-oriented ones. To capture the transition efforts from multiple views and settings, we offer cases from different industries: “AaronSide Goes to Teams” is in the metal machining industry; “Cocable Inc.” is in cable manufacturing business; “A RobustArm Global Industries’ SledgeHammer” providesbuilding materials; “Another Trojan Horse” 3 4 CASE STUDIES is in the nuclear industry; “Call a Truck” offers shipping and transportation services; and “The Project Hand-off Method” is from the field of medical equipment manufacturing. CHAPTER SUMMARY Name of Case Area Supported By Case Case Type Author of Case Project Management Organization (Functional vs. Matrix Structure) Project Management Organization (Training by Doing) Project Management Organization (Standardized Project Management) Critical Incident Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon Critical Incident Jovana Riddle Critical Incident Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon Issue-based Case Stevan Jovanovic Call a Truck Project Management Organization (Training) Project Management Organization (Matrix Structure) Critical Incident Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon The Project Hand-off Method Project Management Process Critical Incident Dragan Z. Milosevic, Russ J. Martinelli, and James M. Waddell AaronSide Goes to Teams Cocable Inc. A RobustArm Global Industries’ Sledgehammer Another Trojan Horse AaronSide Goes to Teams Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon It took AaronSide, Inc. almost 80 years to grow from a small mom-and-pop business to a company that held the largest market share internationally. What made this feat special was that a single family owned the company since its inception. It is suffice to say that this success made owners, management, and all employees more than proud. A WALL IS BETWEEN US Operating in the metal machining industry, AaronSide’s organization was perfected over time through experience and many saw this as a competitive advantage. Basically, it was an efficient, functional organization where marketing, engineering, and manufacturing with a strong quality group played a major role. The engineering department achieved the fastest 16-month lead time for a new product development project when compared with competitors. Fundamentally, product development was an operation that worked like a well-oiled machine. It started with marketing, which did market research and then threw the specification of what customers desired “over the wall” to the engineering department, which released final drawings to manufacturing, which made the quality product. The approach was called the relay race. Its secret was an efficient, functional department. Typically, if you worked in a specific department, say marketing, you would never talk to a guy from a different engineering. If you did, you might be reprimanded. Indeed, departments talk to each other, not individuals that belong to different departments. How do departments converse? Usually, only heads of departments are authorized to speak on behalf of their staff. TO SURVIVE, CHANGE IS REQUIRED The more intense globalization of business brought more international competition. The two largest rivals in the industry from Europe, subsidiaries of the large multinational organizations, largely expanded their operations in the U.S. market. 5 6 CASE STUDIES This is when problems for AaronSide began to mushroom. AaronSide found it difficult to compete with the Europeans, who had access to resources and new management of their rich parents. As a result, AaronSide slipped to a close third in market share, behind the European rivals. Freefall continued and by 1990, AaronSide was the distant third. Several management teams were replaced during this period, new manufacturing equipment was installed, the company was seriously reengineered, and different management was used to catch up with the leaders without significant results. So, AaronSide became ripe for a sale. After talking with four suitors from the United States and Europe over the last several years, owners concluded that the best offer for purchase of AaronSide was one from Titan Corp, a Swedish company. So, after almost 90 years of being family-owned, AaronSide became a wholly owned subsidiary of a large multinational firm. To facilitate the integration of AaronSide into Titan Corp’s network of companies, the management team of AaronSide was retained. The first initiative of the new owner was to direct AaronSide to commission a pilot project management team (in manufacturing companies usually referred to as concurrent engineering teams), cross-functional in nature, and made up of the permanent members from marketing, engineering, and manufacturing, and auxiliary members from finance and field repair. The team was chartered to develop a new mining vehicle in eight months, twice faster than usual and as fast as the world leader. The new team was empowered to make all major decisions. The idea was to accomplish success with this team, and then use it as a paradigm along with the lessons learned from its operation to establish a company-wide project management system. Eight months later the project was not finished, and needed eight more months to reach its conclusion. The Swedish parent asked for an immediate investigation. The investigation showed that the team did not make any major decisions. Instead vice-presidents (VPs) who were heads of the departments directed the members of their team to make no decisions, but to bring all necessary information to them and they, the VPs, would make the decision. Having discovered this, the management of Titan Corp decided to fire the CEO and all VPs. Discussion items 1. What are the pros and cons of the relay race approach and the cross-functional team approach to product development projects? Which approach is better? 2. Who gets more power and who gets less power by shifting product development projects from the relay race to the cross-functional team approach? 3. Does the shift from the relay race to the cross-functional team approach require a significant cultural change? Explain why or why not. 4. Why do you think the VPs took the approach of not letting a pilot team make major decisions although the team was empowered to do so? 5. Was the firing of the CEO and all VPs justified? Why or why not? Cocable Inc. Jovana Riddle JANE AND OBANGA It was 6:30 on a Wednesday morning, and Jane Campbell was on her way to work. The traffic was heavy like any other day, which usually made Jane frustrated. Today, however, Jane was calm and didn’t seem to mind the long drive. Why? The commute would give her time to think about what her next move at Cocable Inc. should be. Jane had some very important decisions to make in the next few weeks that would greatly impact her life. Jane’s boss, Larry Fitzgerald, recently came to her with a new project proposal. Since her current assignment was wrapping up, she had to make a choice: Should she stay with Cocable, and accept the uninteresting product development coordinator role she was offered, or should she look for a new job with a different company? As she always did when facing a tough decision, she started to identify the pros and cons of each option. If she took a new job she would likely have to move, work longer hours, and experience a huge learning curve. Most importantly, the new job would mean less time with her precious daughter, Obanga. Obanga was now two years old and had been through a lot in her short life. Jane and her ex-husband, Obanga’s dad, met in Kenya where Jane used to live. Shortly after getting married they moved to England, where Obanga was born. Their divorce came soon after Obanga’s birth, just before Jane and Obanga moved to America. To provide Obanga with a better life, Jane went to Oregon Graduate Institute (OGI), to get a master ’s degree in Engineering Management. From there she was hired by Cocable. Thus, in her two short years of life Obanga had dealt with the loss of her father, a huge move, and the transition of having her stay-athome mom became a full-time employee. Taking a new job, thus, could really impact the little girl negatively. Jane’s other choice was to stay at Cocable and accept the product development coordinator role, for a project that would likely last for at least eight to nine months. This new role would not be very challenging and, more importantly, would not increase her moderate salary. As she finally arrived at the office, Jane knew she had to make a decision soon, one that she couldn’t regret. 7 8 CASE STUDIES BACKGROUND Cocable is a company based in Chicago, which makes interconnecting cables for industry gear. Their annual sales are around $78 million and the company currently employs 720 people. Jane’s role thus far at Cocable has been in operations and product development. The new project she has been offered would require Jane to coordinate product development for gear, similar to her current assignment. Therefore, the learning curve would be nonexistent, and would likely not be challenging or exciting for Jane. The product that needs to be developed is brand new and would require the formation of a 25-person team. Jane’s role in this 25-person team would be to coordinate product development. The members assigned to the team thus far are from all product development functions and various groups. Most of them have spent their entire careers working on similar products and have not been challenged or motivated in their jobs in a very long time. In an attempt to encourage Cocable employees, the company decided to hire an external consulting team to train employees on project management, the area that had never been formally known in the organization. The aim was to help facilitate the product development process at least on a temporary basis. Jane and this 25-person team were requested to attend this training before they would start on the new project. TRAINING The newly formed team would have to undergo a two-day training session, which would be divided into two 5-hour modules. According to historical attendance of training sessions, it could be expected that 22 of the 25 people on the team would be present for each session. The main purpose of this training would be to get all the team members on the same page, and to encourage learning best practices and project management knowledge. Most importantly, this would be a first step in building a cohesive team while providing all members with vivacious and interesting in-classroom training. The team building would also allow the leaders of the group to stand out. The five most prominent leaders would be asked to make up the “Cascade team” that would help design and deploy the project management manual that would be used later in the company. TRAINING BY DOING It would take Cocable two weeks to organize and coordinate the required training session. Upon the conclusion of the training, the Cascade team would focus on designing a manual, using the project management training they just received. To test whether the manual was feasible, Jane’s new project would be the first to use its draft. If it was effective, then the manual would be deployed Introduction 9 to all projects within the company. During the first three months of the project, the team would have to consult the manual and apply its guidelines to each task. By using the manual for each task the team would learn the ins and outs of the project and the application of project management. This typical practice, which is very common in project management, is referred to as “training by doing.” After the three-month anniversary the team would be up for their “threemonth review,” during which the application of the designed manual would be analyzed. The review would be in a workshop format and attended by the 25 employees/trainees and the supervising consultant. The purpose of the threemonth review is to identify any mistakes the employees make while applying the manual to their tasks. For example, each employee would present a real-world example of how they used the manual in everyday tasks and potential mistakes in application would be identified by the team. PRE-IMPLEMENTATION The pre-implementation phase is the period of time between the three- and sixmonth anniversaries of the project’s start. During this time, the trainees continue to apply all the rules in the manual. The “six-month review” is a workshop-style format attended by the supervising consultant and the 25 trainees. Again, each employee is asked to present a real-world issue they have encountered and any potential mistakes/deviations from the manual implementation are identified by the larger group. This workshop would also conclude the pre-implementation phase of the project. CUT-OFF The company would then transition from following the old handbook for all its tasks to using different project management rules presented in the new manual. The application of the old handbook would be abandoned and each step would be transitioned to operating in a new way. The transition date is also known as a cut-off date, the point at which a company chooses to transition to a new way of doing things. This would be the first time in company history that a standard manual was introduced and applied to projects regardless of their size. Things seemed to be changing at Cocable, and Jane felt that she might want to stick around for a while. Discussion item 1. What are the advantages and disadvantages of introducing project management to new product development the way they did in the Cocable case? A RobustArm Global Industries’ Sledgehammer Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon READY, STEADY, NOW . . . “We have a corporate mandate to start the management of our projects by means of Standardized Project Management (SPM) processes by the end of the year. Considering that most frequently projects are done in the Engineering department, its head, Blaine Peters, will be in charge,” said Tim Robison, the general manager of the RobustArm Global Industries (RGI) plant in Duckville, Oregon, to close the meeting of the management leadership team. And the SPM race began. BACKGROUND RGI company was a global multi-million-dollar business that served the planet with the most cost-effective building materials. The company had several branches, and the one in Duckville was one of the biggest plants which employed 220 people, and had annual sales of around $2 million. The company strategy led the plant to cater their products to Western United States and China. What made RGI a distinct company was the three-pronged corporate culture: improve continually, standardize processes, and purse change. In the early 1990s RGI won the Baldridge award for quality, and embarked on a never-ending race for continuous improvement. All employees relentlessly searched for the next production method to enhance or to remove a bottleneck. Most importantly, the Baldridge award changed their worker mindsets forever, making them feel like owners of processes, rather than just regular employees. One of the major aims of this corporate culture facet was standardization of processes. The new corporate mandate of pursuing SPM has the purpose of bettering ways of running projects, and raising efficiency and reducing costs in order to eventually provide greater value to the customer. At RGI, they even standardized one facet of meetings: To convene any meeting, you had to send a standardized agenda ahead of time. 10 Introduction 11 “Nothing is permanent except change” was the motto at RGI. This was not a “one-major-change-initiative-at-a-time” type. Actually, this was a whitewater type of change where a multiple of change initiatives were unfolding at the same time. So, while they were preparing to launch the SPM initiative, there was a serious effort related to the six sigma initiative, targeting the improvement of production facilities, and several teams used the best of their knowledge to upgrade processes in production, HR, IT, R&D, engineering, etc. GETTING TO WORK As soon as Blaine left the conference room, he began to run the SPM race. He did so by following the corporate guidelines for the major change. According to the guidelines, he established the project and named the change initiative: SPM Implementation Project Sledgehammer, and assumed the job of Project Manager. Blaine then chose his project team members, from the Engineering department, who needed to be properly trained in project management first before proceeding to the next step. It took him a week to find the right project management trainer, and another two weeks to arrange the three-day project management training. So far, project affairs went smoothly and were expected to continue that way. In three weeks, the team would need to produce an SPM manual, which had 10 standard items with a template for each one, including: ● ● ● ● ● ● ● ● ● ● Scope statement Work Breakdown Structure (WBS) Responsibility matrix Schedule Cost estimate Quality plan Risk plan I (P-I matrix) Risk plan II (Risk response plan) Progress report Closure To finish the Sledgehammer with flying colors, the project team would need to organize separate training, designed specifically for the use of the SPM manual, for all members of RGI’s Duckville plant. When this was done, the project team would announce the cut-off date by which all new projects had to be managed with the SPM manual. It sounded that simple. Discussion items 1. How important is the SPM process to the company? Explain your answer. 2. What are the pros and cons of the approach that RGI used to develop the SPM process? Another Trojan Horse Stevan Jovanovic MEET THE TROJANS John Lackey can’t hear the noise of the hundreds of people cheering in congratulations for him. His thoughts have drowned out the noise. He just received a reward for Best Project Management of a Utility Plant in the United States. The plant is Trojan Nuclear Plant, which was officially shut down in 1996. The year is now 2000. John is about to give a speech in front of hundreds of people. He is expected to give the typical acceptance speech and thank everyone for their hard work and thank the award committee for their recognition. This is not, however, the usual utility plant management story. John is consumed with thoughts of how a common speech could possibly convince the world that a nuclear plant, having produced zero power in four years, deserves an award praising its project management. The story of a project that involves decommissioning of a nuclear plant cannot be short. This project is also very unique with equally unique circumstances. The whole project plays out in his mind. His thoughts start from the very beginning . . . THE SIMPLE TASK The task sounded simple enough, to shut down a nuclear plant, decommission it, and make the plant, or at least its location, safe for the future. The plant was near a major metropolitan area, which made the first line of reasoning simple; get the dangerous stuff away from the dense population and reduce risk for human harm. Trojan was a large plant—it was the largest and most powerful nuclear plant of its day. It was built on a huge site that supported tons in equipment. Although most people seldom consider decommissioning, as part of managing a power plant, it is actually a necessary part of the plant lifecycle. As one would expect, most of the equipment was used to handle extremely hazardous nuclear material. Nuclear material stays dangerous for very long periods of time, for thousands of years. The varying degrees of danger involved for 12 Introduction 13 the different parts of the huge plant ranged from slightly dangerous to extremely poisonous. Every inch of the 600-acre complex had to be thoroughly examined and a plan had to be made to deal with each and every inch. All of the equipment was hazardous and had to be handled with extreme caution. The project would take years. TRAINING Decommissioning of a nuclear reactor is unique in that every single detail of the project must be planned out and reviewed long before any work can begin. Error was unacceptable, especially for a project such as this that would be scrutinized not only by the authorities, but by the general public as well. Nuclear power has always been a hot topic, generating extreme public opinion. The Trojan Nuclear Plant, even during its operating life, was always a source of controversy for people on both sides of the nuclear power debate. Every aspect of its operation, especially bad news, became fodder for the media. Any negative news immediately became front page material. John and his company definitely did not want their name associated with negative “nuclear news.” The only way to ensure that this did not happen was to be as prepared as possible. Naturally, the first step was getting up to date on the latest in project management techniques. For this they chose the four-day training course by Scope Management (statement, WBS, process, changes), Cost Management (estimates, earned value, cost baselines), Time Management (jogging line, TAD, milestone charts), and Risk Management (risk events, PI Matrix, Monte Carlo analysis). The course was structured per the PMBOK Guide. Now armed with tools and concepts needed for the work ahead, they felt prepared for any size project. LEARNING One of the biggest challenges for this company was the change in mindset from an operating company to a project management company. An operating company does use basic project management techniques but spends much of its time and energy executing operations. Naturally, however, a project management company spends all of its energy on project management. Although the transition from an operating company to a project management company may not sound challenging, there can be difficulty when a person has spent their entire career focusing on project execution. The tendency for that type of person might be to revert to old ways. On a project this complex, however, skimping on project management could be disastrous. The first step in decommissioning the plant was to break down the project into smaller projects. These “smaller” projects were by no means easy, but were more adaptable for applying and refining their recently acquired project management skills. They were essentially used as learning blocks and every “smaller” 14 CASE STUDIES project management project was carefully reviewed and each lesson learned was clearly outlined. One of the projects was the removal of the central reactor. This involved transferring the entire reactor hundreds of miles from the plant location. Such a project had never been attempted before, which means no historical information upon which to rely. The entire decommissioning project had many “firsts” and of them all the reactor removal was by far the biggest and most complicated. The reactor, a concrete and steel maze, was the size of a basketball court and weighed many, many tons. The safest way to remove the reactor was in one piece. The reactor was not originally designed and built, however, with the intent of being picked up and carried around in one piece. It was a system of structures, pipes, and mechanical equipment. Damaging and breaking open any part of the reactor system would have allowed poisonous material to leak out. This was the worst possible scenario and could not be allowed to happen. The project was the pinnacle of the team’s project management use. They managed to safely lift the reactor, transfer it to a ship, move it up river (including going through four dam locks), transfer it to a land vehicle, and “truck it” to its final destination. They managed every detail of the move. To the great relief of everyone, the move was a success. The team and the company had made their mark in the pages of project management history. Discussion item 1. What do you learn from this case? Call a Truck Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon CAT, Inc. was a powerful company. They provided their customers with the goods to transport, the food to eat, the gas to drive, and a place to sleep overnight. In fact, they provided everything that a driver would need on the road. What kind of company was that? CAT, Inc. was a broker between companies that transport the freight and the owners of the freight. And they were the premier broker of the market. In the 1980s, the technology wasn’t very complicated or advanced. “Computer” was a fairly new term that was just recently becoming known to this business. Most requests and information were handled by fax or telephone. CAT, Inc. was one of the many companies that used this technology. THE NEW CEO CAT, Inc. just got a new CEO, James Carter. James was voted and selected by the majority of managers who were former drivers. To the surprise of the majority of the employees, the new CEO was not a former driver. He was a businessman who viewed CAT, Inc. as a dinosaur, an about-to-be-obsolete business that used fax and telephone. The new CEO had a new vision. The vision was to be in touch with customers by a new means that radically changed the way people communicated. The means was known as a computer. This required massive investments. Luckily, CAT, Inc. was in a position that could afford the changes. So, to make his vision possible, he launched a number of operative and strategic changes. Among the operative changes, James ordered a stop to many fax-based communications between his people and customers and changed them to be fully computer-based. In that manner, CAT, Inc. became the first company in its industrial history that was able to provide everything a driver would need on the road, ordered by request through a computer system. However, because not many people had computers at the time, the company also maintained a fair use of the traditional means of fax and telephone, but limited them to minimal usages. 15 16 CASE STUDIES The information through the traditional methods was kept in the digital format, nevertheless. In addition to the operative changes, strategic changes were many and indepth. One example was the new infrastructure. CAT, Inc. built the infrastructure that supported the new system and better facilitated customer requests. Despite a number of positive changes, consequences were inevitable. And one consequence went to the technology development group, where the old faces were all laid off. In place of them, the company hired a new software group from a technology company’s technology group. Immediately after that, a training program with a new content that supported the computer system was established. In addition, a call center was set. Project groups arranged around their customers were also formed for the first time. The projects related to new products and services that were performed in the call center were led in the matrix way by project management. In other words, cross-function teams were initiated to respond to the customer needs. But, there was no standard procedure yet for managing projects. There were so many things that the company would need to do in the next several years. But now, CAT, Inc. was a new company inside-out. Discussion items 1. What were other operative and strategic actions, not mentioned in the case, which might have been executed to accomplish James’ vision? 2. How do the changes affect the strategy of CAT, Inc.? 3. What role did project management play? The Project Hand-off Method Dragan Z. Milosevic, Russ J. Martinelli, and James M. Waddell Hospi-Tek is a medical equipment manufacturing company who has historically used a project hand-off approach to develop its products. They are currently under intense time-to-market pressure from their primary competitor, forcing senior management to reevaluate this approach. A HAND-OFF METHOD Under the project hand-off method, the Hospi-Tek product development effort began with the architectural team who developed an architectural concept and derived the high-level requirements of the medical device from the work of the product marketing team. The architectural concept and specifications were then handed-off to the hardware engineering team, who assumed ownership of the project. The engineering team developed the hardware requirements, engineering specifications, and the product design, which were then handed-off to the manufacturing team, who assumed ownership of the project. The manufacturing team developed the manufacturing processes, retooled the factor, and produced the physical product. The product and project ownership were then handed-off to downstream engineering teams, such as the software development team. The software team developed the software stack, then handed-off the combined hardware/ software product, as well as project ownership, to the validations and test team. Finally, the validations and test team performed product- and component-level testing to ensure the product achieved the functional, quality, usability, and reliability requirements. Management of the project was accomplished through a project managementonly model, with multiple project managers in control of the project as it progressed through the development life cycle. Thus, a project manager with the functional expertise specific to the phase of development the product was currently in assumed ownership of the project. 17 18 CASE STUDIES JUDGEMENT The hand-off method of development is common in smaller, less mature, and technically focused companies in which true project management value is usually not well understood and the engineering functions reign king. Unfortunately, this method is not scalable, and as a company begins to succeed and grow, product and process complexity requires the management team to look at alternative methods to structure and manage its product development efforts. This was the case with Hospi-Tek. Discussion items 1. Why, by implementing the hand-off method, are there multiple project managers in control of the project as it progresses through the development life cycle? 2. Do you agree with the judgment that the hand-off method is popular in companies where true project management value is usually not well understood? Why or why not? 3. What are the pros and cons of the hand-off method? CASE STUDIES IN PROJECT, PROGRAM, AND ORGANIZATIONAL PROJECT MANAGEMENT Dragan Z . Milosevic, Peerasit Patanakul & Sabin Srivannaboon Copyright 02010 by John Wiley & Sons, Inc. All rights reserved. Chapter 2 CULTURAL ASPECTS OF PROJECT MANAGEMENT This chapter discusses the cultural issues of project management, which basically impact how projects are performed. “Culture” involves how people do things, the methods they use, that influence a project’s ability to meet its objectives. It is a collective programming of the minds, generally used to understand basic values of a group, and is used (or sometimes abused) by management to direct the behavior of employees to achieve better performance. Two cases are featured: one is issue-based and the second is a critical incident. 1. Engineering Culture at Beck Engineering Culture at Beck is an issued-based case. It discusses the functional culture of an engineering department. 2. The Jamming The Jamming is a critical incident. It specifically discusses a culturally compatible strategy, called the jamming. 19 20 CASE STUDIES CHAPTER SUMMARY Name of Case Engineering Culture at Beck The Jamming Area Supported by Case Functional Culture Culturally Compatible Strategy Case Type Author of Case Issue-based Case Critical Incident Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon Engineering Culture at Beck Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon IF JIM SAYS SO Jim Traddell, director of a PM Office, and the project initiator, led the meeting with the consultant. He made every effort to look decisive, as he dictated the conclusions of the meeting to the scribe. Raja James was Jim’s partner. He was helping Jim on this project, particularly on the aspects of the culture. The team wanted to learn more about the engineering culture at Beck. To obtain the information, the meeting with an engineer at Beck was arranged at a local restaurant around the corner. Raja was about to leave the office to meet his informant. BACKGROUND Beck operates in an environment that abounds with rapid and discontinuous change in demand, competition, and technology. Even worse, that information is often not available, obsolete, or inaccurate. The company is founded in 1946, and its primary income comes from projects. Annual income is approximately $800 million, with 4,000 employees. Disequilibrium, along with perpetual and discontinuous change makes all competitive advantages temporary. Organizational units are loosely coupled with a lot of entrepreneurial behavior. Any advantage is temporary, contributing surprise and flexibility to Beck strategy. In this industry, risk is viewed as a factor upon which to capitalize, and the trick is that succession of fleeting advantages lead to higher performance. ENGINEERING PRIDE Tippie Anne, the 34-year veteran and engineer, showed up at 11 AM in front of Bombay restaurant for the lunch meeting. After pleasantries were exchanged, Raja invited Tippie inside where the aroma of curry dominated the air. As they helped themselves to an abundance of Indian food, Raja took the first step: “We’ll have to cut to the chase. Let’s start the interview now, as we both are very busy, 21 22 CASE STUDIES and I would appreciate finishing by 12 noon.” Raja announced his intent to focus on the professional part of the lunch. Tippie agreed with his idea, commencing a conversation. “Jim Traddell, one of my good friends, asked me to tell you my story of Beck’s culture. Personally, I don’t like to begin interviews with the word ‘culture’ because it tempts interviewees to become theoretical. But this interview is an exception.” Raja replied, “Thank you. Then, let me ask you, how do you do things around Beck’s now and how did you used to do them?” Raja hoped that using this simpler language would inspire Tippie to speak about culture in easier terms. The conversation went as follows: Tippie: Well, we have a habit of calling ourselves “engineers,” which we are. Perhaps this is in protest to having no such name 20+ years ago when Beck was small and had no real financial power. Today, for comparison, the new Beck is 4,000 employees strong and has $900 million cash at hand to purchase other companies. Nowadays, everybody respects us as engineers. If you talk to senior managers, engineering managers, and workers, you’ll see for yourselves, how much these folks esteem us. Not that other specialists are not held in high regard as well, but when in the past our company would negotiate products, engineers would not be always seen as an important part of the negotiating team. Surprisingly, at old Beck our product sold without engineers around. But not for long. The old Beck valued MBAs. If one desired to get ahead, he had to get an MBA degree. Engineers were engaged almost like mercenaries. Yes, I am telling you the truth. Don’t laugh there, Raja. The newly minted MBAs, mostly second-rate engineers, would prepare business plans for new products, the NPV (Net Present Value) and PI (Profitability Index), mostly what we call today derivative products—routine stuff. Of course, they embellished the products, hired engineers like “mercenaries” and business thrived. As I said, though, not for long. Once the substance was sold out, the derivatives didn’t sell and there were no new breakthroughs (products new to the world) and platforms (products new to the companies), the business sank into the red, resulting in years of suffering. The new Beck was in the making for years and the senior managers spent a lot of time creating project culture. Those platforms and derivatives products helped employees come about. Managers as well as workers understood that Beck would not survive if it didn’t have high-value products. Those high-value products must be designed and developed by engineers and, they were. That’s why they are respected and held in high regard, which is why they are feeling engineering pride. DESIGNERS TO COST Raja: I heard the terms “design to cost” and his cousin, “cost to design,” mentioned many times at Beck. Would you please explain them to me? Cultural Aspects of Project Management 23 Tippie: These proud engineers from the new Beck are very different in one respect from the engineering guard of the old Beck. Namely, current engineers are much more cost conscious, so their skill is much higher and the cost attitudes are essentially more developed. For example, the new ones always design products with the cost in mind. So, the finished product price must be one-fifth of a set of corresponding prices of spare parts. These proud guys have a different beginning policy. Theirs is “design to cost” as opposed to the old Beck’s “cost to design.” These two differ as two philosophies of life but their names are similar. The former means that first the target product prices must be established; then the product is designed backwards. The desire is to first obtain the real product, component, and feature prices, then determine spare part prices. So, we have developed a tool called Kano’s maps, which tells the price of each feature, thus we know which combinations of features really make money, and which don’t. The latter cost-to-design approach implies that engineers first design the product, then, they figure out the price, which the customer may consider overly high. Once product price is a known component, feature and spare prices can be calculated. While the former approach is proactive and customers love it, the latter is reactive and customers consider it obsolete. Sometimes, customers view the cost-to-design approach as a way to rip them off. Skills requiring the design-to-cost approach are markedly higher than those demanded by the cost-to-design approach. Plus, customers like the former approach because it immediately tells the price, and gets their business from others. Sometimes, customers consider the cost-to-design approach not suitable for knowing the target product price sufficiently early. This skill, that engineers at new Beck have and those at old Beck did not, offers our organization strategic market opportunities. In particular, we see new markets and customers become available, and we think this is another good reason to feel like proud engineers. Not so long ago, we got a call from a wholesaler who could turn around 1,000 pieces of one of our products with certain features. We consulted our Kano’s map, and we learned that the asking price was right. CUSTOMER-CENTRIC Raja: I would like to learn how customers impact your engineering culture. Tippie: Our engineers try very hard to be customer-centric. I know it sounds like a buzzword, but it is very precise in what it wants to denote. As in the old Beck, and in many other companies, we didn’t ask the customer what 24 CASE STUDIES they wanted in new products. We assumed by doing that, we would become customer-oriented. Rather, we developed whole arrays of processes and tools that pointed toward seeking out what the customer exactly wanted. The bottom line of being customer-centric is being able to help translate what customers precisely want of the product design. For that, we first used tools of survey design, customer segment, and custom visit documents to understand what customers wanted before the work began. Note that sometimes customers do not know what they want. So, our engineers designed all of the tools and processes to help them figure out what customers asked for. Then, in the design stage, we may use Quality Function Deployment (QFD) or rapid prototyping, to give design features customers long for. They have a long experience of working with customers’ people. For instance, they sit on joint development teams with customers, or use lead users’ concepts to reveal what future products would look like. Our engineers are trained to stand in front of customers. You know, psychologists get trained how to talk to patients and elicit meritorious information; they are only college grads who get this education. No engineers get this kind of training. We at Beck spend thousands of dollars to prepare engineers to be comfortable talking to customers and becoming customer-centric. RUN TO THE END Raja: What else distinguishes Beck culturally from others? Tippie: One thing I should mention as unique to us is our motto of “run to the end.” Namely, in old Beck, our first priority was to secure new business, and a concern for producing a product at times fell through the cracks. So, as a consequence, acquisition of the business really mattered, and implementation of business suffered. Obviously, more attention was paid to the front end of the order process, rather than to the back end. At times, we did not know where this product was in the production cycle. As a further consequence, all kinds of promises were made to customers to bring the business in, usually forgotten easily in the production stage, and that was considered “normal” and ethical. Customers, anyhow, felt cheated. The new Beck does not tolerate this. We worked very hard to show our engineers that all products are made equal. So, the customer has every right to know how long down the manufacturing line their product is. And, hence “run to the end.” We put a lot of effort into eradicating this ugly habit—not only to know the product production status but where it will be the next day, in the next two days, until its completion. We, in other words, care about any product in production and show it. Raja: Give me an example. Cultural Aspects of Project Management 25 Tippie: We had a big wholesale customer in China. Thanks to this approach, we followed the product and its life cycle. So, this customer called us, and told us that market shifted away and two planned features didn’t sell. We were at the third quarter of the project’s life cycle but we managed to drop the two features. Raja: What other ways of doing things around Beck are unique? Tippie: We are a typical high-velocity company around the area. So, we have many ways that we share—the rewards, matrix organization, decision making, etc.—but those I described make us who we are. Raja still had several questions he wanted to ask, but an hour had passed. He had no choice but to thank Tippie, and leave the restaurant. He had another appointment at 12:30, the second lunch meeting he needed to have for today. Discussion items 1. List major definitions of the culture mentioned in the case. Analyze them and tell what is unique in each. 2. What do you like and dislike about Beck’s culture? The Jamming Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon SCENARIO 1: JAM WITH THE COUNTERPART An executive five-member team was formed to manage a small but global company. Because they were allowed to choose where they wanted to live, the team spread across Finland, Denmark, Sweden, and England. Although each member was multilingual, they spoke in English during their weekly teleconference. Every month the team met at one of the company’s divisional headquarters and spent the next day with the managers from that division. Members were encouraged to be part of every discussion, although their individual roles were very clear, so that interaction on a day-to-day basis was unnecessary. Even though the team never went through a formal team-building process, its emphasis on an agreed team mission, shared business values, and high performance goals for all members made it a true model of a well-jammed multicultural team. SCENARIO 2: THE NPD GAME When the team members first went to work on a product development project in a small high-tech company in the United States, it appeared that they would forever be at odds over every aspect of managing a project. A few projects and many fights later, however, a German, an American, a Mexican, and a Macedonian looked as cohesive as any other team. As they marched through their projects, they acquired an in-depth knowledge of each other ’s cultures and project management scripts. Not only did they know each other ’s religious holidays and eating habits, but they also reached a point of accepting American concern for cost tracking, German obsession with precise schedule management, Macedonian dedication to team spirit, and Mexican zeal for interpersonal relationships. The road to their masterly jamming was not paved by deliberate actions. Rather, it evolved from patient learning, many dead ends in their interactions, and the need to be successful in their work. 26 Cultural Aspects of Project Management 27 JAMMING The situations described here can be called “jamming,”—a strategy that suggests the project manager and the counterpart improvise, without an explicit mutual agreement, and transform their ideas into an agreeable scenario for their work. In this sense, they are like members of a jazz band following the loose rules of a jam session. “Jazzers” jam when they begin with a conventional theme, improvise on it, and pass it around until a new sound is created. This strategy implies what is apparent in the executive team (scenario 1)— all team members are highly competent. Such competency enabled them to fathom the counterparts’ assumptions and habits, predict their responses, and take courses of actions that appealed to them. Another condition was met for jamming to work with the executive team, in particular, understanding the individuality of each counterpart. A counterpart’s fluency in several scripts clearly meant that he or she might propose any of the scripts’ practices. Knowing the individuality then meant anticipating the practices. That the counterpart was analyzed as a person with distinct traits, and not only as a representative of a culture, was the key to successful jamming. However, there are intrinsic risks in the use of the jamming strategy. As it occurred in the initial phase of the high-tech team (scenario 2), some counterparts did not read the jamming as recognition of cultural points, but rather as an attempt to seek favor by flattery and fawning. Although the team never faced it, it is also possible that jamming may lead to an “overpersonalization” of the relationship between the project manager and the counterpart, characterized by high emotional involvement, loss of touch with and ignorance of other team members, and reluctance to delegate. Jamming’s basic design may not be in tune with all cultures and may not even be appropriate for the execution by teams composed of members with varying levels of competency in other people’s project management scripts. While in its early stage of development the high-tech team members’ varying levels of competency were a significant roadblock, their further learning and growth got them over the obstacle. Still, the number and intensity of cultural run-ins that the team experienced before maturing supported the view that this strategy tends to be shorter on specific instructions for implementation and higher in uncertainty than any other unilateral strategy. However, its plasticity may be such a great asset to multicultural project managers that many of them view it as ideal in the development of a culturally responsive project management strategy. Discussion items 1. In what situation would the jamming approach work well? 2. What are the pros and cons of the jamming approach? CASE STUDIES IN PROJECT, PROGRAM, AND ORGANIZATIONAL PROJECT MANAGEMENT Dragan Z . Milosevic, Peerasit Patanakul & Sabin Srivannaboon Copyright 02010 by John Wiley & Sons, Inc. All rights reserved. Chapter 3 PROJECT MANAGEMENT PROCESSES This chapter presents case studies of issues related to concepts in Chapter 3 of the PMBOK® Guide, namely the project management processes in which a process is defined as a set of interrelated actions and activities performed to achieve a predetermined product, result, or service. There are four issue-based cases in this chapter. 1. Special Session Special Session is an issue-based case that generally describes different project management process groups, defined in the PMBOK Guide, including Initiating, Planning, Executing, Monitoring and Controlling, and Closing. 2. Waterfall Software Development Waterfall Software Development is an issue-based case which centers on the waterfall model for software development projects. In this case, six common phases of the model, including its limitations, are discussed. 3. Extreme Programming Extreme Programming, an issue-based case, talks about a methodology that is intended to improve software quality and increase the responsiveness of the software development organizations to changing market demands. The process has the iterative nature of the development, which facilitates continuous feedback to maintain management visibility of the project status and budget consumptions. 29 30 CASE STUDIES 4. Do You ZBB? This issue-based case presents one technique of project estimation and the selection process, known as zero-based budgeting (ZBB). It provides an example of applying the ZBB concept to everyday life; in this particular case, getting a degree while still balancing the work needed with life. In comparison, a strategy is expressed in terms of a bucket of money that a business unit wants to spend making the strategy work. In the process of selecting the projects, their estimates therefore should be equal or not exceed the bucket sum. CHAPTER SUMMARY Name of Case Special Session Waterfall Software Development Extreme Programming Do you ZBB? Area Supported by Case PMI’s Project Management Process Groups Software Development Model Software Development Model Select Project Case Type Author of Case Issue-based Case Sabin Srivannaboon Issue-based Case Osman Osman Issue-based Case Mani Ambalan Issue-based Case Rabah Kamis Special Session Sabin Srivannaboon One fine Monday in spring 2008, Thomas Glacia was waiting for his students in a classroom at the 4th Avenue building to come back from a 15-minute break. Thomas was a senior lecturer of a local institute in Eugene, Oregon. This term he was teaching two classes, which were already completed. But his assignment wasn’t yet over. He still had to teach this special session, which covered project management concepts. Why special? It was because there were only five undergraduates in the class; Jill, Kelly, Alice, Mackey, and Octavio, who failed the final exam, and needed to retake the exam in three days. As Thomas was looking at his lecture notes, his students returned to the room for the second half. SPECIAL SESSION Thomas: Okay, guys. Let’s continue. We have discussed project management concepts and the differences and relationships between project management and their related principles. We also talked about the triple constraints which every project must meet: the time given, the budget, and the acceptable quality standard. Now let’s move on and talk about the project management process. Now someone tell me how many processes do we have, according to the PMBOK? And what are they? You guys already learned about it. Come on. Alice: There are nine processes. They are time management, cost management, quality management, risk management, etc. Right? Thomas: Well, nice try, but not quite. Those are the knowledge areas, Alice. We have only five process groups, not nine! What are they? Anyone? Kelly: Initiating, Planning, Executing, Monitoring and Controlling, and Closing process groups. Thomas: Exactly. These processes overlap, and are used as a guideline for applying appropriate project management knowledge and skills during the project. 31 32 CASE STUDIES They are iterative, and many processes are repeated during the project. The first process is initiating. Like its name implies, this is when we initiate a project. This is when we get some ideas of the project scope, and identify the purposes of the project. Kelly: What are we really looking for in the scope and purpose of the project? Thomas: We need to clearly and explicitly define what the project is intended to achieve and what its scope of interest will be. One output of the process is a project charter. And the charter is . . .? Jill: I just read about it. The charter is a summary of project team members. Thomas: Well, that could be one element in the charter. The charter is actually a document that formally authorizes a project or a phase and documents initial requirements that satisfy the stakeholders’ needs and expectations. Now for the second process, the planning process—what do we have to do there? Mackey: We can break a project into a number of smaller pieces, and arrange them in a top-down structure, which is called a work breakdown structure. Also, we should define what resources and time commitments are required to carry out the project through the work breakdown structure. Octavio: Also, we need to create a project plan that involves resource plan, financial plan, quality plan, acceptance plan, and communications plan. Mackey: But how will we deliver a project and present it to our customer for their acceptance? Thomas: Not too fast, Mackey. That’s the third process, the execution. The execution process is undertaken to perform the work defined in the project plan to achieve the project’s objectives. The activities here may include creating project deliverables; managing tools, equipment, and people; managing risks; and creating project data such as schedule, cost, technical, and quality progress. Alice: I think the most challenging task for me is not executing, but rather monitoring and controlling the tasks executed. Thomas: That’s the fourth process. We monitor and control projects to identify the potential problems in a timely manner so corrective actions can be taken promptly. Monitoring and controlling projects will benefit the project performance since it is observed and measured regularly to identify variances from the project plan. Octavio: Could you give some examples of monitoring and controlling a project, please? I mean what exactly do we need to monitor in a project? Project Management Processes 33 Thomas: What about risk? When risk becomes a problem, it can greatly affect a project’s cost, schedule, scope, or quality. So, it needs to be closely monitored and controlled. One way of monitoring and controlling risks is to create and deploy a Risk Management Plan which anticipates any project challenges. Usually, the progress of monitoring and controlling is provided through the project status report to all stakeholders of the project. Jill: Monitoring and controlling are the same, aren’t they? I am not quite clear on these two terms. Thomas: They are related. Monitoring is collecting, recording, and reporting information concerning all aspects of project performance that the project manager or others in the organization wish to know. In our discussion, it is important to remember that monitoring should be kept distinct from controlling and from evaluation. On the contrary, controlling uses the data supplied by monitoring to bring actual performance into approximate equivalence with planned performance. Evaluation is performed through judgments that are made about the quality and effectiveness of project performance. Mackey: How do we monitor our projects? Thomas: Usually, the first task in monitoring projects is to identify the key factors in the project action plan. The factors should focus on results rather than activities. Then, we need to collect several important data. Data can be frequency counts, numbers, subjective numeric ratings, indicators, and verbal measures. Then, we can generate project progress reports after data collection has been completed. Alice: That must be difficult. I bet there would be problems with the project reporting. Thomas: Yes, there are actually three common project reporting problems, which are too much detail, poor correspondence to the parent firm’s reporting system, and a poor correspondence between the planning and monitoring systems. Jill: What kind of analysis do we use to monitor the entire project? Thomas: There are several techniques. The most well-known one is the Earned Value Analysis. Earned value analysis is abbreviated as EVA, measuring overall performance by using an aggregate performance measure. The earned value chart depicts scheduled progress, actual cost, and actual progress to allow the determination of spending, schedule, and time variances. In practice, there are a number of commercial software packages that can help in monitoring project status, but the common desirable attributes that most project managers 34 CASE STUDIES prefer are user friendliness, schedules, calendars, budgets, reports, graphics, networks, charts, migration, and consolidation. Mackey: What about controlling? Thomas: Control is an act of reducing the difference between plan and reality. Project control focuses on three elements of a project: performance, cost, and time. Is the project delivering what it promised to deliver or more? Is it making delivery at or below the promised cost? Is it making delivery at or before the promised time? There are two purposes of control. First, it is to regulate results through altering activity. Second, it is to conserve the organization’s physical, human, and financial assets. Kelly: What about the control report? I learned about this, but I forgot. What should be included? Thomas: The control report should include project objectives, milestones and budgets, final project results, and recommendations for improvement. Jill: I see. A good controlling system must help. So what kind of controlling system should we establish? Thomas: It should be flexible, cost effective, and truly useful. More importantly, it should operate in an ethical manner, in a timely manner, and be sufficiently accurate. Anything else you want to add? Kelly: Well, it should be easy to maintain and simple to operate. Alice: It should be fully documented and extendable, as well, I think. Thomas: That’s good. One of the problems in controlling projects is the control of change. It is difficult because it causes uncertainty, increases sophistication in a project, and has to modify rules applying to the project processes. Let me recap. We already discussed four project management processes; project initiation, project planning, project execution, and project monitoring and controlling processes. Now let’s move on to the final process, the closing process. How many ways can a project be terminated? Jill: I think it can be terminated by the extinction. Sorry, I don’t remember the rest. Thomas: Come on. The exam is coming in three days. In addition to the extinction, a project can also be terminated by addition, integration, and starvation. Octavio: I didn’t know a project can be stopped by addition! What exactly is that? Thomas: It’s in the book, Octavio. You should read it again before the exam. It means that project personnel, property, and equipment are simply transferred Project Management Processes 35 from the dying project to the newly born division. It transforms a project into a division of the firm and then, if real economic stability seems assured, the new project in that division can be created. Kelly: How do we know when to terminate a project? Thomas: Making a decision to terminate a project is difficult, but a number of factors can be used to reach a conclusion. For example, the factors that are considered in terminating projects are technical, economic, market, the customer ’s satisfaction, the impact of the project on the organization, etc. Alice: What should be included in the project final report? Thomas: You tell me. Mackey: I think the report should include the process knowledge gained from the project. Octavio: It should include what we have learned. For instance, it should incorporate project performance comments, administrative performance comments, personnel suggestions, etc. Thomas: That’s good. Time is almost up. Make sure you guys review the materials today again before the exam. This is your last chance. And I hope that I won’t see you in class again next year. Good luck guys! Discussion items 1. What project management tools were mentioned in this case? 2. Which of the process groups do you think is the most challenging one? Explain your reasons. 3. How are the knowledge areas and project management processes related? 4. In your opinion, what is termination by starvation? Waterfall Software Development Osman Osman Robert Adam, the project manager of Renegade, just received a notification that his project was in an idle stage for four hours due to a specification conflict. The conflict came from the disagreement of how to accomplish one of the project tasks. Dangerously, the disagreement was built around specification deviations, thus delay of the project was likely inevitable. Robert was well aware that his project would make no progress until this issue was resolved. Consequently, if the project did not meet the specifications during the review, it would not progress at all until a correction had been made or modification to the specification document had been approved and recorded. This irritated Robert. So, he called for an emergency meeting with the involved parties. RENEGADE Renegade is a health insurance provider in the southeast region. The company has employed the “waterfall” methodology for their software development projects. The waterfall methodology is based on the assumption that projects can be managed better when segmented into a hierarchy of phases, stages, activities, tasks, or steps. The waterfall methodology therefore directs a software development project to progress in an orderly sequence of development steps. This also means concurrent development steps of a project are prohibited. Renegade has experienced a rapid growth over the years. In just a short five-year span, the numbers of subscribers has increased from two hundred thousand to more than one million subscribers. Management predicts even more growth. This number is only the subscribers, and their dependents are not included in this number. Therefore, the rapid growth of subscribers means extensive data to manage for Renegade. The company has been using Microsoft Access as their data management system. Renegade realizes the limitations of MS Access in managing large amounts of data, now that they have to deal with their aggressive demands. Therefore, an upgrade to more sophisticated data management systems is a must. 36 Project Management Processes 37 After some research, top business managers decided to convert the database management system to Oracle, which should have been be able to provide flexibility, ability to manage huge amounts of data, expandability, and referential integrity. THE PROJECT To respond to this need, Renegade initiated a project whose purpose was to implement: Oracle database with proper connectivity to the existing system, and Safe data transfer from MS Access to Oracle Project Budget: $200, 000 Project Duration: 10 weeks The pharmacy department (PD) was responsible for the project and its cost. The PD selected Robert Adam as the project manager and Leila Rakoba as the business analyst, both of whom were very experienced individuals. Robert was the main person in charge of any problem/issue/concern regarding the project. He was responsible for all aspects of the project, including project schedule, development matrix, budgeting, and issue escalations. Leila was the major point of contact for the user. She was responsible for collecting all the requirements from the users and documenting them in the business requirement document. WATERFALL SOFTWARE DEVELOPMENT As mentioned, similar to other projects this project followed the waterfall software development model. The project must complete each phase and go through a final walkthrough (FWT) before it could move forward. The formal walkthrough committee usually involved the phase completion check-off and presided over all sign-offs. The committee consisted of managers from different functional areas. Robert was also involved in the FWT, but was not part of the committee. So his signature wasn’t required for phase completion sign-off. The purpose for the FWT meeting was to ensure that specification requirements of the particular phase were clearly met and documented. Requirements must be validated and exit criteria must be satisfied before the project could progress. In other words, the waterfall model created disciplined project management and ensured the adequacy of documentation and design reviews. It set all requirements, schedules, and expectations before the project kick-off. Figure 3.1 shows a preliminary outline that represents the overall process of software development life cycle at Renegade. 38 CASE STUDIES Figure 3.1 Software Development Life Cycle Initiation Planning > User/Business Specification Requirement—BA Implementation > Functional R’t Doc—SA Test > Technical Spec > System Doc—Developer > Development Architecture Unit Test Plan—Dev > Integration Matrix—PM and System Doc—SE > Code and Unit Testing plan > Documentation > Requirement Test Standard > User > Project Plan—PM Analyses > Product Visibility Acceptance > Data Model— > FWT > Risk Management Test—TA DA > Test Data and > Documentation > FWT Reports > FWT > FWT > Functional Specification—SA Deployment Maintenance > Release Document—RE > DBA > Environment User Support Test > Documentation > FWT > Baseline > FWT INITIATION PHASE As the project manager, Robert was responsible for the development of the resource requirement document and project plan. To prepare these documents, he needed to get help from different functions. In particular, Robert needed assistance from the Solution Engineer (SE), Systems Analyst (SA), Developer, Test Analyst (TA), Release Engineer (RE), Data Architect (DA), and Database Analyst (DBA). Robert also needed to write a development matrix document that consisted of the deliverables and the responsible members for the deliverables. Additionally, he needed to produce a resource-planning document that included the roles and requirements of the resources. For example, Robert requested the database analyst who had a minimum of 3.5 years of work experience in related fields, and possessed good Oracle and MS Access technical knowledge. FIRST FORMAL WALKTHROUGH MEETING It was November 13, 2007, 10 days prior to the kick-off meeting. The PD already allocated all required resources and assigned them to Robert for the project. It was his responsibility to use the resources optimally according to the schedule and budget. With Leila’s help in facilitating and conveying all the project requirements, the meeting was sure to go well. The team was more than ready. 39 Project Management Processes PLANNING PHASE As expected, the team passed the first FWT meeting, and moved onto the planning phase. Robert and his team went on, and started laying out the project plan. But when the team worked on the project plan for a week, a conflict arose. That’s when Robert called for an emergency meeting. EMERGENCY MEETING In the meeting, Robert wasn’t very excited to hear issues or complaints from Luke, who was the systems analyst. Robert knew that Luke was very experienced but stubborn and liked to make last-minute changes. The role of the systems analyst was to design how to implement the Oracle system, and the developer (Jason) and the solutions engineer (Jasmine), should agree to the plan before the next FWT. Robert: So, what is going on? Could someone explain to me what is happening? Jasmine: We could not agree on how to handle flat file bit conversion. I am not sure if you’re familiar with the flat file. Robert: No, please explain. Jasmine: Okay, it is easier if I draw. (See Figure 3.2.) Jasmine: The new system must be able to receive the 16-bit from the existing system to ensure that input feeds are not misconfigured. So the new system must be programmed to handle it. The small box within the Implementation box is the conversion process that is going to be integrated into the introduction of the new database. This conversion block is Luke’s plan and the point of conflict. Jason and I are opposed to it, as it is beyond the scope and not part of the project plan. Figure 3.2 The Flat File Existing Input Flat File 16 Bit No Change New Implementation 16 to 8 bit Conversion New Database 8 Bit Existing Reports No Change 40 CASE STUDIES Luke: Robert, what I am suggesting is that this conversion process will satisfy the need to implement the project and it will not take long to develop. I do not see any reason to do the more complex work of programming the new DB to 16-bit capability. Why break a wall when you can walk around it? Robert: Luke, I realize the complexity of programming the 16-bit DB capability but your solution is suggesting a scope change. Again, we cannot spend more time going back and forth; once the plan is set we should abide to it. Therefore, scratch the conversion plan. Stick to the original script. Any questions? Luke: It does not make sense that we have to reinvent the wheel. I have learned a lot about this system during the development of the referential integrity (thousands of tables in the database connecting through a key or specific reference number). The conversion will take 18 hours less than developing a 16-bit database interface. Robert: I do realize and appreciate your enthusiasm but specification requirement documentation indicates that the new database will be 16-bit capable of interfacing the input of the 16-bit flat file. Even with discussions after discussions, Luke seemed not willing to concur. Robert looked for someone who could assist in solving this issue. Luke was a senior systems analyst and had been around for a while. He reported to a moresenior manager who was not easily accessible. Therefore, Robert decided to talk to his own manager, Steven, who was the program manager. Steven sent Luke an email informing him of the direction the project should take and carbon-copied Luke’s manager. Robert learned the next day that Luke conceded and the project was progressing ahead. Shortly after, with ...
Purchase answer to see full attachment
User generated content is uploaded by users for the purposes of learning and should be used following Studypool's honor code & terms of service.

Explanation & Answer



Project Management: Project Scope




Project management entails a series of complex and connected activities with a common
purpose. In today’s dynamic business environment, project management is regarded as a high
priority for all the companies or organizations are implementing it in all new undertakings,
innovations, and changes. The case study, project anatomy, outlines how a new project manager
assumed the responsibility of an already delayed project by utilizing the anatomy to identify
productivity bottlenecks and scheduling issues to bring back the project under control (Milosevic,
2010). The nature of the product in the case study was to develop a new central processor for the
AXE system. It was to be a state-of-the-art with a four-time increase in capacity of the system in
terms of, the quantity of transmission, speed, and bandwidth.
Project Anatomy
The anatomy is a project management approach used to drive the series of activities
involved in the development of a project. The central processor is a project in a context that
consisted of seven major projects each with subsequent subprojects. The primary objective of
using the p...

Excellent! Definitely coming back for more study materials.


Similar Content

Related Tags