Computer Science Books/Sem7/Spm
intermediate
Computer Science Books/Sem7/Spm
– 1 of 496 –
– 2 of 496 –
INFORMATION TECHNOLOGY PROJECT MANAGEMENT FOURTH EDITION
– 3 of 496 –
– 4 of 496 –
INFORMATION TECHNOLOGY PROJECT MANAGEMENT FOURTH EDITION Providing Measurable Organizational Value Jack T. Marchewka John Wiley & Sons, Inc.
– 5 of 496 –
VICE PRESIDENT & PUBLISHER Don Fowley EXECUTIVE EDITOR Beth Lang Golub EDITORIAL ASSISTANT Elizabeth Mills PROJECT EDITOR Rachael Leblond EXECUTIVE MARKETING MANAGER Christopher Ruel SENIOR PRODUCTION MANAGER Janis Soo ASSOCIATE PRODUCTION MANAGER Joyce Poh ASSISTANT PRODUCTION EDITOR Annabelle Ang-Bok DESIGNER Maureen Eide This book was set in 10/12 Times Roman by Laserwords Private Limited and printed and bound by Hamilton Printing. The book is printed on acid free paper. Founded in 1807, John Wiley & Sons, Inc. has been a valued source of knowledge and understanding for more than 200 years, helping people around the world meet their needs and fulfill their aspirations. Our company is built on a foundation of principles that include responsibility to the communities we serve and where we live and work. In 2008, we launched a Corporate Citizenship Initiative, a global effort to address the environmental, social, economic, and ethical challenges we face in our business. Among the issues we are addressing are carbon impact, paper specifications and procurement, ethical conduct within our business and among our vendors, and community and charitable support. For more information, please visit our website: www.wiley.com/go/citizenship. Copyright © 2012, 2009, 2006 John Wiley & Sons, Inc. All rights reserved. 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 Sections 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, Inc. 222 Rosewood Drive, Danvers, MA 01923, website www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030-5774, (201)748-6011, fax (201)748-6008, website http://www.wiley.com/go/permissions. Evaluation copies are provided to qualified academics and professionals for review purposes only, for use in their courses during the next academic year. These copies are licensed and may not be sold or transferred to a third party. Upon completion of the review period, please return the evaluation copy to Wiley. Return instructions and a free of charge return mailing label are available at www.wiley.com/go/returnlabel. If you have chosen to adopt this textbook for use in your course, please accept this book as your complimentary desk copy. Outside of the United States, please contact your local sales representative. Library of Congress Cataloging-in-Publication Data Marchewka, Jack T. Information technology project management : providing measurable organizational value / Jack T. Marchewka. –4th ed. p. cm. Includes bibliographical references and index. ISBN 978-1-118-05763-6 (pbk. : acid-free paper)
- Project management. 2. Information technology–Management. 3. Microsoft Project.
- Project management–Computer programs. I. Title. HD69.P75M367 2012 004.068’4–dc23 2011041419 Printed in the United States of America 10 9 8 7 6 5 4 3 2 1
– 6 of 496 –
The fourth edition is dedicated to Beth and Alma.
– 7 of 496 –
– 8 of 496 –
BRIEF CONTENTS CHAPTER 1 The Nature of Information Technology Projects 1 CHAPTER 2 Conceptualizing and Initializing the IT Project 30 CHAPTER 3 The Project Infrastructure 76 CHAPTER 4 The Human Side of Project Management 103 CHAPTER 5 Defining and Managing Project and Product Scope 135 CHAPTER 6 The Work Breakdown Structure and Project Estimation 156 CHAPTER 7 The Project Schedule and Budget 198 CHAPTER 8 Managing Project Risk 246 CHAPTER 9 Project Communication, Tracking, and Reporting 280 CHAPTER 10 IT Project Quality Management 318 CHAPTER 11 Managing Organizational Change, Resistance, and Conflict 354 CHAPTER 12 Project Procurement Management and Outsourcing 380 CHAPTER 13 Leadership and Ethics 397 CHAPTER 14 Project Implementation, Closure, and Evaluation 420 APPENDIX: An Introduction to Function Point Analysis 441 INDEX 453 vii
– 9 of 496 –
– 10 of 496 –
CONTENTS PREFACE xxi ABOUT THE AUTHOR xxvii CHAPTER 1 The Nature of Information Technology Projects 1 Introduction 1 The Purpose of This Book 4 The State of IT Project Management 5 Why IT Projects Fail 8 Improving the Likelihood of Success 9 A Value-Driven Approach 9 A Socio-Technical Approach 10 A Project-Management Approach 11 A Knowledge-Management Approach 12 The Context of Project Management 13 What Is a Project? 13 Extreme Project Management 15 The Project Management Body of Knowledge (PMBOK R ©) 17 Project Management Knowledge Areas 17 Chapter Summary 19 Review Questions 19 Extend Your Knowledge 20 Global Technology Solutions 20 Husky Air—Pilot Angels 21 Husky Air Assignment 21 The Martial Arts Academy—School Management System 22 Case Studies 25 Bibliography 29 CHAPTER 2 Conceptualizing and Initializing the IT Project 30 Introduction 30 The Project Life Cycle and IT Development 31 Define Project Goal 32 Plan Project 32 Execute Project Plan 32 ix
– 11 of 496 –
x CONTENTS Close Project 33 Evaluate Project 33 The Systems Development Life Cycle (SDLC) 33 The PLC and The SDLC 35 An Information Technology Project Methodology (ITPM) 35 Phase 1: Conceptualize and Initialize 37 Phase 2: Develop the Project Charter and Detailed Project Plan 38 Phase 3: Execute and Control The Project 39 Phase 4: Close Project 39 Phase 5: Evaluate Project Success 40 IT Project Management Foundation 40 Project Management Process Group 40 Tools 41 Infrastructure 41 Project Management Knowledge Areas 41 The Business Case 42 What Is a Business Case? 42 Developing the Business Case 42 Step 1: Select the Core Team 43 Step 2. Define Measurable Organizational Value (MOV) 44 Step 3: Identify Alternatives 50 Step 4: Define Feasibility and Assess Risk 50 Step 5: Define Total Cost of Ownership 51 Step 6: Define Total Benefits of Ownership 52 Step 7: Analyze Alternatives 52 Step 8: Propose and Support the Recommendation 57 Project Selection and Approval 57 The IT Project Selection Process 58 The Project Selection Decision 58 Chapter Summary 62 Review Questions 62 Extend Your Knowledge 63 Global Technology Solutions 64 Husky Air Assignment—Pilot Angels 64 The Martial Arts Academy (MAA)—School Management System 66 Case Studies 68 Bibliography 74 CHAPTER 3 The Project Infrastructure 76 Introduction 76 Project Integration Management 77
– 12 of 496 –
CONTENTS xi Project Management Processes 80 Project Management Process Groups 81 Initiating 81 Planning 81 Executing 82 Monitoring and Controlling 82 Closing 82 Product-Oriented Processes 82 Implementing the SDLC 83 Structured Approach to Systems Development 83 Iterative Systems Development 84 The Project Charter 85 What Should Be in a Project Charter? 87 Project Identification 87 Project Stakeholders 87 Project Description 87 Measurable Organizational Value (MOV) 87 Project Scope 87 Project Schedule 88 Project Budget 88 Quality Standards 88 Resources 88 Assumptions and Risks 88 Project Administration 89 Acceptance and Approval 89 References 89 Terminology 90 Project Planning Framework 91 The MOV 91 Define the Project’s Scope 91 Subdivide the Project into Phases 92 Tasks—Sequence, Resources, and Time Estimates 92 Sequence 93 Resources 93 Time 93 Schedule and Budget—The Baseline Plan 93 The Kick-Off Meeting 94 Chapter Summary 94 Review Questions 95 Extend Your Knowledge 95 Global Technology Solutions 96 Husky Air Assignment—Pilot Angels 97
– 13 of 496 –
xii CONTENTS The Martial Arts Academy (MAA)—School Management System 97 Case Studies 98 Bibliography 102 CHAPTER 4 The Human Side of Project Management 103 Introduction 103 Organization and Project Planning 104 The Formal Organization 105 The Functional Organization 105 The Matrix Organization 109 The Informal Organization 111 Stakeholders 112 Stakeholder Analysis 112 The Project Team 113 The Roles of the Project Manager 114 Team Selection and Acquisition 115 Team Performance 115 Work Groups 115 Real Teams 116 Project Teams and Knowledge Management 118 Learning Cycles and Lessons Learned 119 The Project Environment 123 Chapter Summary 123 Review Questions 126 Extend Your Knowledge 126 Global Technology Solutions 127 Husky Air Assignment—Pilot Angels 128 The Martial Arts Academy (MAA)—School Management System 129 Case Studies 130 Case Studies 133 Bibliography 134 CHAPTER 5 Defining and Managing Project and Product Scope 135 Introduction 135 Scope Management Processes 135 Scope Planning 136 Scope Boundary 137 The Statement of Work (SOW) 138 The Scope Statement 138
– 14 of 496 –
CONTENTS xiii Scope Statement 138 Out of Scope for This Project 139 Project Scope Definition 139 Project-Oriented Scope 139 Project-Oriented Scope Definition Tools 139 Product-Oriented Scope 141 Product-Oriented Scope Definition Tools 142 Project Scope Verification 145 Scope Change Control 145 Scope Change Control Procedures 146 Benefits of Scope Control 148 Chapter Summary 148 Review Questions 149 Extend Your Knowledge 149 Global Technology Solutions 150 Husky Air Assignment—Pilot Angels 150 The Martial Arts Academy (MAA)—School Management System 151 Case Studies 152 Bibliography 155 CHAPTER 6 The Work Breakdown Structure and Project Estimation 156 Introduction 156 The Work Breakdown Structure (WBS) 157 Work Packages 158 Deliverables and Milestones 158 Developing the WBS 159 The WBS Should Be Deliverable Oriented 161 The WBS Should Support the Project’s MOV 161 The Level of Detail Should Support Planning and Control 161 Developing the WBS Should Involve the People Who Will Be Doing the Work 161 Learning Cycles and Lessons Learned Can Support the Development of a WBS 161 Project Estimation 162 Guesstimating 162 Delphi Technique 162 Time Boxing 163 Top-Down Estimating 163 Bottom-Up Estimating 164 Software Engineering Metrics and Approaches 165 Lines of Code (LOC) 165 Function Points 166
– 15 of 496 –
xiv CONTENTS COCOMO 169 Heuristics 171 Automated Estimating Tools 172 What is the Best Way to Estimate IT Projects? 172 Chapter Summary 173 Web Sites to Visit 174 Review Questions 175 Extend Your Knowledge 175 Global Technology Solutions 176 Husky Air Assignment—Pilot Angels 177 The Martial Arts Academy (MAA)—School Management System 178 Case Studies 178 Microsoft Project Tutorial 1—Creating the Work Breakdown Structure (WBS) 181 Bibliography 197 CHAPTER 7 The Project Schedule and Budget 198 Introduction 198 Developing the Project Schedule 199 Gantt Charts 200 Project Network Diagrams 201 Activity on the Node (AON) 201 Critical Path Analysis 203 PERT 204 Precedence Diagramming Method 205 Critical Chain Project Management (CCPM) 206 Project Management Software Tools 208 Developing the Project Budget 210 Cost Estimation 210 Other Costs 212 Resource Allocation 214 Finalizing the Project Schedule and Budget 215 Chapter Summary 216 Review Questions 216 Extend Your Knowledge 217 Global Technology Solutions 217 Husky Air Assignment—Pilot Angels 218 The Martial Arts Academy (MAA)—School Management System 218 Case Studies 219 Microsoft Project Tutorial 2—The Baseline Project Plan 222 Bibliography 245
– 16 of 496 –
CONTENTS xv CHAPTER 8 Managing Project Risk 246 Introduction 246 IT Project Risk Management Planning Process 248 Risk Planning 249 Risk Identification 250 Risk Assessment 251 Risk Strategies 251 Risk Monitoring and Control 251 Risk Response 251 Risk Evaluation 252 Identifying IT Project Risks 252 An IT Project Risk Identification Framework 252 Applying the IT Project Risk Identification Framework 254 Other Tools and Techniques 255 Risk Analysis and Assessment 257 Qualitative Approaches 258 Expected Value 258 Decision Trees 259 Risk Impact Table 259 Quantitative Approaches 261 Discrete Probability Distributions 261 Continuous Probability Distributions 261 PERT Distribution 263 Triangular Distribution 263 Simulations 264 Risk Strategies 268 Risk Monitoring and Control 270 Risk Response and Evaluation 270 Chapter Summary 271 Web Sites to Visit 272 Review Questions 272 Extend Your Knowledge 273 Global Technology Solutions 273 Husky Air Assignment—Pilot Angels 274 The Martial Arts Academy (MAA)—School Management System 275 Case Studies 276 Bibliography 279 CHAPTER 9 Project Communication, Tracking, and Reporting 280 Introduction 280 Monitoring and Controlling the Project 282
– 17 of 496 –
xvi CONTENTS The Project Communications Plan 283 Project Metrics 285 Earned Value 287 Reporting Performance and Progress 292 Burn Down Chart 294 Information Distribution 295 Chapter Summary 297 Review Questions 297 Extend Your Knowledge 298 Global Technology Solutions 298 Husky Air Assignment—Pilot Angels 299 The Martial Arts Academy (MAA)—School Management System 300 Case Studies 301 Microsoft Project Tutorial 3—Tracking and Reporting 304 Bibliography 317 CHAPTER 10 IT Project Quality Management 318 Introduction 318 Quality Tools and Philosophies 321 Scientific Management 321 Control Charts 323 The Total Quality Movement 324 Quality Planning, Improvement, and Control 326 Cause and Effect of Diagrams, Pareto Charts, and Flow Charts 326 Quality Systems 328 International Organization for Standardization (ISO) 328 Six Sigma (6σ ) 330 The Capability Maturity Model Integration (CMMI) 331 Level 1: Initial 334 Level 2: Repeatable 334 Level 3: Defined 334 Level 4: Managed 335 Level 5: Optimizing 335 The IT Project Quality Plan 337 Quality Philosophies and Principles 337 Focus on Customer Satisfaction 338 Prevention, Not Inspection 338 Improve the Process to Improve the Product 338 Quality Is Everyone’s Responsibility 338 Fact-Based Management 339 Quality Standards and Metrics 339
– 18 of 496 –
CONTENTS xvii Verification and Validation 340 Change Control and Configuration Management 342 Monitor and Control 343 Learn, Mature, and Improve 345 Chapter Summary 345 Review Questions 346 Extend Your Knowledge 347 Global Technology Solutions 348 Husky Air Assignment—Pilot Angels 349 The Martial Arts Academy (MAA)—School Management System 349 Case Studies 350 Bibliography 353 CHAPTER 11 Managing Organizational Change, Resistance, and Conflict 354 Introduction 354 The Nature of Change 356 Change Has an Impact 356 Change Is a Process 358 Change Can Be Emotional 359 The Change Management Plan 360 Assess Willingness, Readiness, and Ability to Change 360 Sponsor 360 Change Agents 361 Targets 361 Develop or Adopt a Strategy for Change 362 Rational-Empirical Approach 362 Normative-Reeducation Approach 363 Power-Coercive Approach 363 Environmental-Adaptive Approach 364 Implement the Change Management Plan and Track Progress 364 Evaluate Experience and Develop Lessons Learned 365 Dealing with Resistance and Conflict 365 Resistance 365 Conflict 366 Chapter Summary 369 Review Questions 370 Extend Your Knowledge 371 Global Technology Solutions 371 Husky Air Assignment—Pilot Angels 372 The Martial Arts Academy (MAA)—School Management System 373
– 19 of 496 –
xviii CONTENTS Case Studies 374 Bibliography 379 CHAPTER 12 Project Procurement Management and Outsourcing 380 Introduction 380 Project Procurement Management 381 The Project Procurement Management Processes 381 Plan Procurements 382 Conduct Procurements 383 Contracts between Sellers and Buyers 383 Administer Procurements 385 Close Procurements 385 Outsourcing 386 The Beginning of the Outsourcing Phenomenon 386 Types of Outsourcing Relationships 387 The Realities of Outsourcing 387 Managing the Outsourcing Relationship 388 Chapter Summary 390 Review Questions 390 Extend Your Knowledge 391 Global Technology Solutions 391 Husky Air Assignment—Pilot Angels 392 The Martial Arts Academy (MAA)—School Management System 392 Case Studies 393 Bibliography 396 CHAPTER 13 Leadership and Ethics 397 Introduction 397 Project Leadership 398 Some Modern Approaches to Leadership 399 Leadership Styles 400 Emotional Intelligence 402 Ethics in Projects 404 Ethical Leadership 405 Common Ethical Dilemmas 406 Making Sound Ethical Decisions 407 Codes of Ethics and Professional Practices 409 Multicultural Projects 410 The Challenges of International Projects 410 Understanding and Managing Diversity 412 Chapter Summary 413
– 20 of 496 –
CONTENTS xix Review Questions 414 Extend Your Knowledge 414 Global Technology Solutions 415 Husky Air Assignment—Pilot Angels 416 The Martial Arts Academy (MAA)—School Management System 416 Case Studies 416 Bibliography 419 CHAPTER 14 Project Implementation, Closure, and Evaluation 420 Introduction 420 Project Implementation 421 Direct Cutover 421 Parallel 422 Phased 422 Administrative Closure 423 Project Sponsor Acceptance 426 The Final Project Report 427 The Final Meeting and Presentation 427 Closing the Project 428 Project Evaluation 428 Individual Performance Review 429 Postmortem Review 429 Project Audit 430 Evaluating Project Success—The MOV 431 Chapter Summary 432 Review Questions 433 Extend Your Knowledge 434 Global Technology Solutions 434 Husky Air Assignment—Pilot Angels 435 The Martial Arts Academy (MAA)—School Management System 436 Case Studies 436 Bibliography 440 APPENDIX: An Introduction to Function Point Analysis 441 INDEX 453
– 21 of 496 –
– 22 of 496 –
PREFACE Welcome to Information Technology Project Management—Providing Measurable Organiza- tional Value (4th Edition). This book was written to help you learn the processes, tools, tech- niques, and areas of knowledge needed to successfully manage information technology (IT) projects. The idea of project management has been around for a long time. In fact, it was around before the great pyramids of Egypt were created. Today, project management has emerged as its own field, supported by a body of knowledge and research. Although still relatively new, the fields of management information systems (MIS) and software engineering have their own bodies of knowledge that include various tools, techniques, and methods supported by a continually growing base of research. Unfortunately, the track record for IT projects has not been as successful as one might expect, although the situation appears to be improving. One reason for this improvement has been a greater focus on a project management approach to support the activities required to develop and deliver a product, service, or information system. Just as building a system is more than sit- ting down in front of a computer and writing code, project management is more than just creating fancy charts or diagrams using one of the more popular project management software packages. We can, however, build a system that is a technical success but an organizational failure. Information systems—the products of IT projects—are planned organizational change. Informa- tion technology is an enabler for new products, services, and processes that can change existing relationships between an organization and its customers or suppliers, as well as among the people within the organization. This change can represent a threat to many groups. Therefore, people may not always be receptive to a new IT solution regardless of how well it was built or whether cutting edge technology, tools, and techniques are used. On the other hand, people in an organization may rightfully resist an information system that does not function properly or meet their envisioned needs. Therefore, we must take an approach that does not consider the technical side over the organizational side or vice versa. Attention to both the technical and organizational sides of IT projects must be balanced in order to deliver a successful project. APPROACH In writing this book, I have tried to create a balance between concept and application. Many project management books tend to cover a broad set of topics with little practical application. Others tend to focus on the tools and techniques, but fall short in showing how everything ties together. This book was written with the student in mind. Many years ago—more than I would care to admit—when I was a student, one of my instructors said that the problem with many textbooks was that they were written by professors for other professors. That statement stuck with me over the years. When I first began writing this text, I wanted to be sure that it was written with the student in mind. Learning and understanding how to apply new concepts, tools, and techniques can be chal- lenging enough without being made more complex by obscure writing. As you will find out, xxi
– 23 of 496 –
xxii PREFACE learning concepts is relatively easy when compared to putting them into good practice. This book is intended for both undergraduate and graduate students. While it has no specific prereq- uisites, you should have at least an introductory class in information systems or programming under your belt. You should find that the concepts of IT project management will complement courses in systems analysis and design. Those of you who are undergraduates will not be thrust into the role of a project manager immediately after graduation. My goal is to help prepare you for the next several progressions of your career. For example, your first assignment may be to work on a project as a programmer or analyst. The knowledge that you will gain from this text will give you a good idea of how your work fits into the big picture so that you can be a more valuable project team member. More challenging and interesting assignments and opportunities for advancement will follow as you continue to gain more knowledge and experience. Eventually, this may lead to a leadership role where your knowledge and experience will be put to the optimal test. On the other hand, you may have already acquired some experience and now find yourself in the role of a project manager. This text will provide you not only with the big picture, but also with a foundation for applying directly the tools, processes, and methods to support the management and delivery of a successful IT project. This book follows a generic information technology project methodology (ITPM). Most students who read this book will never have been on a real IT project. I have written this book based on a flexible methodology that attempts to bridge the questions: How do I get started?, What do I do next?, How do we know when we’re finished? This methodology provides a structure for understanding how projects are initiated, conceptualized, planned, carried out, terminated, and evaluated. This methodology will take you through the different phases of the project life cycle and introduce the concepts and tools that are appropriate for each specific phase or stage of the project. In addition, you will find the methodology and central theme of this text is that IT projects should provide measurable value to organizations. The text provides an integrated approach to IT project management. It incorporates the nine areas outlined in the Project Management Institute’s Project Management Body of Knowledge (PMBOK®). The concepts associated with information systems management and software engi- neering when integrated with PMBOK® provide an important base of knowledge that builds a foundation for IT project management. This integration helps to distinguish IT projects from other types of projects such as construction or engineering. The text also integrates a knowledge management approach. The area of knowledge man- agement is an area of growing interest and development. Knowledge management is a systematic process for acquiring, creating, synthesizing, sharing, and using information, insights, and expe- riences to create business value. Here, the concept of learning cycles provides a unique approach for defining and creating new knowledge in terms of lessons learned. These lessons learned can be stored in a repository and made available throughout the organization. Best practices can be developed from the lessons learned and integrated or made a part of an organization’s IT project methodology. Over time, the generic ITPM introduced in this text can evolve and become a valuable asset to an organization as it becomes aligned with the organization’s culture and busi- ness. In turn, this evolving process will provide the organization with increased capability and maturity that hopefully will increase the likelihood of successful projects. CHAPTER OVERVIEWS The material in each chapter provides a logical flow in terms of the phases and processes required to plan and manage an IT project. The text begins with a call for a better way to manage IT
– 24 of 496 –
PREFACE xxiii projects and then focuses on the deliverables and processes required to initiate a project. Once a decision to approve and fund an IT project is made, the project must be planned at a detailed level to determine the schedule and budget. The planning and subsequent execution of the project’s plan are supported by the project management and information technology bodies of knowledge. ■ Chapter 1: The Nature of Information Technology Projects includes defining what a project is and the discipline of project management. The concepts of the project life cycle and systems development life cycle are also introduced, as well as IT project governance and the project selection process. ■ Chapter 2: Conceptualizing and Initializing the IT Project introduces an information technology project management methodology (ITPM) and the concept of measurable organizational value (MOV), which will provide a foundation for this text. In addition, the first phase of this methodology, conceptualizing and initializing the project, and the first deliverable of this methodology, the business case, are described and discussed. ■ Chapter 3: The Project Infrastructure introduces a knowledge area called project inte- gration management. A project planning framework is also described to support the development of the project plan. ■ Chapter 4: The Human Side of Project Management describes the formal and informal organization so that the project manager and team can conduct a stakeholder analysis to better understand the organizational landscape. Project team selection and the roles of the project manager are discussed, as is the concept of learning cycles to support a knowledge management approach to IT project management. ■ Chapter 5: Defining and Managing Project and Product Scope introduces and describes the project management knowledge area called project scope management. The project’s scope defines what the team will and will not deliver to the sponsor or client. Scope management processes also ensure that the scope is properly defined and that controls are in place in order to manage scope throughout the project. ■ Chapter 6: The Work Breakdown Structure and Project Estimation describes the project management tool called the work breakdown structure (WBS), which breaks up the project’s scope into work packages that include specific deliverables and milestones. Several traditional project estimation approaches are introduced, as well as several soft- ware engineering techniques and metrics for software estimation. ■ Chapter 7: The Project Schedule and Budget introduces several project management tools, including Gantt charts, activity on the node (AON), critical path analysis, program evaluation and review technique (PERT), and precedence diagramming, that aid in the development of the project schedule. A budget can then be developed based upon the activities defined in the WBS, the schedule, and the cost of the resources assigned or required. ■ Chapter 8: Managing Project Risk describes the concept of risk management and intro- duces a framework for defining and understanding the integrative nature of risks asso- ciated with an IT project. Several qualitative and quantitative approaches and tools are introduced for analyzing and assessing risks so that appropriate risk strategies can be formulated. ■ Chapter 9: Project Communication, Tracking, and Reporting focuses on developing a communication plan for reporting the project’s progress to various project stakeholders. This chapter includes an introduction to the concept of earned value and several common project metrics to monitor and control the project.
– 25 of 496 –
xxiv PREFACE ■ Chapter 10: IT Project Quality Management provides a brief history of the quality movement, the people involved, and their philosophies and teachings as an underpinning to support the project quality objective. Several quality systems to support IT project quality are also discussed. These include the International Standards Organization (ISO), Six Sigma, and the capability maturity model (CMM). Together, the concepts, teachings, philosophies, and quality system approaches provide a basis for developing the IT project quality plan. ■ Chapter 11: Managing Organizational Change, Resistance, and Conflict describes the nature and impact of change associated with the delivery of an information system on the people within an organization. Several organizational change theories are introduced so that a change management plan can be formulated and executed in order to ease the transition from the current system to the system that will be implemented. ■ Chapter 12: Project Procurement Management and Outsourcing introduces several project procurement management processes. This PMBOK® knowledge area focuses on con- tract management and the processes needed to administer relationships with outside suppliers and vendors as well as clients or customers. In addition, outsourcing of orga- nizational and project components has received a great deal of attention. This chapter describes the various types of outsourcing relationships as well as how an outsourcing relationship should be managed. ■ Chapter 13: Leadership and Ethics describes some modern approaches to leadership and the relationship with ethics. Some common ethical dilemmas that may be encountered on projects are introduced along with a process for making sound ethical decisions. Moreover, several challenges and issues associated with managing multicultural projects are discussed as more organizations attempt to diversify their workforce or conduct business across the globe. ■ Chapter 14: Project Implementation, Closure, and Evaluation describes the tactical approaches for installing and delivering the project’s product—the information sys- tem. In addition, the processes for bringing closure to the project and evaluating the project team and the project’s MOV are discussed. ■ Appendix: An Introduction to Function Point Analysis provides a more detailed discus- sion on counting function points than is provided in Chapter 6. WHAT’S NEW IN THE FOURTH EDITION ■ The Project Management Body of Knowledge areas have been updated to reflect the latest edition of the PMBOK Guide®. ■ Several Quick Thinking exercises have been replaced or updated. These short cases provide a useful pedagogical tool for in-class discussions to increase a student’s level of learning. ■ A new integrated case called the Martial Arts Academy has been added at the end of each chapter. Along with the Husky Air cases, these cases provide students with an opportunity to work as a project team and apply the concepts presented in each chapter. ■ A third and new case has been added to the end of each chapter. These cases provide an opportunity for higher-level analysis and discussion. Many of the new cases also provide in depth material on some of the more recent developments in project management and information systems development techniques, processes, concepts, and best practices used in many organizations today.
– 26 of 496 –
PREFACE xxv ■ Three Microsoft Project® tutorials have been added to the 4th edition. These tutorials provide a foundation for learning, using, and applying the concepts of the text to the integrated case assignments. ORGANIZATION AND SUPPORT An instructor’s manual, test bank, and presentation slides are available through the Wiley website. A 60-day trial edition of Microsoft Project is packaged with every new textbook. Note that Microsoft has designed the trial version to be installed only once. If you have purchased a used book and a prior user has installed the software, you will not be able to install it. Also, please be aware that Microsoft has changed their policy and no longer offers the 120-day trial available with previous editions of this textbook. Another option now available to education institutions adopting this Wiley textbook is a free 3-year membership to the MSDN Academic Alliance. The MSDN AA is designed to provide the easiest and most inexpensive way for academic departments to make the latest Microsoft software available in labs, classrooms, and on student and instructor PCs. Microsoft Project 2007 software is available through this Wiley and Microsoft publishing partnership, free of charge with the adoption of any qualified Wiley textbook. Each copy of Microsoft Project is the full version of the software, with no time limitations, and can be used indefinitely for educational purposes. Contact your Wiley sales representative for details. For more information about the MSDN AA program, go to http://msdn.microsoft.com/academic/. ACKNOWLEDGMENTS I would like to thank my editor Beth Lang Golub, as well as Elizabeth Mills and Rachael Leblond for all their help in writing this 4th edition. Also, I would like to thank the following reviewers for their valuable insight, comments, and suggestions. John Taz Lake Georgia State University Dushan Gasich San Jose State University John Towns College of Notre Dame of Maryland James Fogal Notre Dame De Namur University Mark Huber University of Georgia David Riske Western Nevada College Paul Licker Oakland University Eric Ackerman Nova Southeastern University Alan Sixsmith University of Technology, Sydney Anthony Scime The College at Brockport Phyllis Chasser Nova Southeastern University Howard Woodard Georgia College & State University David Riske Western Nevada College Siti Arshad-Snyder Clarkson College Gene Akers Auburn University Montgomery David Firth The University of Montana
– 27 of 496 –
xxvi PREFACE Barry Flachsbart Missouri University of Science & Technology Richard Will University of South Florida Richard Lomax Bellevue University Valarie Griep University of Minnesota Toru Sakaguchi Northern Kentucky University Charles Collins Bellevue University
– 28 of 496 –
ABOUT THE AUTHOR J ack T. Marchewka is a professor of Management Information Systems at Northern Illinois University. He received his Ph.D. from Georgia State University’s department of Computer Information Systems and was a former faculty member at Kennesaw State University. Prior to entering academia, Dr. Marchewka was a vice president of MIS for a healthcare company in Atlanta, Georgia. Dr. Marchewka has taught a number of courses at both the undergraduate and graduate levels and has been a guest lecturer at the Rotterdam School of Management at Erasmus Uni- versity in the Netherlands and the University of Bordeaux in France. His current research primarily focuses on IT project management, and his articles have appeared in such journals as Information Resources Management Journal, Information Technology and People, Journal of International Technology and Information Management, Communications of the IIMA, and Information Management. He is currently a board member and fellow of the International Information Manage- ment Association, where he has served as program chair, conference chair, and past president. Dr. Marchewka was also editor of the Communications of IIMA. Jack Marchewka is also a black belt in Kajukenbo and an instrument-rated commercial pilot who enjoys his family, karate, fishing, playing guitar, good BBQ, riding his motorcycle, and a good laugh. xxvii
– 29 of 496 –
– 30 of 496 –
C H A P T E R 1 The Nature of Information Technology Projects CHAPTER OBJECTIVES Chapter 1 provides an overview of information technology project management (ITPM). After studying this chapter, you should understand and be able to: ■ Describe the dominant eras of information systems called the electronic data processing (EDP) era, the micro era, the network era, and the globalization era, and understand how managing IT projects has evolved during these eras. ■ Understand the current state of IT project management and how successfully managing IT projects remains a challenge for most organizations. ■ Explain the value-driven, socio-technical, project management, and knowledge management approaches that support ITPM. ■ Define what a project is and describe its attributes. ■ Define the discipline called project management. ■ Describe the role and impact IT projects have on an organization. ■ Identify the different roles and interests of project stakeholders. ■ Describe eXtreme project management. ■ Identify the Project Management Body of Knowledge (PMBOK®) core knowledge areas. INTRODUCTION Information technology (IT) projects are organizational investments. When an organization builds or implements an IT solution, it often commits considerable time, money, and resources to the project with an expectation of receiving something of value in return. To improve the chances of success, you will be introduced to a relatively new discipline called information technology project management (ITPM). Some may argue that managing an IT project is like managing any other project, so all we need to do is apply the processes, tools, and techniques of traditional project management. This may be true to some degree, but a one-size-fits-all approach has not served us all that well in the past. Moreover, building an information system is different from building a house, a bridge, or a rocket for space travel. Although many of the project processes are similar, an entirely different approach to engineering each of these examples is needed. By combining the body of knowledge of modern-day project management with the body of knowledge of management information systems (in particular, software engineering 1
– 31 of 496 –
2 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS and systems analysis and design), we can craft a better philosophy and method for planning and managing IT projects. This will provide a foundation for a logical and repeatable approach that improves the likelihood of IT project success. Modern-day project management is often credited to the U.S. Navy, with its initiation of the Polaris missile project as a way to deter potential Soviet nuclear aggression in the early 1950s. The Polaris project was complex and risky, but the Navy used a project management approach to take the project from concept to deployment. This approach was viewed as a great success, and other organizations in various industries began to adopt project management as a way to define, manage, and execute work to achieve a specific objective. Today, project management is viewed as an effective approach that addresses a wide variety of organizational opportunities and challenges. Project management focuses on reducing costs and product cycle times and provides an important link between an organization’s strategy and the deployment of that strategy. In turn, this will have a direct impact on an organization’s bottom line and competitiveness. The field of information systems also evolved in parallel with the field of modern project management. According to Richard Nolan, a consultant and Harvard business professor, the use of the business computer has gone through a series of three dominant eras: the electronic data processing (EDP) era, the micro era, and the network era. However, some people believe that we are entering into a new era called globalization. We can look at each of the first three eras to understand how technology supported organizations and the approaches used to manage these projects. As we enter a new era of globalization, many projects can benefit from a foundation built upon past experience and knowledge, but new ways will be needed to overcome many of the challenges and issues that will be encountered. The EDP era began in the early 1960s and is characterized by the purchase of the first centralized mainframe or a minicomputer by large organizations. The IT projects during this era focused generally on automating various organizational transactions such as general account- ing tasks, inventory management, and production scheduling. The manager of this technology resource was often called the data processing (DP) manager and usually reported to the head accounting or financial manager. The goal of using technology was to improve efficiency and reduce costs by automating many of the manual or clerical tasks performed by people. As Richard Nolan (2001) points out, software programmers applied computer technology similar to the ways that farmers or engineers applied steam engine technology to mechanize agriculture. The process remained relatively unchanged, while the means for realizing the process became more efficient. Subsequently, IT projects during this era were generally structured, and there- fore a structured approach for managing these projects could be used. Since the requirements or business processes were fairly stable, changing requirements were not a major issue and large, multiyear projects were common. Unfortunately, in many cases these legacy systems created information silos, as projects supported specific business functions that often employed different technology platforms, programming languages, and standards for data. In the early 1980s, the IBM personal computer (PC) and its subsequent clones signaled the beginning of the micro era. However, the transition or integration from a centralized computer to the PC did not happen immediately or without conflict. The often uncontrolled proliferation of the PC in many organizations challenged the centralized control of many MIS managers. For example, the first PCs cost less than $5,000 and many functional department managers had the authority to bypass the MIS manager and purchase these machines directly for their department. This often led to the rise of user-developed, independent systems that replicated data throughout the organization. Security, data integrity, maintenance, training, support, standards, and the sharing of data became a rightful concern. The organization often had an IT resource that was split between a centralized computer and a collection of decentralized user-managed PCs. The organization needed to regain control of its IT resource while using IT strategically. Many organizations created the new position called the chief information officer (CIO) to expand
– 32 of 496 –
INTRODUCTION 3 the role of IT within the organization. While the DP manager often reported to the head account- ing or financial manager, the CIO often reported to the chief executive officer (CEO). Therefore, IT increasingly became viewed as more than just a tool for automating low-level transactions and more of a tool for supporting the knowledge worker. Shoshana Zuboff (1988) coined the term “infomate” to describe the role of computers in this era. The computer no longer remained under the direct control of the IT function and its spread throughout the various levels of the organization made IT ubiquitous. IT projects had to take more of an organizational view so that policies, standards, and controls become a part of all systems in order for existing mainframe or minicomputer applications to coexist or integrate with a growing surge of PCs. Moreover, a project manager and team could no longer rely on stable business processes, requirements, or technology that would allow for longer project schedules; otherwise, they would face the risk of implementing an obsolete IT solution. Shorter project horizons that crossed functional lines became the norm, while software development methodologies attempted to shorten the development life cycle. Meanwhile, in the late 1960s and early 1970s, a defense project called ARPANET allowed university researchers and scientists to share information with one another even in the event of a nuclear war. By the mid-1980s, this network of computers became known as the Internet and led to the network era that began around 1995. In the network era, IT projects focused primarily on the challenge of creating an IT infrastructure to support many partners, strategic alliances, vendors, and customers. The network architecture had to be scalable so that potentially thousands of networked computers could function in an efficient and timely manner. Moreover, digital convergence or the integration of data, voice, graphics, and video allowed for new and innovative ways to deliver new products and services to customers. While the micro era focused on creating an internal network within the organization, the thrust of the network era was to extend this network externally. Network era projects not only faced the challenge of coordination and control, but also how to support a dynamic business strategy and new organizational structures. IT project members not only needed to understand the technology, but the organization and its competitive environment. As witnessed by the rise and fall of many dot com businesses in the late 1990s, the benefits and risks of managing IT projects were much higher than the two previous eras. With the new millennium, IT received a great deal of attention in the media and the board- room. Some people at the end of the century emptied their bank accounts and stockpiled food and water for fear that computers would crash and civilization would fall into mass confusion. Fortunately, the reported Y2K computer-related problems were few and not too critical. But what made the Y2K problem fascinating was that just about everyone was in it together and the project had an immovable deadline. To fix the Y2K date problem in the millions of lines of code, many organizations took advantage of cheaper wage rates and outsourced the rewriting of its code overseas to such countries as India. After Y2K, it appeared that organizations now had the time and money to start on the IT projects that had been put on hold. Electronic commerce, enterprise resource planning (ERP) and customer relationship management (CRM) systems were at the top of the IT project list for many organizations. Together with large, global investments in fiber optics and the rise of the dot coms, the demand for skilled IT professionals and IT project managers to head up these new initiatives had never been stronger. Recruiters couldn’t hire experienced professionals and university graduates fast enough to meet the demand. Unfortunately, this golden time for IT did not last, especially in the United States. The tragic events of September 11, 2001 had a profound impact on the world and the global economy. As a result, many organizations were forced to make some difficult choices in order to survive. Seasoned IT professionals and new graduates who once commanded high salaries and choice assignments found themselves facing a tough job market. The bubble had burst. People learned that things can change quickly and without warning.
– 33 of 496 –
4 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS According to Richard Nolan, people, organizations, and even society goes through a period of discontinuity whereby people try to make sense of the changes created by the transition from one era to the next. Some people such as Thomas L. Friedman (2007) suggest that we may be entering into a new era called globalization. According to Friedman, the combination of technology and lowering of political barriers has flattened the world so that it is possible for people and organizations to work with almost anyone in any place and at any time. Moreover, the real IT revolution is just beginning as the global competitive playing field becomes leveled for everyone. What does this mean for you? As a project manager or member of a project team you will be involved in projects that are more dynamic, geographically dispersed, and ethnically or culturally diverse than ever before. The risk and rewards will be greater than the previous eras. Therefore, a solid set of technical, nontechnical, and project management skills founded upon past experience and adapted to this new environment will be needed to manage IT projects successfully. In both good times and bad, senior management will make a certain level of funding available for IT projects. The budgeted amount will depend on such things as the economy, com- petitors’ actions within the industry, and the organization’s strategic plan. Regardless whether an organization’s budget for IT projects shrinks or grows, the resources available for any given period will be relatively fixed. Quite often the total funding requests for proposed projects will be greater than the available budget. As a result, any project that receives funding will do so at the expense of another project. The competition for funding IT projects proposed by the various business units or departments within an organization will be especially keen when the budget is tight. Projects that do not receive any funding will either have to wait or fall by the way- side. Therefore, the decision to fund a specific project will always be an important management decision because it will have a major impact on the organization’s performance. The decision to fund or invest in an IT project should be based on the value that the completed project will provide the organization. Otherwise, what is the point of spending all that time, effort, and money? Although senior management must make the difficult decision as to which IT projects receive funding and which ones do not, others must plan and carry out the project work. Which situation is worse: successfully building and implementing an information system that provides little or no value to the organization, or failing to implement an information system that could have provided value to the organization, but was developed or managed poorly? It’s probably a moot point: In either situation everyone with a direct or indirect interest in the project’s success loses. The Purpose of This Book The goal of this book is to help you to plan and manage information technology projects. We will focus on a number of different theories, but the main emphasis will be on applying the methods, tools, techniques, and processes for planning and managing an IT project from start to finish. If you are a project manager (or will be one soon), this book will help you to understand and apply project management principles in order to better manage your IT project. If you are just starting out in the field, this book will help you to understand the big picture of what an IT project is all about. This knowledge will help you to become a better team member and prepare you for the next several progressions in your career. Many of the principles of project management can be applied to just about any project, but IT projects are unique in several ways. Throughout the text, we will discuss what makes IT projects different from other types of projects and how the principles and methods of system development can be integrated to define the IT project management discipline. Although many
– 34 of 496 –
THE STATE OF IT PROJECT MANAGEMENT 5 of the concepts for developing an information system will be integrated throughout, this is not a systems analysis and design text. More specifically, we will not delve too deeply into the systems analysis and design techniques that are used during systems development. We will leave that for other books and classes. The remainder of this book provides a foundation for understanding project planning pro- cesses, methods, and tools. We will begin by understanding the nature of IT projects and then follow the project life cycle from project initiation through implementation and closure. Throughout the book you will be introduced to a number of project management knowledge areas and related software engineering concepts. While the goal of this book is not to prepare you for a professional certification in project management, it will provide a solid base to help you in your career and later on should you choose to become a certified project manager. THE STATE OF IT PROJECT MANAGEMENT Although IT is becoming more reliable, faster, and less expensive, the costs, complexity, and risks of managing IT projects continues to be a challenge for many organizations. Although IT projects have experienced challenges since the DP era, a survey conducted by the Standish Group of 365 IT managers in 1994 drew attention to what many called the software crisis. The study was called CHAOS and reported that only 16 percent of the application development projects were successful in terms of being completed on time and within budget. Moreover, about 31 percent of the projects were canceled before completion, while 53 percent were completed but over budget, over schedule, and not meeting original specifications. The average cost overrun for a medium-size company surveyed was about 182 percent of the original estimate, while the average schedule overrun was about 202 percent. That is, the results of the survey suggest that a medium-size project estimated to cost about $1 million and take a year to develop actually cost about $1.8 million, took just over two years to complete, and only included about 65 percent of the envisioned features and functions. Many took this to mean that IT project management was in a state of crisis, especially since 48 percent of the IT managers surveyed believed that there were more failures at the time than five or ten years earlier. The 1994 CHAOS study has become one of the most cited, and Robert Glass (2005) raises the issue that people tend to quote the original 1994 figures while ignoring the fact that the Standish Group has updated the CHAOS reports every two years. A key reason may be that the 1994 study is free and easily attainable from the Standish Group, while the later studies must be purchased and thus are an expensive barrier for many researchers and practitioners. Fortunately, a summary of the later studies can be found using a good Internet search engine. The latest findings of these studies from 1994 through 2008 are summarized in Figure 1.1. Overall, it appears that IT projects are showing a higher success rate. For example, the latest study in 2008 reports that 32 percent of the IT projects were classified as successful in terms of being completed on time, within budget, and including all of the features or requirements envisioned. The Standish Group attributes this continuing improvement to better project management tools and processes, smaller projects, improved communication, more skillful IT project managers, and iterative development. Interestingly, the CHAOS studies also report factors for successful and unsuccessful projects. Table 1.1 provides a summary of key factors for successful projects for four different time periods. It appears that successful projects have a strong nontechnical component in terms of executive support and user involvement that may lead to clearly defined requirements and project objectives, while the technology, tools, and methods play an important, but lesser, role.
– 35 of 496 –
6 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS 2006 2008 2004 2002 2000 1998 1996 1994 46% 35% 19% 53% 29% 18% 51% 34% 15% 49% 28% 23% 46% 26% 28% 33% 27% 40% 53% 16% 31% Sucessful Challenged Failed 44% 32% 24% Figure 1.1 Summary of CHAOS Studies from 1994 to 2008 Source: http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS. Table 1.1 Summary of CHAOS Study Factor Rankings for Successful Projects Rank 1994 2001 2006 2008 1 User Involvement Executive Support User Involvement User Involvement 2 Executive Management Support User Involvement Executive Management Support Executive Support 3 Clear Statement of Requirements Experienced Project Manager Clear Business Objectives Clear Business Objectives 4 Proper Planning Clear Business Objectives Optimizing Scope Emotional Maturity 5 Realistic Expectations Minimized Scope Agile Process Optimizing Scope 6 Smaller Project Milestones Standard Software Infrastructure Project Management Expertise Agile Process 7 Competent Staff Firm Basic Requirements Financial Management Project Management Expertise 8 Ownership Formal Methodology Skilled Resources Skilled Resources 9 Clear Vision and Objectives Reliable Estimates Formal Methodology Execution 10 Hard-working, focused team Other Standard Tools and Infrastructure Tools and Infrastructure Sources: Adapted from the Standish Group. CHAOS (West Yarmouth, MA: 1995, 2010) and http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
– 36 of 496 –
THE STATE OF IT PROJECT MANAGEMENT 7 The 2010 CHOAS Manifesto describes the most recent factors for project success: ■ User Involvement—Users can be thought of as the project’s customer. Users are impor- tant project stakeholders that should be involved in important decisions and because they may have vital knowledge of the business and processes not possessed by the more technical people. Working closely together, the users and developers can better understand the business opportunities and limitations of the technology. ■ Executive Support—The support of upper management is critical in terms of acquiring and maintaining financial backing for the project. Visible support by senior manage- ment is also important in terms of emotional support and negotiation or resolution of organizational conflicts. ■ Clear Business Objectives—The project’s stakeholders must focus on the core value of the project. This includes understanding the larger picture of how a particular project supports the business and organizational strategies. ■ Emotional Maturity—Projects are planned organizational change. Emotional maturity focuses on the ability and capability to understand and manage the emotions and actions of the various project stakeholders. This may include the ability to deliver bad news, accept criticism, or dealing rationally with various project challenges. ■ Optimization—The optimization of information technology centers making systems, processes, and people efficient and effective as possible in order to provide the highest level of value to the organization. For example, an information system should include only those feature and functions that help the users perform their job. Including extra functionality that the user doesn’t need or didn’t ask for is not optimal. ■ Agile Process—An agile process supports the user/developer relationship by encouraging team work, collaboration, and evolving requirements, while allowing for rapid delivery. ■ Project Management Expertise—Project managers must be skilled in both project man- agement knowledge and the organizational environment. On the other hand, the organi- zation must recognize and give support to the project manager and his/her expertise. ■ Skilled Resources—To be successful, a project manager must be able to acquire, manage, and control the right resources at the right time. This may include the ability to develop people or replace a key project team member due to turnover. ■ Execution—Projects are executed or carried out according to a plan. This first requires developing a realistic plan, but also requires leadership and project management knowl- edge and expertise for a successful outcome. ■ Tools and Infrastructure—This means having the right tool for job, but also having the skill to use that tool properly. Tools, such as Microsoft Project®, are useful for planning, managing, and communicating the progress of a project, but by themselves will not make a project successful. Tools and infrastructure must support the project management processes. However, a study of 800 senior IT managers from the U.K., United States, France, Germany, India, Japan, and Singapore conducted by Tata Consultancy Services (2007) reports dire results similar to the CHAOS Studies: ■ 62 percent of the IT projects failed to meet their schedules ■ 49 percent experienced budget overruns
– 37 of 496 –
8 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS Table 1.2 IT Project Success Criteria Criteria Response Schedule 61.3% said it is more important to deliver a system when it is ready to be shipped than to deliver it on time. Scope 87.3% said that meeting the actual needs of stakeholders is more important than building the system to specification. Money 79.6% said that providing the best return on investment (ROI) is more important than delivering a system under budget. Quality 87.3% said that delivering high quality is more important than delivering on time and on budget. Staff 75.8% said that having a mentally and physically healthy workplace is more important than delivering on time and on budget. Source: http://www.drdobbs.com/architecture-and-design/202800777. ■ forty-seven percent experienced higher than expected maintenance costs ■ forty-one percent failed to deliver the expected business value and return on investment (ROI) One criticism of the CHAOS Studies is that project success is defined in terms of whether projects were completed on-time, within-budget, and if it included all of the planned features and functionality (Dominguez, 2009). Another criticism is that the success/failure rates of the CHAOS Studies may be suspect if organizations define success differently. Table 1.2 summarizes the results of a survey of 600 business stakeholder and IT professionals by Scott Ambler (2007) and reports five success criteria that are different from the CHAOS Studies. All studies have strengths and weaknesses. More research over time and broader samples will allow us to better understand the state of IT project management. While we will never be able to achieve a 100 percent success rate for all projects, we should strive to understand why certain projects are successful and others are not. While some people may argue that the success rate for IT projects is getting better, there is still ample room for improvement. Why IT Projects Fail One reason for high failure rates in the CHAOS Studies may be the way we define “success” and “failure.” For example, Robert Glass (2005) asks, How should a project be classified if it is “functionally brilliant” but is over budget and over schedule by 10 percent? According to the CHAOS definition, this would be considered a failure, while in reality, it could be a success for the organization. However, no matter what value a project brings to an organization, a project that continues to exceed its budget and schedule will eventually exceed any potential or real value it can bring to the organization. The CHAOS Studies also provide some interesting insight as to why some projects fail. For example, Table 1.3 summarizes the project factors for not-so-successful projects to see what might be happening. Lack of user input or involvement ranks at or near the top in factors listed under challenged or failed (impaired) projects. One can almost picture that chain of events. Without close support of key users, the team will have a difficult time understanding and defin- ing the requirements of the project. As a result, suspicion and conflicts may arise, and there can easily be an “us versus them” situation between the developers and the users. Without effective communication and a clear direction, changes to the project’s requirements always seem to appear, and both the users and developers may set unrealistic expectations. Management then begins to find fewer reasons to support an unpopular project, and more and more resources may be diverted from it. The project is barely successful, if not a failure.
– 38 of 496 –
THE STATE OF IT PROJECT MANAGEMENT 9 Table 1.3 Summary of Factor Rankings for Challenged and Failed (Impaired) Projects Rank Factors for Challenged Projects Factors for Failed (Impaired) Projects 1 Lack of user input Incomplete requirements 2 Incomplete requirements Lack of user involvement 3 Changing requirements and specifications Lack of resources 4 Lack of executive support Unrealistic expectations 5 Technology incompetence Lack of executive support 6 Lack of resources Changing requirements and specifications 7 Unrealistic expectations Lack of planning 8 Unclear objectives Didn’t need it any longer 9 Unrealistic time frames Lack of IT management 10 New technology Technology illiteracy Source: Adapted from the Standish Group, CHAOS (West Yarmouth, MA: 1995). More recently, however, according to a Web-based poll conducted by Computing Technol- ogy Industry Association (CompTIA), nearly 28 percent of the more than 1,000 respondents said that poor communication is the number one reason for project failure, followed by insufficient resources (18 percent), and unrealistic schedule deadlines (13.2 percent) (Rosencrance, 2007). Communication is an important component throughout the project in terms of setting project expectations, requirements, as well as schedule and budget constraints. As seen in Table 1.3, a number of factors relating to challenged and failed projects can be attributed directly or indirectly to poor communication. Insufficient resources can be tied closely to poor communication. All projects require resources in terms of people, technology, and facilities. Communication is important in under- standing the appropriate number of people that will be needed, what skill sets they will need, the training that may be necessary, and the tools to do the job. Moreover, executive sponsors may accept schedule commitments from developers who offer no evidence that they can meet those commitments, while developers may accept schedules that are unrealistic. Not getting the right resources when they are needed may risk that the schedule will not be met. Unrealistic schedules may doom the project before it even starts. According to the CompTIA poll, other factors that contribute to project failure include poor project require- ments, lack of stake-holder buy-in/support, undefined project success/closure criteria, unrealistic budget, insufficient or no risk planning, and lack of control/change process. One can look at troubled projects to identify whether there are any signs of impending failure. These warning signs may include strained relationships among the project team members or between the project team and the client or users, excessive overtime, lost confidence, threats of legal action by the customer or client, and low project stakeholder moral. What becomes interesting is how many people have accepted IT project problems and failure as the status quo. Figure 1.2 provides a summary of Tata Consultancy Services survey in terms of how business managers and board of directors view IT project failure and problems. Improving the Likelihood of Success How can we improve the chances for IT project success and avoid repeating past mistakes? Here are four approaches that will be focal points throughout this book. A Value-Driven Approach Plain and simple: IT projects must provide value to the orga- nization. Many people and organizations define project success in terms of the project being
– 39 of 496 –
10 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS When IT projects have gone wrong, what has been the reaction from the business managers and the Board of Directors? Reduced IT budgets Tend to accept problems as the norm (i.e., a necessary evil) Continued to provide support to improve IT Don’t know None Looked for a scapegoat among IT staff Sought compensation from IT vendors Reluctant to fund new IT projects 19% 21% 43% 69% 1% 2% 9% 13% Figure 1.2 Reaction to Failed IT Projects by Business Managers and Board of Directors Source: http://www.tcs.com/pdf/Board%20research%20statistical%20factsheet.pdf. completed on time and within budget. While schedule and budget are important, they are not sufficient definitions of project success. For example, if an organization sets a mandate that a par- ticular customer relationship management (CRM) package must be up and running within eight months and cost no more than $1 million to implement, would the project be considered unsuc- cessful if it required an extra day and an extra dollar to complete? You may think this is trivial, but at exactly what point in terms of schedule or budget does the project become unsuccessful? We can also turn things around and ask whether finishing a project early and under budget necessarily makes the project successful. Of course, any organization would like to spend less money and have its system delivered early, but what if the system does not perform as expected? More specifically, what value will the organization receive by spending six months and $1 million on this particular project? If IT projects are investments, what measurable value will it receive to offset the time, money, and opportunity cost of purchasing and implementing the CRM system? This value could come in terms of better customer service, more efficient business processes, lower costs, or expanded market share. Therefore, success should not be measured in terms of schedule or budget, but in terms of value. This will put less pressure on project stakeholders to set unrealistic schedules and budget, since the value of the project will be the true measure of success. A Socio-Technical Approach In the past, organizations have attempted to improve the chances of IT project success by focusing on the tools, techniques, and methodologies of IT development. A purely technical approach, however, focuses attention on the technology. We can easily end up developing an application that no one asked for or needs. Applications to support electronic commerce, supply chain management, and integration require that at least equal attention be paid to the organizational side. The days of being good order takers are over. We can no
– 40 of 496 –
THE STATE OF IT PROJECT MANAGEMENT 11 QUICK THINKING—INVOLVING THE USER According to the Standish Group, users can be your best friend or your worst enemy. Projects can be viewed as an ecosystem where users and developers must work together to share knowledge, ideas, and information. The CHAOS Studies have shown that user involvement is one of the leading factors for project success, while lack of user involvement is a leading factor for project failure. The Standish Group recommends that correctly identifying the proper user or user group is crucial to project success because the right users will provide vital information and feedback. Conversely, the wrong users can lead the devel- opers down the wrong path by not specifying requirements accurately or completely. It is important to develop a good rapport and relationship with the user and user groups so that they feel involved and understand their roles and responsibilities as members of the project team. Good com- munication and feedback can also help achieve consensus and harmony regarding the project’s direction even though projects can be more of an autocracy than a democracy. Projects also need someone to play the role of an evan- gelist who believes strongly in the goal or value of the project and can help to gain the support of the rest of the user community and upper management.
- What are some key factors or characteristics you should consider when attempting to identify the correct user or user group to be part of a project team?
- What are some potential conflicts between users and developers? As a project manager, what steps could you take to minimize or avoid these conflicts to ensure that the user or user group is involved? Source: Adapted from the CHAOS Manifesto: The Laws of CHAOS and the CHAOS 100 Best PM Practices. The Standish Group. 2010. longer be content with defining a set of user requirements, disappearing for several months, and then knocking on the user’s door when it is time to deliver the new system. IT professionals must understand the business and be actively creative in applying the technology in ways that bring value to the organization. Similarly, the clients must become stakeholders in the project. This means actively seeking and encouraging their participation, involvement, and vision. The successful application of technology and the achievement of the project’s goal must be an equal responsibility of the developers and users. A Project-Management Approach One suggestion of the CHAOS study was the need for better project management. But, isn’t building an information system a project? Haven’t organi- zations used project management in the past? And aren’t they using project management now? While many organizations have applied the principles and tools of project management to IT projects, many more—even today—build systems on an ad hoc basis. Success or failure of an IT project depends largely on who is, or is not, part of the project team. Applying project management principles and tools across the entire organization, however, should be part of a methodology—the step-by-step activities, processes, tools, quality standards, controls, and deliverables that are defined for the entire project. As a result, project success does not depend primarily on the team, but more on the set of processes and infrastructure in place. A common set of tools and controls also provides a common language across projects and the ability to compare projects throughout the organization. In addition, other reasons for project management to support IT projects include: ■ Resources—When developing or purchasing an information system, all IT projects are capital projects that require cash and other organizational resources. Projects must be estimated accurately, and cost and schedules must be controlled effectively. Without the proper tools, techniques, methods, and controls in place, the project will drain or
– 41 of 496 –
12 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS divert resources away from other projects and areas of the organization. Eventually, these uncontrolled costs could impact the financial stability of the organization. ■ Expectations—Today, organizational clients expect IT professionals to deliver quality products and services in a professional manner. Timely status updates and communica- tion, as well as sound project management practices, are required. ■ Competition—Internal and external competition has never been greater. An internal IT department’s services can easily be outsourced if the quality or cost of providing IT services can be bettered outside the organization. Today, competition among consultants is increasing as they compete for business and talent. ■ Efficiency and effectiveness—Peter Drucker, the well-known management guru, defined efficiency as doing the thing right and effectiveness as doing the right thing. Many companies report that project management allows for shorter development time, lower costs, and higher quality. Just using project management tools, however, does not guar- antee success. Project management must become accepted and supported by all levels within the organization, and continued commitment in terms of training, compensation, career paths, and organizational infrastructure must be in place. This support will allow the organization to do the right things and do them right. A Knowledge-Management Approach A socio-technical approach and a commitment to project management principles and practices are important for success. However, excellence in IT project management for an individual or an organization takes time and experience. Knowledge management is a systematic process for acquiring, creating, synthesizing, sharing, and using information, insights, and experiences to transform ideas into business value. Although many organizations today have knowledge management initiatives under way, and spending on knowledge management systems is expected to increase, many others believe that knowledge management is just a fad or a buzzword. What about learning from experience? Experience can be a great teacher. These experiences and the knowledge gained from these experiences, however, are often fragmented throughout the organization. Chances are that if you encounter what appears to be a unique problem or situation, someone else in your organization has already dealt with that problem, or one very similar. Wouldn’t it be great to just ask that person what they did? What the outcome was? And, would they do it again the same way? Unfortunately, that person could be on the other side of the world or down the hall—and you may not even know! Knowledge and experience, in the form of lessons learned, can be documented and made available through the technologies accessible today, technologies such as the World Wide Web or local versions of the Web called intranets. Lessons learned that document both reasons for success and failure can be valuable assets if maintained and used properly. A person who gains experience is said to be more mature. Similarly, an organization that learns from its experiences can be more mature in its processes by taking those lessons learned and creating best practices—simply, doing things in the most efficient and effective manner. In terms of managing IT projects, managing knowledge in the form of lessons learned can help an organization develop best practices that allow all of the project teams within the organization to do the right things and then to do them right. As summarized in the CHAOS report: There is one aspect to be considered in any degree of project failure. All success is rooted in either luck or failure. If you begin with luck, you learn nothing but arrogance. However, if you begin with failure and learn to evaluate it, you also learn to succeed. Failure begets knowledge. Out of knowledge you gain wisdom, and it is with wisdom that you can become truly successful (Standish Group 2002, 4).
– 42 of 496 –
THE CONTEXT OF PROJECT MANAGEMENT 13 THE CONTEXT OF PROJECT MANAGEMENT What Is a Project? Although the need for effectively managing projects has been introduced, we still require a work- ing definition of a project and project management. The Project Management Institute (PMI), an organization that was founded in 1969, has grown to become the leading nonprofit professional association in the area of project management. In addition, PMI establishes many project man- agement standards and provides seminars, educational programs, and professional certification. It also maintains the Guide to the Project Management Body of Knowledge (PMBOK® Guide). The PMBOK® Guide (Project Management Institute, 2008) provides widely used definitions for project and project management. A project is a temporary endeavor undertaken to accomplish a uniqu
[…content truncated for processing]
