Information Technology Project Management PDF

 KEEP THIS CARD! Download a free 60-day trial of Microsoft Project Professional 2013 from the following web site: http://www.microsoft.com/en-us/evalcenter/evaluate-project-professional-2013 INFORMATION TECHNOLOGY PROJECT MANAGEMENT FIFTH ED...

 KEEP THIS CARD! Download a free 60-day trial of Microsoft Project Professional 2013 from the following web site: http://www.microsoft.com/en-us/evalcenter/evaluate-project-professional-2013 INFORMATION TECHNOLOGY PROJECT MANAGEMENT FIFTH EDITION Providing Measurable Organizational Value Jack T. Marchewka  The fifth edition is dedicated to Beth, Bill, Tim, Kellie Ann, and Matt. VICE PRESIDENT AND EXECUTIVE PUBLISHER Don Fowley EXECUTIVE EDITOR Beth Lang Golub EDITORIAL ASSISTANT Jayne Ziemba SPONSORING EDITOR Mary O’Sullivan PROJECT EDITOR Ellen Keohane MARKETING MANAGER Margaret Barrett MARKETING ASSISTANT Elisa Wong SENIOR PRODUCT DESIGNER Lydia Cheng ASSOCIATE EDITOR Christina Volpe ASSOCIATE PRODUCTION MANAGER Joyce Poh PRODUCTION EDITOR Wanqian Ye INTERIOR DESIGN Kristine Carney COVER DESIGNER Wendy Lai This book was set in 10/12 Times Roman by Laserwords Private Limited. 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 ©2015, 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. – Fifth edition. pages cm Includes bibliographical references and index. ISBN 978-1-118-91101-3 (paperback) 1. Project management. 2. Information technology–Management. 3. Microsoft Project. 4. Project management–Computer programs. I. Title. HD69.P75M367 2015 004.068’4–dc23 2014031899 Printed in the United States of America 10 9 8 7 6 5 4 3 2 1  CONTENTS PREFACE xiii ABOUT THE AUTHOR xviii CHAPTER 1 The Nature of Information Technology Projects 1 Introduction 1 What Is a Project? 2 Project Attributes 2 What Is Project Management? 4 Projects, Programs, and Portfolios 4 Project Management and Information Technology 5 The State of IT Project Management 7 Why Many Projects Fail 8 Improving the Likelihood of Success 10 The Purpose of this Book 12 Chapter Summary 12 Review Questions 13 Husky Air—Pilot Angels 14 Husky Air Assignment 15 The Martial Arts Academy—School Management System 16 Quick Thinking—Involving the User 19 Quick Thinking—FAA Nextgen Air-Traffic Control Project 20 Case Studies 20 Bibliography 23 CHAPTER 2 Project Methodologies and Processes 24 Introduction 24 The Project Life Cycle 25 The Project Management Body of Knowledge (PMBOK® ) 27 Project Management Knowledge Areas 27 Project Processes 28 Project Management Process Groups 29 v vi CONTENTS PRINCE2® 31 PRINCE2® Processes 31 PRINCE2® Themes 32 PRINCE2® Principles 33 The Systems Development Life Cycle (SDLC) 34 The PLC and the SDLC 35 Implementing the SDLC 35 Waterfall 36 Agile Systems Development 38 What Is Agile? 38 Some Commonly Used Agile Methods 40 Waterfall versus Agile? 41 Learning Cycles and Lessons Learned 42 Chapter Summary 46 Review Questions 48 Husky Air—Pilot Angels Assignment 50 Martial Arts Academy (MAA) Assignment 51 Quick Thinking—Learning from Failure 53 Quick Thinking—Doing Agile or Being Agile? 54 Case Studies 55 Bibliography 58 CHAPTER 3 Measurable Organizational Value and the Business Case 59 Introduction 59 Measurable Organizational Value (MOV) 60 The MOV and Project Objectives 61 Developing the MOV 62 The Business Case 67 What Is a Business Case? 67 Developing the Business Case 68 Project Selection and Approval 76 The IT Project Selection Process 76 The Project Selection Decision 76 Chapter Summary 77 Review Questions 77 Husky Air Assignment—Pilot Angels 78 The Martial Arts Academy (MAA)—School Management System 80 Quick Thinking—Measuring the Immeasurable 83 Quick Thinking—The Elevator Pitch 83 Case Studies 84 Bibliography 89  CONTENTS vii CHAPTER 4 Project Planning: The Project Infrastructure 91 Introduction 91 Project Governance 92 The Project Team 94 The Project Manager 94 The Project Team 95 The Organization and Project Planning 96 The Functional Organization 96 The Project Organization 99 The Matrix Organization 100 Procuring External Project Resources 101 Procurement Planning 102 Contracts Between Sellers and Buyers 103 The Project Environment 105 The Project Charter 105 What Should Be in a Project Charter? 106 Project Identification 106 Project Stakeholders 107 Project Description 107 Measurable Organizational Value (MOV) 107 Project Scope 107 Project Schedule 107 Project Budget 108 Quality Standards 108 Resources 108 Assumptions and Risks 108 Project Administration 108 Acceptance and Approval 109 References 109 Terminology 109 Chapter Summary 110 Review Questions 111 Husky Air Assignment—Pilot Angels 112 The Martial Arts Academy (MAA)—School Management System 113 Quick Thinking—The Project Sponsor 114 Quick Thinking—Projects as Social Networks 114 Case Studies 115 Bibliography 119 viii CONTENTS CHAPTER 5 Project Planning: Scope and the Work Breakdown Structure 120 Introduction 120 The Triple Constraint 121 Defining and Managing Project Scope 122 Plan Scope Management 123 Collect Requirements 123 Define Scope 123 The Scope Boundary 123 The Statement of Work (SOW) 124 The Scope Statement 124 Project-Oriented Scope 125 Product-Oriented Scope 125 Validate Scope 128 Control Scope 128 Scope Change Control Procedures 129 The Work Breakdown Structure (WBS) 130 Work Packages 131 Deliverables and Milestones 131 Developing the WBS 132 Project Estimation 134 Guesstimating 134 Delphi Technique 134 Time Boxing 135 Top-Down Estimating 135 Bottom-Up Estimating 136 Poker Planning 136 Chapter Summary 138 Review Questions 139 Husky Air Assignment—Pilot Angels 140 The Martial Arts Academy (MAA)—School Management System 141 Quick Thinking—Sinking a Project 142 Quick Thinking—More People = More Problems 143 Quick Thinking—Politics and Estimates 143 Case Studies 144 Bibliography 147 CHAPTER 6 Project Planning: The Schedule and Budget 149 Introduction 149 Developing the Project Schedule 151  CONTENTS ix Gantt Charts 151 Project Network Diagrams 153 Critical Chain Project Management (CCPM) 157 Project Management Software Tools 159 Developing the Project Budget 161 The Baseline Plan 163 The Kick-Off Meeting 164 Chapter Summary 164 Review Questions 166 Husky Air Assignment—Pilot Angels 166 The Martial Arts Academy (MAA)—School Management System 167 Quick Thinking—Planning versus the Plan 168 Quick Thinking—The Map is Not the Territory 168 Case Studies 169 Bibliography 172 CHAPTER 7 Managing Project Risk 173 Introduction 173 Create a Risk Plan 176 Identify Risks 176 A Project Risk Identification Framework 176 Applying the Project Risk Identification Framework 178 Other Tools and Techniques 179 Analyze Risk 182 Qualitative Approaches 183 Quantitative Approaches 186 Discrete Probability Distributions 186 Continuous Probability Distributions 186 Develop Risk Strategies 191 Monitor and Control Risk 193 Respond and Evaluate Response to Risk 193 Chapter Summary 194 Review Questions 196 Husky Air Assignment—Pilot Angels 197 The Martial Arts Academy (MAA)—School Management System 197 Quick Thinking—Send in the Reserves 198 Quick Thinking—Risky Management 199 Case Studies 200 Bibliography 204 x CONTENTS CHAPTER 8 Managing Project Stakeholders and Communciation 205 Introduction 205 Stakeholder Analysis 206 The Informal Organization 206 Stakeholders 206 Stakeholder Analysis 206 Monitoring and Controlling the Project 207 The Project Communications Plan 209 Project Metrics 211 Burn-Down Chart 213 Earned Value 213 Analyzing Current Performance 216 Forecasting Project Performance 218 Reporting Performance and Progress 222 Information Distribution 222 Chapter Summary 223 Review Questions 224 Husky Air Assignment—Pilot Angels 225 The Martial Arts Academy (MAA)—School Management System 227 Quick Thinking—Projects as Social Networks 228 Quick Thinking—Communication and Mentoring 229 Case Studies 230 Bibliography 233 CHAPTER 9 Managing Project Quality 234 Introduction 234 Quality Philosophies 237 Craftsmanship 237 Scientific Management 238 The Total Quality Management (TQM) Gurus 238 Process Capability and Maturity 240 The Project Quality Management Plan 242 Quality Philosophies and Principles 242 Quality Standards, Processes, and Metrics 244 Quality Assurance 245 Quality Control 247 Continuous Improvement: Learn, Mature, and Improve 251 Chapter Summary 251 Review Questions 252 Husky Air Assignment—Pilot Angels 253 The Martial Arts Academy (MAA)—School Management System 253  CONTENTS xi Quick Thinking—Why Do We Accept Low-Quality Software? 254 Quick Thinking—OPM3® 254 Case Studies 255 Bibliography 259 CHAPTER 10 Leading the Project Team 260 Introduction 260 Project Leadership 261 Some Modern Approaches to Leadership 261 Leadership Styles 263 Emotional Intelligence 264 Ethics and Leadership 265 Ethical Leadership 266 Some Common Ethical Dilemmas in Projects 268 Making Sound Ethical Decisions 269 Teams and Leadership 270 Multicultural Projects 272 The Challenges of International Projects 272 Understanding Diversity 273 Chapter Summary 274 Review Questions 275 Husky Air—Pilot Angels 275 The Martial Arts Academy (MAA)—School Management System 276 Quick Thinking—Leadership and Listening 277 Quick Thinking—Sitting Ducks 277 Case Studies 278 Bibliography 281 CHAPTER 11 Managing Organizational Change, Resistance, and Conflict 282 Introduction 282 The Nature of Change 284 Change Has an Impact 284 Change Is a Process 285 Change Can Be Emotional 286 The Change Management Plan 287 Assess Willingness, Readiness, and Ability to Change 287 Develop or Adopt a Strategy for Change 289 Rational-Empirical Approach 289 Normative-Reeducation Approach 290 Power-Coercive Approach 290 Environmental-Adaptive Approach 291 xii CONTENTS Implement the Change Management Plan and Track Progress 291 Evaluate Experience and Develop Lessons Learned 292 Dealing with Resistance and Conflict 292 Resistance 292 Conflict 293 Chapter Summary 295 Review Questions 295 Husky Air Assignment—Pilot Angels 297 The Martial Arts Academy (MAA)—School Management System 298 Quick Thinking—It’s Not Easy Going Green 299 Quick Thinking—Cross-Functional and Multicultural Teams 299 Case Studies 300 Bibliography 305 CHAPTER 12 Project Completion 306 Introduction 306 Product Release or System Implementation 307 Direct Cutover 307 Parallel 308 Phased 308 Project Closure 310 Project Sponsor Acceptance 312 The Final Project Report 312 The Final Meeting and Presentation 313 Administrative Closure 313 Project Evaluation 314 Individual Performance Review 314 Project Close-Out (Postmortem) Review 315 Project Audit 316 Evaluating Project Success—The MOV 316 Chapter Summary 317 Review Questions 318 Husky Air Assignment—Pilot Angels 319 The Martial Arts Academy (MAA)—School Management System 319 Quick Thinking—Killing a Project 320 Quick Thinking—The Post-Implementation Audit 320 Case Studies 321 Bibliography 324 APPENDIX: An Introduction to Function Point Analysis (Available online at www.wiley.com/college/marchewka) INDEX 325  PREFACE Welcome to Information Technology Project Management—Providing Measurable Organizational Value (5th Edition). This book was written to help you learn the processes, tools, techniques, 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 sitting 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. Informa- tion systems—the products of IT projects—are planned organizational change. Information 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 challenging enough without being made more complex by obscure writing. As you will find out, 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 prerequisites, 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 imme- diately 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. xiii xiv PREFACE 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. Most students who read this book will never have been on a real 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 under- standing 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 projects should provide measurable value to organizations. The text provides an integrated approach to project management. It incorporates the ten areas out- lined in the Project Management Institute’s Project Management Body of Knowledge (PMBOK® ), as well as many of the themes and principles outlined in the PRINCE2® project methodology. The con- cepts associated with information systems management and software engineering when integrated with PMBOK® provide an important base of knowledge that builds a foundation for IT project manage- ment. 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 management is an area of growing interest and development. Knowledge management is a systematic process for acquiring, creating, synthesizing, sharing, and using information, insights, and experiences to create business value. Here, the concept of learning cycles provides a unique approach for defining and creat- ing 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 project methodology. Over time, the generic methodology may evolve and become a valuable asset to an organization as it becomes aligned with the organization’s culture and business. 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 a project. The text begins with an introduction to project management and why IT projects are organizational investments. Once a decision to approve and fund a 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 provides an introduction to what a project is and why projects must be viewed as organizational investments that must align with a chosen business strategy. In addition, this chapter discusses how the disciplines of information technology and project management have evolved together and have led to how we manage projects today.  CHAPTER OVERVIEWS xv ▪ Chapter 2: Project Methodologies and Processes introduces the concepts of lifecycles, methodologies, and processes for managing and developing the project’s product, service, or system. Overviews of the knowledge areas and processes associated with Project Management Body of Knowledge (PMBOK® ), as well as the core principles, processes, and themes of the PRINCE2® methodology are provided. This chapter also describes the waterfall method and two common Agile approaches for developing the project’s product or system. In addition, the concept of Learning Cycles is introduced and can be used throughout the end of chapter case assignments. ▪ Chapter 3: Measurable Organizational Value and the Business Case focuses on the processes, tools, and deliverables to conceptualize and start a project. Conceptualizing a project begins by developing a clear goal defined as the project’s measurable organizational value (MOV). The MOV provides a clear understanding of the project’s purpose and is the foundation for writing the business case. In addition to learning how to prepare a business case, students are provided with an understanding of how projects are often selected among other competing projects. ▪ Chapter 4: Project Planning: The Project Infrastructure focuses on defining the infrastructure required to support and plan the project. This includes governance of the project, selection of the project team, the acquisition of internal and external resources, and procurement contracts that are summarized in the next project deliverable called the project charter. ▪ Chapter 5: Project Planning: Scope and the Work Breakdown Structure describes the relation- ship among scope, schedule, and budget. It introduces a set of processes and tools for defining and managing the project and product deliverables. Students also learn how to develop a work breakdown structure (WBS) and several methods for estimating the work to be completed. ▪ Chapter 6: Project Planning: The Schedule and Budget introduces several project management tools, including Gantt charts, activity on the node (AON), critical path analysis, program evalu- ation 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 and the resources defined in the project infrastructure in order to develop the baseline project plan. In addition, the concept of critical chain project management (CCPM) is discussed. ▪ Chapter 7: Managing Project Risk describes the concept of risk management and introduces a framework for defining and understanding the integrative nature of risks associated with a project. Several qualitative and quantitative approaches and tools are introduced for analyzing and assessing risks so that appropriate risk strategies can be formulated. ▪ Chapter 8: Managing Project Stakeholders and Communication focuses on understanding the informal organization by developing a stakeholder analysis. This analysis provides the basis for creating a communication plan for reporting the project’s progress to various project stake- holders. This chapter also introduces the concept of earned value and several common project metrics to monitor and control the project. ▪ Chapter 9: Managing Project Quality describes planning for quality, quality assurance, and quality control in order to improve the project’s products and supporting processes continu- ously. This chapter also introduces several founders of the quality movement, as well as their philosophies that form an underlying basis for the project’s quality plan. In addition, the qual- ity management system called the capability maturity model and verification and validation activities are discussed. ▪ Chapter 10: Leading the Project Team focuses on project leadership and two important related components—ethics and development of the project team. This chapter also discusses some common ethical dilemmas that may be encountered on projects and a process is introduced 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. xvi PREFACE ▪ Chapter 11: Managing Organizational Change, Resistance, and Conflict describes the nature and impact of change associated with the delivery of a new product or 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 Completion focuses on three important areas necessary for project com- pletion: project implementation, closure, and evaluation ▪ Appendix: An Introduction to Function Point Analysis provides a more detailed discussion on counting function points and is provided online at www.wiley.com/college/marchewka. WHAT’S NEW IN THE FIFTH EDITION ▪ The new edition has been updated to reflect changes from the latest version of A Guide to the Project Management Body of Knowledge (PMBOK Guide), 2013. ▪ CHAPTER 2 PROJECT METHODOLOGIES AND PROCESSES was completely re-written. ▪ CHAPTER 8: MANAGING PROJECT STAKEHOLDERS AND COMMUNCIATION com- bines two chapters from the previous edition. ▪ The author has also added an overview of PRINCE2® Methodology. ▪ The discussion of an Agile approach to product/system development has been expanded. ▪ Integration of learning cycles has been added to end-of-chapter assignments. ▪ The discussion (including examples) of measurable organizational value (MOV) has been expanded. ▪ Content on project governance and its role in project management has been added to the text. ▪ CHAPTER 4: PROJECT PLANNING: THE PROJECT INFRASTRUCTURE now integrates procurement contracts. ▪ There is an expanded discussion on the relationship among scope, schedule, and budget—the triple constraint. ▪ A relatively new Agile estimation technique called Poker Planning has been added to the text. ▪ Content throughout the book has been streamlined and reorganized so that it is now 12 chapters instead of 14. ORGANIZATION AND SUPPORT Instructor Resources (go to www.wiley.com/college/marchewka) Instructor’s Manual This manual contains detailed solutions to questions in the textbook. Test Bank Test your students’ comprehension with this digital collection of true/false, multiple-choice, short answer, and essay questions. Lecture Presentation Slides These PowerPoint™ presentations contain a combination of key concepts allowing instructors to illustrate important topics with images and figures from the textbook.  ACKNOWLEDGMENTS xvii Husky Air Case Sample Solutions Solutions are provided to this integrated case study that provides students with the opportunity to work as a project team and apply the concepts presented in each chapter. Student Resources Microsoft Project Tutorials The author has provided a set of online-only Microsoft Project tutorials at www.wiley.com/go/ marchewka/msprojecttutorial. Using these tutorials, students can learn some basic skills that will help them create a work breakdown structure using Microsoft Project. Project Management Software Students can download a 60-day trial of Microsoft Project Professional 2013 from the following web- site: http://www.microsoft.com/en-us/evalcenter/evaluate-project-professional-2013. Note that Micro- soft has changed its policy and no longer offers the 120-day trial previously available. Another option now available to education institutions adopting this Wiley title is a free intro- ductory 3-year membership for DreamSpark Premium. DreamSpark Premium is designed to provide the easiest and most inexpensive way for academic departments to make the latest Microsoft soft- ware available in labs, classrooms, and on student’s and instructor’s PCs. Microsoft Project software is available through this Wiley and Microsoft publishing partnership, free of charge with the adop- tion of any qualified Wiley title. Each copy of Microsoft Project is the full version of the software, with no time limitation, and can be used indefinitely for educational purposes. Contact your Wiley sales representative for details. For more information about the DreamSpark Premium program, contact [email protected]. ACKNOWLEDGMENTS I would like to thank Beth Lang Golub, Ellen Keohane, Sangeetha Parthasarathy, and Mary O’Sullivan for all their help in writing this 5th edition. Also, I would like to thank the following reviewers for their valuable insight, comments, and suggestions. Rajeev Agrawal, North Carolina A&T State University David Bantz, University of Southern Maine Phyllis Chasser, Nova Southeastern University Barbara Cullis, University of Delaware Robert Fredericks, Drexel University Valarie Griep, University of Minnesota Mark Kwandrans, State University of New York at Buffalo Paul Licker, Oakland University Miriam Masullo, University of Maryland University College Toru Sakaguchi, Northern Kentucky University Jeanne Sawyer, San Jose State University Patricia Shamamy, Lawrence Technological University Gerhard Steinke, Seattle Pacific University Jeremy St. John, Texas A&M University Commerce  ABOUT THE AUTHOR J ack T. Marchewka is a professor of Management Information Systems at Northern Illinois Uni- versity. He received his Ph.D. from Georgia State University’s department of Computer Informa- tion 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 University in the Nether- lands 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 Management Associ- ation, where he has served as program chair, conference chair, and past president. Dr. Marchewka was also editor of the Communications of the 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. xviii 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 be able to: ▪ Understand why information technology (IT) projects are organizational investments. ▪ Understand why projects are planned organizational change and why they must align with an orga- nization’s business strategy. ▪ De!ne what a project is and describe the attributes of a project. ▪ De!ne the discipline called project management. ▪ Understand the relationship among project portfolios, programs, and projects. ▪ Understand how the disciplines of information technology and project management have evolved together and have led to how we manage projects today. ▪ Understand the current state of IT project management. ▪ Understand why some projects fail and how to improve the likelihood of success. INTRODUCTION Information technology (IT) projects are organizational investments. When an organization builds or implements a new IT-based product, service, or solution, it commits time, money, and resources to the project with an expectation of receiving something of value in return. Just as an investor considers the expected return and risk of a !nancial opportunity, an organization must weigh the expected costs, bene!ts, and risks of a project in order to make an effective business decision. It is up to the project manager and project team to deliver that value to the organization. Projects play an important role in organizations and can have a major impact. Business strategy supports the vision and mission of an organization’s current or desired markets, products, and services. While an organization must have an effective business strategy to be successful, projects are the planned organizational changes or means for achieving a chosen strategy. More speci!cally, IT projects enable the integration of technology in new products, services, or processes that can change existing relationships between an organization and its customers or suppliers, as well as among the people within the organization. An IT-based product, service, or solution can be a technical success if it functions properly, but it can also be an organizational failure if it fails to meet the needs and expectations of the customer, client, or user group. 1 2 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS WHAT IS A PROJECT? The Project Management Institute (PMI) is an organization that was founded in 1969 and has grown to become the leading nonpro!t professional association in the area of project management. In addition, PMI establishes many project management standards and provides seminars, educational programs, and professional certi!cations that are recognized globally. It also maintains the Guide to the Project Management Body of Knowledge (PMBOK© Guide) that provides commonly used de!nitions for a project and a project manager (1). A project is a temporary endeavor undertaken to create a unique product, service, or result. (p. 3) A project manager is the person assigned by the performing organization to lead the team that is responsible for achieving the project objectives. (p. 16) Project Attributes Projects can be large or small, short or long in duration, or relatively cheap or expensive; however, all projects share some common attributes. ▪ Time Frame—Because a project is a temporary endeavor, it must have a de!nite beginning and end. Some projects must begin on a speci!c date, and the date of its completion must be estimated. On the other hand, some projects have an immovable date that de!nes when the project must be completed. In this case, it becomes necessary to work backwards to deter- mine a date when the project should start. Regardless, a project ends when all the promised work is completed and the organization’s expectations are met, or it can be terminated prema- turely when the work or expectations cannot be met. While a project is temporary, the product, service, or system created by the project can have either a brief or lasting impact. ▪ Purpose—Projects are undertaken to accomplish something. A project must also create some- thing unique. This could be a new product, service, system, or an enhancement to an existing product, service, or system. For IT projects, this could include engineering or building a custom solution or integrating and implementing an existing third party’s product or system. Regard- less, a project must have a clear goal that de!nes the value of the project to the organization. This is important for setting expectations, de!ning the work to be done, setting direction for the project team, and developing a schedule and budget. A clear (and measurable) project goal can be used after the project is completed to evaluate its overall success. ▪ Ownership—A project can have many stakeholders that include people, groups, or other organi- zations that have a vested interest in the project’s success or failure. In many cases, the product, service, or system will be developed for stakeholders other than those involved directly with the project team. Projects undertaken within an organization support internal customers such as a high-level manager, often called a sponsor, a business unit, or a group of users, while external projects developed by third parties such as consultants or other IT-service providers support external customers, often called clients. At the completion of most projects, ownership of the product, service, or system is transferred from the project team to the customer, client, or user group. ▪ Resources—All projects require resources. Resources include time, money, people, facilities, and technology. Although resources provide a means for achieving the project’s goal and com- pleting the work, they can be a constraint as most organizational resources are limited. Sub- sequently, project resources must be managed and controlled to ensure a project achieves its anticipated organizational value to its internal or external customers.  WHAT IS A PROJECT? 3 ▪ Project Roles—All projects require people with skill sets that include both technical and nontechnical (soft) skills. The technical skills required will be determined largely by the product, service, or system that is to be built or implemented. On the other hand, nontechnical or soft skills can be just as important to the success of the project. These skills focus more on interpersonal skills such as the ability to communicate not only with fellow team members, but also with users, customers, or the client. Based on the project and skills required, a project may include the following roles: ▪ Project Manager or Leader—The project manager or team leader is responsible for ensur- ing that all the project management processes and processes associated with the creation of the product, service, or system are in place and carried out ef!ciently and effectively. ▪ Project Sponsor—The project sponsor may be the client, customer, or high-level exec- utive who plays the role of champion for the project by providing resources, making project-related decisions, giving direction, and publicly supporting the project when needed. ▪ Subject Matter Experts (SME)—A subject matter expert may be a user or a person who has speci!c knowledge, expertise, or insight in a speci!c functional area needed to support the project. For example, if the organization wishes to develop a system to support tax decisions, having a tax expert either as part of the project team or available to the team to share his or her expertise can be more productive than having the technical people trying to learn tax accounting. ▪ Technical Experts (TE)—Technical expertise is needed when engineering or building a product, service, or system. Technical experts may include database analysts, network spe- cialists, engineers, programmers, graphic artists, and so forth. ▪ Risks and Assumptions—All projects include an element of risk, and some projects entail more risk than others. Risk can arise from many sources, both internal and external to the project. For example, internal risks may arise from the way the project work is estimated to cost or the time to be completed. Another internal risk could be a key member of the project team leaving in the middle of the project to take another job. External risks, on the other hand, could arise from dependencies on other contractors, project teams, or suppliers. Assumptions are different forms of risk that are introduced to the project as a result of forecasts or predictions. They are what we use to estimate schedule and budget. For example, a project manager may need to hire a programmer. While estimating the project’s budget, the project manager may make an assumption that this programmer’s salary will be $75,000 a year. If this assumption is too low and the programmer is hired for more than $75,000 a year, then the project’s budget will be higher than what the project manager estimated and the project may run the risk of being over budget. ▪ Interdependent Tasks—The work to deliver a product, service, or system requires many inter- dependent tasks or activities. For example, a network cannot be installed until a server and other hardware is delivered, or important requirements cannot be incorporated into the design of a product or an application (app) unless a key customer or user is interviewed. Often the delay of one task can affect other subsequent, dependent tasks. As a result, the project’s schedule may slip, and the project will not meet its planned deadline. In addition, projects can be characterized by progressive elaboration whereby the details of a project become clearer as more informa- tion becomes available. For example, the features and functionality of a new smartphone app may be de!ned at a high or an abstract level early on in the project but become de!ned in much greater detail later on as the project team and user/customer work more closely together during the design phase. ▪ Organizational Change—New products, services, or systems are planned organizational change. Change must be understood and managed because a project can alter how people 4 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS work or how they related to one another. Because not everyone likes or is in favor of change, the potential for resistance and conflict exists. This is where a new IT-based product or solution could end up being a technical success but an organizational failure. Subsequently, the potential value of the project may not be fully realized. ▪ Organizational Environment—Projects operate in an environment larger than the project itself. Organizations choose or select projects for a number of reasons, and the projects chosen can impact the organization (1). It is especially important for the project manager and team to understand the organization’s culture, environment, politics, and structure. These organizational variables influence the selection, funding, and support of a project. The project team must understand the organizational variables and the political climate within the orga- nization so that potential issues that could impede the project can be recognized and handled appropriately. WHAT IS PROJECT MANAGEMENT? A project is undertaken to create something new or unique, as well as to enhance an existing product, service, or system. The Guide to the Project Management Body of Knowledge (PMBOK© Guide) de!nes project management as (1). Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. (p. 5) Projects, Programs, and Portfolios Organizations often fund more than one project at any given time. Some projects may be in the beginning stages, while others are somewhere in the middle or close to completion. Similar to the idea of a !nancial investment portfolio, organizations should have a project portfolio comprised of a collection of diverse projects. Just as a wise investor should not invest too heavily in any given !nancial instrument like a particular stock or fund, organizations should seek to balance their project portfolio with respect to risk, experience, and technology so that the project portfolio is balanced (2). In short, an organization may not want to take on too many large, risky projects. On the other hand, an organization may not want to have a portfolio of low-risk projects using soon-to-be obsolete technologies that cater only to a single business unit. A portfolio of projects should be managed collectively so as to align with the organization’s strategy and overall plan to achieve competitive advantage. Some projects within the portfolio may be independent and not directly related to one another. Conversely, some projects are managed as a program where the projects’ activities are coordinated so that the bene!ts of the program are greater than the sum bene!ts of the individual projects (1). Therefore, projects that are part of a program have a common outcome or capability. While a project may not be part of a program, a program will include more than one project. For example, an organization may approve a project to move its existing data center to a new building. On its own, this could be an individual project. However, if the project to move the data center is part of a strategic plan to integrate a new supply chain system and customer support system, then a single project that includes moving the data center and development of two systems may be too risky. Instead of planning and managing the data center move, supply chain system, and customer support system as one large project, it may be wiser and saner to coordinate this collectively as a program of three interdependent projects. Each project would have its own project manager, team, budget, schedule, and so forth with a shared governance structure in place for resolving issues and conflicts and to ensure that each project aligns with the overall success of the program (1).  WHAT IS PROJECT MANAGEMENT? 5 Project Management and Information Technology Modern-day project management is often credited to the U.S. Navy’s Polaris missile project undertaken in the early 1950s to deter potential Soviet nuclear aggression. The Polaris project was strategically important, complex, and risky, so the Navy needed to ensure it was managed well from concept through deployment. This new approach included a set of tools to manage projects and was viewed by many as a success. As a result, other organizations in various industries began to adopt this new approach as way to de!ne, manage, and execute work with the hope of achieving similar success. Today, project management is viewed as a discipline that addresses a wide variety of organizational opportunities and challenges. However, the !eld of project management has in many ways evolved in parallel with the !eld of information technology. According to Richard Nolan, the use of the computer in business from 1960 to 2000 has gone through a series of three dominant eras: the electronic data processing (EDP) era, the micro era, and the network era (3). The EDP era began in the early 1960s and was characterized by the purchase of the !rst centralized mainframe or a minicomputer by large organizations. The IT projects during this era focused generally on automating various organizational transactions such as general accounting tasks, inventory manage- ment, 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 a !nancial manager. The goal of using technology was to improve ef!ciency and reduce costs by automating many of the manual or clerical tasks performed by people. The use of computer technology was 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 ef!cient. Subsequently, IT projects during this era were generally structured, so a structured, formalized approach similar to the one used on the Polaris project was effective. Because the requirements of a business process such as payroll were fairly stable, changing the requirements was not a major issue and large multiyear projects were common. Unfortunately, in many cases these legacy systems created information silos, as projects supported speci!c 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 begin- ning 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 management information system (MIS) man- agers. For example, the !rst 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 central- ized 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 a new position called the chief information of!cer (CIO) to expand the role of IT within the organization. While the DP manager often reported to the head accounting or !nancial manager, the CIO often reported to the chief executive of!cer (CEO). Therefore, IT increas- ingly 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 (4) 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 through- out 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 6 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS 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 univer- sity 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 creat- ing an IT infrastructure to support many business partners, strategic alliances, vendors, and customers. This started a digital convergence or the integration of data, voice, graphics, and video that allowed for innovative ways to deliver new products and services to customers worldwide. While micro-era projects tended to focus on an organization’s internal network, the network era extended 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. The IT project team needed to under- stand new and evolving technologies as well as the organization and its competitive environment. As witnessed by the rise and fall of many dot com businesses in the late 1990s, the bene!ts and risks of managing IT projects were much higher than in the !rst two eras. Project schedules and the time to develop IT solutions had to be shortened as many projects had to be completed in a few weeks or a few months. However, the combination of a global network infrastructure and lowering of political barriers in the late 1990s and early 2000s led to a rise of globalization. Countries like India and China became connected to North America and Europe. According to Thomas L. Friedman, the world has become flatter so that it is possible for people and organizations to work with almost anyone in any place and at any time (5). Many organizations outsourced and offshored business processes, projects, and even entire business units. As a result of globalization, projects began to cross time zones as well as organi- zational and cultural boundaries. Instead of working and meeting at the same time and place, a virtual team with project members working in different places and time zones became common. Instead of relying on stable requirements, new project management approaches and development methodologies acknowledged that many product and system requirements cannot be de!ned upfront and, once de!ned, often change. Today, IT projects support a wide range of organizational activities that range from maintaining existing (legacy) systems to developing innovative ideas that take advantage of emerging technolo- gies like 3-D printing or cloud and mobile computing. IT projects can be relatively straightforward like upgrading a network or developing a simple web site, while large, expensive, and risky enterprise applications like ERP (enterprise resource planning) and CRM (customer relationship management) can support core business processes and activities throughout the organization. Moreover, social media and big data analytics are increasingly rede!ning the customer relationship and enhancing the customer experience. A number of companies hope that alternative reality or how people use technology in their everyday lives will become integrated into consumer products such as smartphones, smart watches, and smart glasses. 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, more geographically dispersed, and more ethnically or culturally diverse than ever before. The risk and rewards will be greater than in the past. Therefore, a solid set of technical, nontechnical, and project management skills founded upon past experience and adapted to this new, dynamic environment will be needed to successfully manage IT projects. In both economic good times and bad times, senior management will make a certain level of fund- ing available for IT projects. The budgeted amount will depend on such things as the overall !nancial strength of the organization, the economy, the competitors’ actions within the industry, and the organi- zation’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 !xed. 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  THE STATE OF IT PROJECT MANAGEMENT 7 budget is tight. Projects that do not receive any funding will either have to wait or fall by the wayside. Therefore, the decision to fund a speci!c 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 dif!cult 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 a new product, service, or system that provides little or no value to the organization, or failing to roll out or implement a new product, service, or 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 an indirect interest in the project’s success loses. 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. There is no shortage of stories in the trade magazines about failed IT projects. Very often, these failures end up in lawsuits that cost people and organizations vast amounts of money, as well as damaged careers and estranged relationships (6). Some recent examples of IT project failures include the cancelation of an ERP project that cost the U.S. Air Force more than $1 billion. The project was called the Expeditionary Combat Support System and was envisioned to replace more than 200 legacy systems. Although the project started in 2005, it was scrapped in 2012 after spiraling costs and the inability to create “any signi!cant military capability.” Only about 25 percent of the original features and functionality were developed, and an additional $1.1 billion would be needed to complete the project by 2020 (6). In 2008, the beverage distributor Major Brands decided to replace a number of its 20-year-old application systems with a software package developed and sold by Epicor. According to the lawsuit, a contract was signed in September 2009 whereby Major Brands paid $500,000 to Epicor for software licenses and support with about $670,000 for implementation. Although Epicor assured Major Brands that its software system would be a good !t and that it would be up and running by the middle of 2011, issues associated with training, installation, and performance arose very early in the project. Major Brands spent an additional $100,000 to upgrade its servers, but the application system continued to perform well below acceptable performance targets. Epicor informed Major Brands that it would need to make major changes and upgrades to the existing software that would extend the project’s schedule signi!cantly. Although the suit was settled in April 2012, the terms of settlement were not disclosed (6). Many people heard about the problems associated with the Healthcare.gov web site that was sched- uled to launch October 1, 2013 to help many Americans purchase health insurance as part of the Affordable Care Act. While the project was in planning and development for three years after the initial law was passed, only about 30 percent of the users were able to sign up for health care (7). After a frenzied “tech surge” to !x the “glitches,” the system was still experiencing problems by the end of December 2013. Although the contractor for the web site was initially awarded $93 million for the project, the !nal cost is estimated between $300 million and $500 million (8). Unfortunately, the stories behind these three examples are nothing new. The truth is that the overall success rate for many large governmental and nongovernmental projects throughout the world is low (9). In fact, a great deal of research suggests that IT projects have and will continue to fail and experience challenges. In 1995, the Standish Group drew attention to what many called the software crisis when it pub- lished a survey of 365 IT managers conducted in 1994. The study was called CHAOS and reported that only 16 percent of the application development projects were successful in terms of being com- pleted on time and within budget. Moreover, about 31 percent of the projects were canceled before 8 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS completion, while 53 percent were completed but over budget, over schedule, and did not meet original speci!cations. 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 suggested 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 !ve or ten years earlier (10). The original CHAOS study has been updated every two years and provides a valuable and inter- esting long-term, global study of IT project success and failure. The latest study in 2013 reports that 39 percent of the IT projects were classi!ed as successful, while 43 percent were classi!ed as challenged, and 18 percent as failed (11). Project success is de!ned as a project being completed on time, within budget, and including all of the features or requirements envisioned. A challenged project is de!ned as a project that is late, over budget, and having fewer features and functionality than envisioned, while a failed project is a project that was canceled before completion. A poor success rate has been supported by other studies. For example, a 2007 study of 800 senior IT managers from the United Kingdom, United States, France, Germany, India, Japan, and Singapore conducted by Tata Consultancy Services reports dire results similar to the CHAOS Studies (12): ▪ 62 percent of the IT projects failed to meet their schedules ▪ 49 percent experienced budget overruns ▪ 47 percent experienced higher than expected maintenance costs ▪ 41 percent failed to deliver the expected business value and return on investment (ROI) In addition, a 2012 study by McKinsey reports that, on average, a large IT project runs 45 percent over budget, 7 percent over the scheduled deadline, and delivers 56 percent less value than expected. Even more dire, is the statistic that 17 percent of IT projects perform so poorly that they threaten the very existence of the organization (13). Why Many Projects Fail One reason for the reported high failure rates in the various studies may be how “success” and “failure” are de!ned. For example, Robert Glass (14) asks, How should a project be classi!ed if it is “functionally brilliant” but is over budget and over schedule by 10 percent? According to the CHAOS de!nition, this would be considered a failure, while in reality, it could be a success for the organization. However, no matter what value a project is envisioned to bring to an organization, a project that continues to surpass its budget and schedule will eventually exceed any potential or real value it can pass on to the organization. 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. The number of reasons why projects fail is pretty much unlimited. Generally, a project does not fail because of one single reason, but because of a whole host of problems, issues, and challenges that build upon one another. However, as illustrated in Figure 1.1, most reasons for project failure can be grouped into four categories: people, processes, technology, and organizational. ▪ People—People are the stakeholders of a project, and stakeholders can have varied roles and interest in the project’s success or failure. The support of top management or a high-level execu- tive consistently ranks as one of the most important criteria for project success (1). The support of upper management is critical in terms of acquiring and maintaining !nancial backing for the project. Visible support by senior management is also important in terms of emotional support  THE STATE OF IT PROJECT MANAGEMENT 9 People Processes Technology Organization ∙ Lack of Top ∙ Poorly De!ned ∙ Obsolete ∙ Lack of Direction Management Goals & ∙ Unproven ∙ Changing Support Objectives ∙ Incompatible Priorities ∙ Ineffective User ∙ Poor Planning ∙ Lack of Funding Involvement ∙ Lack of Controls ∙ Competition for ∙ Lack of Skills ∙ Poorly De!ned Funding ∙ Lack of Requirements ∙ Organizational Experience ∙ Changing Politics ∙ Poor Requirements ∙ Bureaucracy Communication ∙ Inadequate ∙ Lack of Oversight ∙ Poorly De!ned Testing ∙ Poor Change Roles and ∙ Project Management Responsibilities Management & ∙ Lack of Product Accountability Development ∙ Unrealistic Processes Expectations Nonexistent or ∙ Conflicting Not Followed Stakeholder Goals ∙ Poor Execution ∙ Poor Decisions Figure 1.1 Examples of Why Projects Fail and negotiation or resolution of organizational conflicts. Users can be thought of as the project’s customer. Users are important project stakeholders that should be involved in important deci- sions 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. Ineffective user involvement can lead to missed opportunities, unrealistic expectations, or a lack of buy-in. Other people-related issues that contribute to project failure include poor communication, as well as not having the right people on the project team with respect to skills, experience, or decision-making ability. Often conflicts arise if stakeholders have competing goals or interests or if roles, responsibili- ties, and accountability are not well-de!ned. ▪ Processes—This includes having a set of project management and product development pro- cesses. Project management processes de!ne the project’s goal and objectives and help to develop and carry out a realistic project plan. Product processes focus on the new product, pro- cess, or system to be designed, built, tested, and implemented. Processes that are not de!ned or followed can lead to poor quality in terms of a solution not providing the expected value or not meeting schedule, budget, or quality objectives. Often, requirements that are not properly de!ned lead to additional work or a product, process, or system that stakeholders did not ask for or do not need. In short, the project is poorly executed. ▪ Technology—Only 3 percent of IT project failures can be attributed to technical challenges (15). However, projects run the risk of failure if a technology is obsolete, unproven, or incompatible with developing the project’s product, process, or system. Choosing the right technology means having the right tool for the job and that the product, process, or system is not hindered by a technology that is not scalable, integrative, maintainable, or supported in the future. ▪ Organization—Organizational issues can lead to project failure as well. A lack of clear direc- tion in terms of strategy can allow an organization to fund the wrong project or overlook a potential winner. In a dynamic environment, changing requirements in terms of laws, the com- petition, or customer demands may create a moving target for the project’s product, service, or system as the organization’s priorities change. Funding can impact a project if business 10 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS units within the organization compete for limited funds or if the organization suffers a !nancial downturn. Management can create its own problems because of a lack of oversight or through a bureaucracy of overly complex and unwavering rules and policies. Moreover, not having an organizational plan to prepare the stakeholders for the project’s planned organizational change can lead to missed deadlines due to conflicts and resistance from stakeholders. 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 text. ▪ A Value-Driven Approach—Plain and simple: IT projects must provide value to the organi- zation. Many people and organizations de!ne project success in terms of the project being completed on time and within budget. While schedule and budget are important, they are not suf!cient de!nitions of project success. For example, if an organization sets a mandate that a particular 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 unsuccessful 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 !nishing 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 speci!cally, 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 ef!cient 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 devel- opment. 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 sup- port 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 longer be content with de!ning 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 studies has been the need for better project management. But, isn’t building an information system a project? Haven’t organizations 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 de!ned for the entire project. As a result, project success does not depend  THE STATE OF IT PROJECT MANAGEMENT 11 primarily on the team, but more on the set of mature, capable 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 cap- ital 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 divert resources away from other projects and areas of the organization. Eventually, these uncontrolled costs could impact the !nancial stability of the organization. ▪ Expectations—Today, organizational clients expect IT professionals to deliver quality prod- ucts and services in a professional manner. Timely status updates and communication, 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 ser- vices 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, de!ned 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 guarantee 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 to 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 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 she or he did? What the outcome was? And, would that person 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 avail- able through applications accessible today, such blogs, wikis, and shared repositories like Microsoft’s SharePoint©. Lessons learned that document 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 ef!cient and effective manner. In terms of managing 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 thing and then to do it the right way. 12 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS THE PURPOSE OF THIS BOOK The goal of this book is to help you learn how to plan and manage information technology projects. We will focus on a number of different theories and concepts, but the main emphasis will be on applying the methods, tools, techniques, and processes for planning and managing a project from start to !nish. If you are a project manager (or will be one soon), this book will help you to understand and apply project man- agement principles in order to better manage your IT project. If you are just starting out in the !eld, this book will help you to understand the big picture of what a 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 dif- ferent from other types of projects and how the principles and methods of system development can be integrated to de!ne the IT project management discipline. Although many of the concepts for develop- ing an information system will be integrated throughout, this is not a systems analysis and design text. More speci!cally, 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 processes, methods, and tools. We begin by understanding the nature of IT projects and then will 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 certi!cation in project management, it will provide a solid base to help you in your career and later on should you choose to become a certi!ed project manager. CHAPTER SUMMARY ⦁ Information technology (IT) projects are orga- ⦁ Project Manager or Leader nizational investments. When an organization ⦁ Project Sponsor builds or implements a new IT-based product, ⦁ Subject Matter Expert(s) (SME) service, or solution, it commits time, money, and resources to the project with an expectation of ⦁ Technical Expert(s) (TE) receiving something of value in return. ⦁ Risks and Assumptions ⦁ Organizations must have an effective business ⦁ Interdependent Tasks strategy to be successful, and projects are the ⦁ Organizational Change planned organizational changes or means for ⦁ Organizational Environment achieving a chosen strategy. ⦁ Project management is the application of knowl- ⦁ A project is a temporary endeavor undertaken to edge, skills, tools, and techniques to project create a unique product, service, or result. activities to meet project requirements. ⦁ A project manager is the person assigned by the ⦁ Similar to the idea of a !nancial investment port- performing organization to lead the team that is folio, many organizations have a project portfo- responsible for achieving the project objectives. lio comprised of a collection of diverse projects. ⦁ All projects share some common attributes: ⦁ Some projects within the portfolio may be inde- ⦁ Time Frame pendent and not directly related to one another. ⦁ Purpose However, some projects are managed as a pro- ⦁ Ownership gram where the projects’ activities are coordi- nated so that the bene!ts of the program are ⦁ Resources greater than the sum bene!ts of the individual ⦁ Project Roles projects.  REVIEW QUESTIONS 13 ⦁ Modern-day project management is often cred- 1995. IT projects focused primarily on the chal- ited to the U.S. Navy’s Polaris missile project lenge of creating an IT infrastructure to support undertaken in the early 1950s to deter potential many business partners, strategic alliances, ven- Soviet nuclear aggression. This new approach dors, and customers. Project schedules and the included a set of tools to manage projects and time to develop IT solutions had to be shortened was viewed by many as a success. As a result, as many projects had to be completed in a few other organizations in various industries began weeks or a few months. to adopt this new approach as way to de!ne, ⦁ The combination of a global network infras- manage, and execute work with the hope of tructure and lowering of political barriers in achieving similar success. the late 1990s and early 2000s led to a rise ⦁ The EDP era began in the early 1960s and was of globalization as countries like India and characterized by the purchase of the !rst central- China became connected to North America and ized mainframe or a minicomputer by large orga- Europe. Projects began to cross time zones as nizations. The IT projects du