ABOUT THE AUTHOR xxi
| CHAPTER 1 The Nature of Information Technology Projects 1
Global Technology Solutions 1
How This Book Is Organized 3
The Software Crisis 4
Why IT Projects Fail 4
Improving the Likelihood of Success 6
A Socio-Technical Approach 6
A Project-Management Approach 7
A Knowledge-Management Approach 8 The
Context of Project Management 9
What Is a Project? 9
Attributes of a Project 9 The Project Life
Cycle and IT Development
Define Project Goal 12
Plan Project 13
Execute Project Plan 13
Close Project 14
Evaluate Project 14
The IT Product Life Cycle 14
Maintenance and Support 15
Putting the SDLC into Practice 16
vi INFORMATION TECHNOLOGY PROJECT MANAGEMENT
Structured Approach to Systems Development 16 Rapid Applications
Development (RAD) 16 The PLC versus the SDLC 18 The Project
Management Body of Knowledge (PMBOK) 19
Project Management Knowledge Areas 19
Chapter Summary 21 Review Questions 21 Extend
Tour Knowledge 22 Bibliography 22
CHAPTER 2 Conceptualizing and Initializing the IT Project 23
Global Technology Solutions 23
An Information Technology Project Methodology (ITPM) 25
Phase 1: Conceptualize and Initialize 27
Phase 2: Develop the Project Charter and
Detailed Project Plan 28
Phase 3: Execute and Control the Project 29
Phase 4: Close Project 29
Phase 5: Evaluate Project Success 30
IT Project Management Foundation 30
Project Management Processes 31
Project Objectives 31
Project Management Knowledge Areas 32 The
Business Case 32
What Is a Business Case? 32
Developing the Business Case 33
Step 1: Select the Core Team 33
Step 2. Define Measurable Organizational Value (MOV) 34
Step 3: Identify Alternatives 40
Step 4: Define Feasibility and Assess Risk 41
Step 5: Define Total Cost of Ownership 42
Step 6: Define Total Benefits of Ownership 42
Step 7: Analyze Alternatives 43
Step 8: Propose and Support the Recommendation 47
Project Selection and Approval 48
The IT Project Selection Process 49
The Project Selection Decision 49
Chapter Summary 52 Review
Questions 53 Extend Tour
Knowledge 54 Bibliography
| CHAPTER 3 Developing the Project Charter and Baseline Project Plan 55
Global Technology Solutions 55
Project Management Processes 57
Project Management Process Groups
Closing 60 Project Integration
Project Plan Development 61
Project Plan Execution 62
Overall Change Control 62
The Project Charter 63
What Should Be in a Project Charter?
Project Identification 65
Project Stakeholders 65
Project Description 65
Measurable Organizational Value (MOV)
Project Scope 65
Project Schedule 66
Project Budget 66
Quality Issues 66
Assumptions and Risks
Acceptance and Approval
Terminology 67 Project
The MOV 69
Define the Project's Scope
Subdivide the Project into Phases 70
Tasks—Sequence, Resources, and Time Estimates 70
Viii INFORMATION TECHNOLOGY PROJECT MANAGEMENT
Schedule and Budget—The Baseline Plan 71
The Kick-Off Meeting 71 Chapter Summary 72
Review Questions 72 Extend Tour Knowledge 73
CHAPTER 4 The Human Side of Project Management 74
Global Technology Solutions 74
Organization and Project Planning 76
The Formal Organization 77
The Functional Organization 77
The Project Organization 81
The Matrix Organization 82
Which Organizational Structure Is Best"? 84
The Informal Organization 85
Stakeholder Analysis 85
The Project Team 86
The Roles of the Project Manager 86
Team Selection and Acquisition 88
Team Performance 88
Work Groups 89
Real Teams 89
Project Teams and Knowledge Management 91
Learning Cycles and Lessons Learned 92 The
Project Environment 96 Chapter Summary 97
Review Questions 98 Extend Tour Knowledge 99
CHAPTER 5 Defining and Managing Project Scope
Global Technology Solutions 101
Project Scope Management Processes 102
Project Scope Initiation 104
Project Scope Planning 105
Scope Boundary 105 The Scope
Statement 105 Scope Statement
105 Out of Scope for this Project 106
Project Scope Definition 107
Project-Oriented Scope 107
Project-Oriented Scope Definition Tools 107
Product-Oriented Scope 109
Product-Oriented Scope Definition Tools 109
Project Scope Verification 111
Scope Change Control 113
Scope Change Control Procedures 114
Benefits of Scope Control 117
Chapter Summary 117
Review Questions 117
Extend Tour Knowledge 119
CHAPTER 6 The Work Breakdown Structure and Project Estimation 120
Global Technology Solutions 120
The Work Breakdown Structure (WBS) 123
Work Packages 123
Deliverables and Milestones 124
Developing the WBS 125
The WBS Should Be Deliverable-Oriented 126
The WBS Should Support the Project's MOV 126
The Level of Detail Should Support Planning and Control 127
Developing the WBS Should Involve the People Who Will Be Doing the Work 128
Learning Cycles and Lessons Learned Can Support the
Development of a WBS 128
Project Estimation 128
Guesstimating 128 Delphi
Technique 129 Time Boxing
129 Top-Down Estimating
129 Bottom-Up Estimating
X INFORMATION TECHNOLOGY PROJECT MANAGEMENT
Software Engineering Metrics and Approaches 131
Lines of Code (LOG) 133
Function Points 133
Automated Estimating Tools 140 What Is the Best
Way to Estimate IT Projects? 140 Chapter Summary
141 Web Sites to Visit 142 Review Questions 142 Extend
Tour Knowledge 143 Bibliography 144
CHAPTER 7 The Project Schedule and Budget 146
Global Technology Solutions 146
Developing the Project Schedule 149
Gantt Charts 150
Project Network Diagrams 150
Activity on the Node (AON) 151
Critical Path Analysis 152
Precedence Diagramming Method (PDM) 154
Project Management Software Tools 156
Developing the Project Budget 158
Cost Estimation 159
Other Costs 161
Resource Allocation 163
Finalizing the Project Schedule and Budget 163
Chapter Summary 164 Review Questions 165 Extend Tour
Knowledge 165 Bibliography 165
CHAPTER 8 Managing Project Risk 166
Global Technology Solutions
IT Project Risk Management Planning Process
Risk Planning 171
Risk Identification 171
Risk Assessment 172
Risk Strategies 172
Risk Monitoring and Control 173
Risk Response 173
Risk Evaluation 173 Identifying IT
Project Risks 173
An IT Project Risk Management Framework 174
Applying the IT Project Risk Management Framework 175
Tools and Techniques 177 Risk
Analysis and Assessment 179
Qualitative Approaches 179
Expected Value 180
Decision Trees 180
Risk Impact Table 181
Quantitative Approaches 183
Discrete Probability Distributions 183
Continuous Probability Distributions 184
Simulations 187 Risk Strategies 190
Risk Monitoring and Control 192 Risk
Response and Evaluation 193 Chapter
Summary 194 Web Sites to Visit 195 Review
Questions 195 Extend Tour Knowledge 196
| CHAPTER 9 Project Communication, Tracking, and Reporting
Global Technology Solutions 197
Monitoring and Controlling the Project 200
The Project Communications Plan 202
Project Metrics 203 Earned Value 205
Reporting Performance and Progress 209
Information Distribution 210 Chapter Summary
213 Review Questions 215
Xii INFORMATION TECHNOLOGY PROJECT MANAGEMENT
Extend Tour Knowledge 216
CHAPTER 10 IT Project Quality Management 217
Global Technology Solutions 217
The Quality Movement 223
The Industrial Revolution 224
Frederic W. Taylor (1856-1915) 224
Walter A. Shewhart (1891-1967) 225
W. Edwards Deming (1900-1993) 227
Joseph Juran (1904- ) 228
Kaoru Ishikawa (1915- ) 229
Phillip Crosby (1926-2001) 231
Quality Systems 231
International Organization for Standardization (ISO) 231
Six Sigma (6cr) 234
The Capability Maturity Model (CMM) 236
Level 1: Initial 237
Level 2: Repeatable 238
Level 3: Defined 239
Level 4: Managed 239
Level 5: Optimizing 240 The IT
Project Quality Plan 241
Quality Philosophies and Principles 241
Focus on Customer Satisfaction 242
Prevention not Inspection 242
Improve the Process to Improve the Product 243
Quality Is Everyone's Responsibility 243
Fact-Eased Management 243
Quality Standards and Metrics 243
Verification and Validation 245
Change Control and Configuration Management 247
Component Identification 248
Version Control 248
Configuration Building 248
Change Control 249
Monitor and Control 249 Learn,
Mature, and Improve 249
Chapter Summary 250 Web Sites
to Visit 252 Review Questions
252 Extend Tour Knowledge 253
CHAPTER 11 Managing Organizational Change, Resistance,
and Conflict 256
Global Technology Solutions 256
The Nature of Change 260
The Impact of Change 260 Change as a
Process 262 Emotional Responses to
Change 263 The Change Management
Assess Willingness, Readiness, and Ability to Change 264
Change Agents 265
Develop or Adopt a Strategy for Change 266
Rational-Empirical Approach 267
Normative-Reeducation Approach 267
Power-Coercive Approach 268
Environmental-Adaptive Approach 269
Implement the Change Management Plan and Track Progress 270
Evaluate Experience and Develop Lessons Learned 270
Dealing with Resistance and Conflict 270
Polarity Management 274
Chapter Summary 277 Review
Questions 278 Extend Tour
Knowledge 279 Bibliography 280
| CHAPTER 12 Project Implementation, Closure, and Evaluation 281
Global Technology Solutions 281
XIV INFORMATION TECHNOLOGY PROJECT MANAGEMENT
Project Implementation 283
Direct Cutover 284 Parallel
285 Phased 285
Administrative Closure 287
Project Sponsor Acceptance 289
The Final Project Report 290
The Final Meeting and Presentation 291
Closing the Project 291
Project Evaluation 292
Individual Performance Review 292
Postmortem Review 293
Project Audit 294
Evaluating Project Success—The MOV 295
Chapter Summary 296 Review Questions 297
Extend Tour Knowledge 297 298
APPENDIX A: An Introduction to Function Point Analysis 301
Welcome to Information Technology Project Management—Providing Measurable
Organizational Value. This book was written to help people understand 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, long time. In fact, it
was around before the great pyramids of Egypt were created. Today, project manage-
ment has emerged as its own field, supported by a body of knowledge and research
across many disciplines. 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 contin-
ually 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 information systems. 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. Information systems—the products of IT projects—are planned organiza-
tional change. Information technology is an enabler for new products, services, and
processes that can change existing relationships between an organization and its cus-
tomers 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 information system, regardless of how well it was built or
how up-to-date the technology, tools, and techniques. 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 bal-
anced in order to deliver a successful project.
But what is a successful project? Many people and authors define project success in
terms of the project being completed on time and within budget. I will not argue that
completing a project by its intended deadline and within its allocated resources is not
important. I will, however, argue that on time and on-budget are important, but not nec-
essarily sufficient conditions for project success. For example, would a project that was
expected to be completed within six months and cost no more than $1 million be con-
sidered unsuccessful if the project required an extra day or an extra dollar to complete?
XVI INFORMATION TECHNOLOGY PROJECT MANAGEMENT
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 the project early and
under-budget 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 required? More specifically, what value will the organization receive by
spending six months and $ 1 million on this particular project? Therefore, an organi-
zation expects to receive some kind of organizational value from the implemented
system when it makes an IT investment.
As you will see throughout this text, a project's measurable organizational value,
or MOV, defines a project's value to the organization and becomes the project's meas-
ure of success. Moreover, a project's MOV also provides a foundation for integrating
project management and IT concepts, tools, and techniques, as well as for various
decisions that are made from the project's conceptualization to its closure.
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 prac-
tical 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 prob-
lem with many textbooks was that they were written by professors for other profes-
sors. That statement stuck with me over the years. When I 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 informa-
tion systems or programming under your belt. You should find that the concepts of IT
project management will compliment 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 incorpo-
rates the nine areas outlined in the Project Management Institute's Project
Management Body of Knowledge (PMBOK). The concepts associated with informa-
tion systems management and software engineering when integrated with PMBOK
provide an important base of knowledge that builds a foundation for IT project man-
agement. 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 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 organ-
ization 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.
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 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 project's 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 describes the
software crisis and the context of IT project management. This 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
• 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: Developing the Project Charter and Baseline Project Plan
introduces project integration management and a project planning frame
work to support the development of the project plan.
XV111 INFORMATION TECHNOLOGY PROJECT MANAGEMENT
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 Scope introduces and describes
the project management knowledge area called project scope management.
The project's scope defines what the project team will and will not deliver to
the project sponsor or client. Scope management processes also ensure that
the project's 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 will be introduced, as will several software engineering
techniques and metrics for software estimation.
Chapter 7: The Project Schedule and Budget introduces several project man-
agement tools, including Gantt charts, activity on the node (AON), critical
path analysis, program evaluation and review technique (PERT), and prece-
dence diagramming, that can be used to develop the project schedule. A project
budget can then be developed based upon the activities defined in the WBS,
the project schedule, and the cost of the resources assigned or required.
Chapter 8: Managing Project Risk describes the concept of risk management
and introduces a framework for defining and understanding the inte-grative
nature of risks associated with an IT project. Several qualitative and
quantitative approaches and tools will be 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 a system of project metrics to monitor and
control the project.
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 will also be discussed. These include
the International Standards Organization (ISO), TickIT, 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 orga-
nizational change theories will be 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 Implementation, Closure, and Evaluation describes the
tactical approaches for installing and delivering the project's product—the
information system. In addition, the processes for bringing closure to the project
and evaluating the project team and the project's MOV are discussed.
Appendix A: An Introduction to Function Point Analysis provides a more
detailed discussion on counting function points than is provided in Chapter 6.
ORGANIZATION AND SUPPORT
The beginning of each chapter includes an opening vignette or story that describes a
particular situation faced by a project manager and team undertaking an IT project.
This scenario will set the stage for the concepts and tools introduced in the chapter
and make the learning of the material more meaningful. From a student's perspective,
this will attempt to answer the "so what?" and "why do I have to know this?" questions
that should be addressed.
For many chapters there is a Web-based practicum that includes a set of inte-
grated hands-on case assignments. The case assignments allow the student to play the
role of a project team member who has been hired by a newly formed consulting firm.
The Web site provides all the background for the company. The cases lead the student
through the various stages of planning an IT project for a client. They include several
deliverables such as the project charter, project plan, scope management plan, risk
plan, and implementation plan, and they require the student to apply the concepts and
techniques covered in the book.
More specifically, each case assignment will include both a hands-on and a crit-
ical thinking component. For example, the hands-on component of the case assign-
ment may ask students to develop a project plan using Microsoft Project. However,
the student would then be asked to answer questions about how specific concepts dis-
cussed in the book relate to the hands-on component. The hands-on component allows
students to develop a particular skill, while the critical thinking component allows
them to reflect upon how their actions may affect the project in different ways.
The supporting Web site for the Web-based project management community will
host a discussion or chat area that allows students, instructors, project management
experts, and even the author to discuss and share ideas from around the world.
In addition, the Web site will host various student support materials. For example,
it links to various IT and project management-related Web sites and articles to support
the material included in the text. A trial version of Microsoft Project 2002 has also been
included with the text.
An instructor's manual, test bank, and presentation slides are available. A section of
the Web site has been partitioned just for instructors to support the sharing of teaching
ideas and experiences.
I would like to thank my editor Beth Lang Golub, Lorraina Raccuia, and Jennifer
Battista of John Wiley & Sons, and Lari Bishop and Shoshanna Turek of Leyh
Publishing for all of their hard work. I would also thank all of the reviewers for their
insightful and helpful comments.
XX INFORMATION TECHNOLOGY PROJECT MANAGEMENT
Patricia A. McQuaid California Polytechnic State University
John M. Kohlmeier DePaul University
Dennis Adams University of Houston
Anthony R. Hendrickson Iowa State University
Chelley Vician Michigan Technological University
Rajiv Sabherwal University of Missouri-St. Louis
Mark Nissen Naval Postgraduate School
Gurpreet S. Dhillon University of Nevada, Las Vegas
Bel G. Raggad Pace University
Dale Perrin, Ph.D. University of Phoenix
Laurie J. Kirsch University of Pittsburgh
Dr. Laura L. Hall University of Texas at El Paso
Ann Banks Pidduck University of Waterloo
The Nature of Information
Chapter 1 provides an overview of information technology project management
(ITPM). After studying this chapter, you should understand and be able to:
• Describe the software crisis and how the often dismal track record for informa
tion technology (IT) projects provides a motivation for changing how we view
and manage IT projects.
• Explain the socio-technical, project management, and knowledge management
approaches that support ITPM.
Define what an IT 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 the project life cycle, the systems development life cycle, and their
Identify the Project Management Body of Knowledge (PMBOK) and its core
GLOBAL TECHNOLOGY SOLUTIONS
Tim Williams placed the phone gently back in its cradle. He sat for a moment, not sure
whether he felt excitement or sheer terror. Or, could it be he was feeling both? Kellie
Matthews, his partner in Global Technology Solutions (GTS), had just told Tim that
Husky Air, a business air charter company, was very interested in having them
develop an information system. This was the moment Tim had been waiting for—
2 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS
their first client! Before Husky Air will sign a contract, however, they need to know
what GTS will deliver, how much it will cost, and when the project will be completed.
As the project's manager, Tim knows that getting this contract is important.
Husky Air would be the company's first and, so far, only client. Tim also understands
that a successful project could lead to other work with Husky Air. Moreover, a verbal
or written recommendation would provide additional credibility to help GTS get its
foot in the door with other potential clients.
While working together in the information services department at a large com-
pany, Tim and Kellie decided that a small, independent consulting firm could be suc-
cessful developing smaller IT-based systems. The lure of being their own bosses and
the potential for financial and personal rewards were too great to resist. Tim and
Kellie cashed in their stock options, and GTS was born. They decided that Kellie
would develop new business and manage the day-to-day operations of GTS, while
Tim would deliver and manage the projects. New employees with specific skill sets
would be hired as needed to support particular projects.
Although both Tim and Kellie had worked in IT for several years, neither of them
had ever managed a consulting project before. Aside from the questions posed by
Husky Air (What will you deliver? How much will it cost? How long will it take?),
Tim felt a bit overwhelmed because he knew the success or failure of this project
would have an immediate impact on the viability of the new firm.
Things to Think About:
1. If you were in Tim's shoes, what feelings do you think you would experi
2. What questions would you have?
3. What might help reduce your anxiety and uncertainty as an inexperienced
4. Where do you begin a new project?
The new millennium provides a vantage point from which to look back at our past and
ahead to our future. Many people at the end of the century emptied their bank
accounts, stockpiled food and water, and even went so far as to head for the hills for
fear that computers would crash and civilization would fall into mass confusion.
Fortunately, the reported Y2K computer-related problems were few and not especially
critical. Was the problem hyped? Not really. Was there really a problem? Yes! Many
companies spent millions of dollars to change and test the dates in their computer sys-
tems so the passing of January 1, 2000 would have no effect. Just ask one of the many
IT professionals who worked hard and long on a Y2K project. You may even know, or
be, one of those people.
What made the Y2K problem fascinating was that just about everyone was in this
together and the project had an immovable deadline. As a result, the field of information
technology received a great deal of attention in the media and the boardroom. Even
though it was shortsightedness that created the problem, the few reported Y2K prob-
lems prompted some to believe this was the IT profession's shining hour. Moreover, the
risks and costs associated with the Y2K problem captured the attention of senior man-
agement. As a result, people at different levels, including senior management, and in
different functional areas became more involved with and interested in information
technology. The good news is that the world of IT moved from the back office to the
boardroom. The bad news is that IT may be doomed to repeat past mistakes.
After Y2K, it appeared that companies now had the time and money to start on
their IT projects that had been on hold. Electronic commerce and the integration of
enterprise resource planning (ERP) packages were at the top of the IT project list for
many organizations. The demand for skilled IT professionals and project managers
to head up these new initiatives had never been stronger. It seemed as though
recruiters couldn't hire experienced professionals and university graduates fast
enough to meet the demand.
Unfortunately, this golden time for IT did not last. The tragic events of September
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 professionals and new graduates who once commanded high salaries and
choice assignments found themselves facing a tough job market. The bubble had
burst. If nothing else, we learned that things can change quickly and without warning.
As you read this, think about what is going on in the field of IT right now. Is the
demand for IT professionals and IT projects strong? Or, are there fewer jobs and proj-
ects available? If the demand for IT projects and professionals to work on these projects
is strong, many organizations will probably have to choose from among projects that
have been sitting on the backburner for some time. On the other hand, if time, money,
and resources for many organizations are limited, then only a few, select IT projects
can be funded.
In both good times and bad, senior management will make a certain level of funding
available for IT projects. The budgeted amount will depend upon such things as the
economy, competitor's 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 requirements for the 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 busi-
ness units 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 wayside.
Therefore, the decision to fund specific projects will always be an important manage-
ment 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 implementing an information system that could have
provided value to the organization, but was developed or managed poorly? It is prob-
ably moot. In either situation everyone with a direct or indirect interest in the project's
How This Book Is Organized
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 focus will be on
4 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS
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 knowl-edge
will help you to become a better team member and prepare you for the next sev-eral
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
dis-cuss what makes IT projects different from other types of projects and how the
prin-ciples and methods of system development can be integrated to define the IT
project management discipline. Although many of the concepts for developing an
informa-tion 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 chapter provides a foundation for project initiation by
pro-viding an understanding of the nature of information technology projects. Before
get-ting too involved with definitions and concepts, however, it is important to
understand the motivation behind IT project management. In the next section we will
focus on the software crisis, which for many people has become a call to arms for more
effective management of IT projects. Then, we will introduce and define projects and
project management. Subsequently, we will look at the relationship between the
project life cycle and the systems development life cycle. At the end of the chapter, you
will be introduced to the nine areas that make up the Project Management Body of
Knowledge (PMBOK) that will be integrated throughout the remaining chapters of
THE SOFTWARE CRISIS
Although IT is becoming more reliable, faster, and less expensive, the costs, complex-
ities, and risks of IT projects continue to increase. In 1995, a consulting firm called
The Standish Group conducted a survey of 365 IT managers. The widely cited report,
appropriately called CHAOS, was startling.
For example, although the United States spent over $250 billion each year on IT
application development projects, 31 percent of these projects were canceled before
completion. Almost 53 percent were completed, but they were over-budget and
over-schedule and did not meet the original specifications. The average cost overrun
for a medium-size company surveyed was 182 percent of the original estimate, while
the average schedule overrun was 202 percent. That is, the results of the survey,
summarized in Table 1.1, suggest that a medium-sized project originally estimated to
cost about $1 million and to take a year to develop, actually cost $1,820,000, tookjust
over two years to complete, and only included 65 percent of the envisioned features
and functions! Sadly, 48 percent of the IT managers surveyed believed there were
more failures at the time than five and ten years earlier.
Why IT Projects Fail
The CHAOS report also provides some interesting insight as to why some projects
succeed while others fail. According to the survey, user involvement, executive
THE SOFTWARE CRISIS
Table 1.1 Summary of the CHAOS Study Results
Cost of Average Average and
Company Develop- Cost Schedule Functions Successful Challenged Impaired
Size ment Overruns Overrun Included Projects a
Large $2,322,000 178% 230% 42% 9% 61.5% 29.5%
Medium $1,331,000 182% 202% 65% 16.2% 46.7% 37.1%
Small $ 434,000 214% 239% 74% 28% 50.4% 21.6%
Completed on-time and on-budget
Completed, but over-budget, over schedule, and includes fewer features and functions than originally
Cancelled before completion
SOURCE: Adapted from The Standish Group, CHAOS (West Yarmouth, MA: 1995), http://www.standishgroup
management support, and a clear statement of requirements ranked at the top of the
list of factors essential for IT project success. On the other hand, lack of user
involvement and incomplete requirements appear to be the two main factors for
projects being challenged or canceled before completion.
Tables 1.1 and 1.2 summarize some of the key findings of the CHAOS report.
First, larger projects report a success rate of only 9 percent and appear to be much more
risky than medium and smaller projects. Technology, business models, and cycle times
are changing too quickly to develop systems that take much more than a year to com-
plete. This data also supports the need to break up large projects into smaller, more
manageable ones that can be completed in less than a year. Companies such as Sears,
Roebuck and Co., for example, have new, stricter IT project deadlines that require all
web-based projects be completed within three months (Hoffman and King 2000).
In addition, one can look at the project factors for successful and not-so-successful
projects to see what may be happening on those projects. User involvement leads the
list as the most important factor in project success. This should come as no surprise
since the client's expertise is needed to identify problems and opportunities and to
define requirements. Moreover, active participation by the client keeps them interested
in and excited about the project. Individuals will also begin to take ownership of a
project if they feel that they have a stake in the project's success or failure. Effective
communication between the techies and non-techies allows for a clearer definition of
the project's goals and requirements. Working together, developers and users have
more realistic expectations because they themselves set those expectations together.
Management is then more compelled to support a popular project.
On the other hand, lack of user input or involvement ranks at or near the top in
factors affecting challenged and impaired projects. One can almost picture the chain of
events. Without close support of the key users, the project team will have a difficult
time understanding the goals of the project and defining the requirements. As a result,
suspicion and hostility may arise, and there can easily be an "us versus them" situation.
Without effective communication and a clear direction, changes to the project's
requirements always seem to appear, and both groups may set unrealistic expectations.
Chaos sets in. Management begins to find fewer reasons to support an
6 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS
Improving the Likelihood of Success
How can we improve the chances for IT project success and avoid repeating past mis-
takes? Here are three approaches that will be focal points throughout this book.
A Socio-Technicnl 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
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.
THE SOFTWARE CRISIS
TAXPAYERS PAY $50 BILLION A YEAR FOR IRS MISTAKES
A Computerworld investigation reports that delays in
overhauling the federal tax system have cost the U.S.
government approximately $50 billion a year in
uncol-lected taxes. Although the Internal Revenue Service
(IRS) had spent hundreds of millions of dollars in an
attempt to modernize its computer systems, critics claim
that much of that money has been wasted because of
mismanagement and primitive development practices.
Government and private groups believe that there are
several reasons for the problems:
• Failure to redesign the business processes before
beginning systems development
• No overall systems architecture or development plan
• Primitive and sometimes "chaotic" software devel
• Failure to manage information systems as invest
• Lack of information security
Both Congress and the General Accounting Office have
directed the IRS to carry out the following recommendations:
• Put in place a rigorous process for selecting, priori
tizing, controlling, and evaluating major information
• Improve system development practices from ad hoc
to ones that can be repeated and improve the likeli
hood of success
• Develop organization-wide plans that focus on an
integrated systems architecture, security, data archi
tecture, and configuration management
SOURCE: Adapted from Gary H. Anthes, "IRS Project Failures Cost
Taxpayers $50B Annually," Computerworld, October 14, 1996,
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 proj-
ect? Haven't organizations used project management in the past? And aren't they
using project management now? While many organizations have applied the princi-
ples 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 pri-
marily 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, meth
ods, and controls in place, the project will drain or divert resources away
from other projects and areas of the organization. Eventually, these uncon
trolled 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 sta
tus updates and communication, as well as sound project management prac
tices, 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
8 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS
Many people find it easier to avoid failure than accept it.
Yet, failure can be helpful and, at times, even desirable.
Failure can be a valuable experience because one can learn
more from failure than from success since the benefits of
taking risks often outweigh the consequences of failure. In
addition, Harold Kerzner makes three points about failure:
1. A company is not taking enough business risks if its
projects are 100 percent successful.
2. Terminating a project early can be viewed as suc
cessful if the resources originally dedicated to the
project can be reassigned to more profitable activities
or the technology needed for the project does not
exist or cannot be invented cost-effectively within a
reasonable time period.
3. Excellence in project management requires a con-
tinuous stream of successfully managed projects.
But you can still have project failures.
SOURCE: Adapted from Alan S. Horowitz, "The Sweet Smell of
Failure," Computer-world, http://www.computerworld.com/home
/online9676.nsf/all/980209; Harold Kerzner, In Search of Excellence
in Project Management: Successful Practices in High Performance
Organizations (New York: John Wiley, 1998).
cost of providing IT services can be bettered outside the organization. Today,
competition among consultants is increasing as they compete for business and
• 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 guarantee success. Project man-
agement 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 commit-
ment 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 relatively new area. It is a
systematic process for acquiring, creating, synthesizing, sharing, and using informa-
tion, 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
THE CONTEXT OF PROJECT MANAGEMENT 9
that document both reasons for success and failure can be valuable assets if main-
tained 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 wis-
dom that you can become truly successful (Standish Group 1995, 4).
| THE CONTEXT OF PROJECT MANAGEMENT
What Is a Project?
Although the need for effectively managing projects has been introduced, we still
require a working 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 non-profit professional association in the area of project manage-
ment. In addition, PMI establishes many project management 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 2000) provides widely used definitions for
project and project management.
A project is a temporary endeavor undertaken to accomplish a
unique purpose (4).
Project management is the application of knowledge, skills, tools,
and techniques to project activities in order to meet or exceed stake-
holder needs and expectations from a project (6).
Attributes of a Project Projects can also be viewed in terms of their attributes:
time frame, purpose, ownership, resources, roles, risks and assumptions, interde-
pendent tasks, organizational change, and operating in an environment larger than
the project itself.
Time Frame Because a project is a temporary endeavor, it must have a definite
beginning and end. Many projects begin on a specific date and the date of completion is
estimated. Some projects, on the other hand, have an immovable date when the
project must be completed. In this case, it is necessary to work backwards to deter-
mine the date when the project must start. Keep in mind that your career should not
consist of a single project, but a number of projects.
Purpose Projects are undertaken to accomplish something. An IT project can
produce any number of results—a system, a software package, or a recommendation
10 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS
based on a study. Therefore, a project's goal must be to produce something tangible
and of value to the organization. A project must have a goal to drive the project in
terms of defining the work to be done, its schedule, and its budget, and to provide the
project team with a clear direction.
Because it sets expectations that will directly influence the client's level of satisfac-
tion, the project's goal must be clearly defined and agreed upon. The definition for project
management suggests that project activities must meet or exceed stakeholder needs and
expectations. Expectations and needs, however, cannot be met if the project's goal is not
achieved. It is, therefore, important to keep in mind that a project should only be
undertaken to provide some kind of value to the organization. Moreover, a specific and
measurable project goal can be evaluated after the project is completed.
Ownership The project must provide something of value to an individual or
group who will own the project's product after it is completed. Determining who
owns this product is not always easy. For example, different groups may fight over
who does or does not own the system, the data, the support, and the final cost of
imp/ementi'ng and maintaining the system. Although a project may have many stake-
holders (i.e., people or groups wfio nave a vested interest in the project's outcome), a
project should have a clearly defined sponsor. The sponsor may be the end user,
C(f$t6(ftef, or the client who (tag the abttity and desire to provide direction, funding,
and other resources to the project.
Resources IT projects require time, money, people, and technology.
Resources provide the means for achieving a project's goal and also act as a con-
straint. For example, the project's scope, or work to be accomplished, is deter-
mined directly by the project's goal—that is, if we know what we have to
accomplish, we can then figure out how to accomplish it. If the project sponsor
asks that an additional feature be added to the system, however, this request will
undoubtedly require additional resources in terms of more work on the part of the
project team. The use of a project resource has an associated cost that must be
included in the overall cost of the project.
In the past, computer technology was relatively
more expensive than the labor needed to develop a system. Today, the
labor to build a system is relatively more expensive than the
technology. As IT salaries increase, the cost of IT projects will become
even more expensive. Therefore, if team members must do additional
work, their time and the costs associated with time spent doing
unscheduled work must be added to the project's schedule and budget.
In other words, if scope increases, the schedule and budget of
a project must increase accordingly. If the project's schedule
and resources are fixed, then the only way to decrease the cost
or schedule of the project may be to reduce the project's scope.
Scope, schedule, and budget must remain in a sort of
equilibrium to support a particular project goal. This
relationship, sometimes referred to as the triple constraint, is
illustrated in Figure 1.1. It should be a consideration whenever
making a decision that affects the project's goal, scope,
schedule, or budget.
Figure 1.1 The Scope, Schedule, and Budget
Relationship—the Triple Constraint
THE CONTEXT OF PROJECT MANAGEMENT 11
Roles Today, IT projects require different individuals with different skill sets.
Although these skills may be different on different projects, a typical project may
include the following:
• Project Manager—The project manager is the team leader and is responsi
ble for ensuring that all of the project management and technical develop
ment processes are in place and are being carried out within a set of
specific requirements, defined processes, and quality standards.
• Project Sponsor—The project sponsor may be the client, customer, or orga
nizational manager who will act as a champion for the project and provide
organizational resources and direction when needed.
• Subject Matter Expert(s) (SME)—The subject matter expert may be a user
or client who has specific knowledge, expertise, or insight in a specific
functional area needed to support the project. For example, if the organiza
tion wishes to develop a system to support tax decisions, having a tax
expert on the project team who can share his/her knowledge will be more
productive than having the technical people try to learn everything about
tax accounting while developing the system.
• Technical Expert(s) (TE)—Technical expertise is needed to provide a tech
nical solution to an organizational problem. Technical experts can include
systems analysts, network specialists, programmers, graphic artists, train
ers, and so forth. Regardless of their job title, these individuals are respon
sible for defining, creating, and implementing the technical and
organizational infrastructure to support the product of the IT project.
Risks and Assumptions All projects have 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 team. For example, internal risks may arise from the estima-
tion process or from the fact that a key member of the project team could leave in the
middle of the project. External risks, on the other hand, could arise from dependencies
on other contractors or vendors. Assumptions are what we use to estimate scope,
schedule, and budget and to assess the risks of the project. There are many unknown
variables associated with projects, and it is important to identify and make explicit all
of the risks and assumptions that can impact the IT project.
Interdependent Tasks Project work requires many interdependent tasks. For
example, a network cannot be installed until the hardware is delivered, or certain
requirements cannot be incorporated into the design until a key user is interviewed.
Sometimes the delay of one task can affect other subsequent, dependent tasks. The
project's schedule may slip, and the project may not meet its planned deadline.
Organizational Change Projects are planned organizational change. Change
must be understood and managed because implementation of the IT project will
change the way people work. The potential for resistance, therefore, exists, and a sys-
tem that is a technical success could end up being an organizational failure.
Operating in an Environment Larger than the Project Itself Organizations
choose projects for a number of reasons, and the projects chosen can impact the
organization (Laudon and Laudon 1996). It is important that the project manager
and team understand the company's culture, environment, politics, and the like.
12 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS
These organizational variables will influence the selection of projects, the IT
infrastructure, and the role of IT within the organization. For example, a small,
family-owned manufacturing company may have a completely different corporate
culture, strategy, and structure than a start-up electronic commerce company. As a
result, the projects selected, the technical infrastructure, and the role of IT for each
organization will be different. The project team must understand both the technical
and organizational variables so that the project can be aligned properly with the
structure and strategy of the organization. Moreover, understanding the orga-
nizational variables can help the project team understand the political climate
within the organization and identify potential risks and issues that could impede
THE PROJECT LIFE CYCLE AND IT DEVELOPMENT
The project life cycle (PLC) is a collection of logical stages or phases that maps the
life of a project from its beginning to its end in order to define, build, and deliver the
product of a project—that is, the information system. Each phase should provide one
or more deliverables. A deliverable is a tangible and verifiable product of work (i.e.,
project plan, design specifications, delivered system, etc.). Deliverables at the end of
each phase also provide tangible benefits throughout the project and serve to define
the work and resources needed for each phase.
Projects should be broken up into phases to make the project more manageable
and to reduce risk. Phase exits, stage gates, or kill points are the phase-end review of
key deliverables that allow the organization to evaluate the project's performance and
to take immediate action to correct any errors or problems. Although the deliverables at
the end of a stage or phase usually are approved before proceeding to the next stage,
fast tracking or starting the next phase before approval is obtained can sometimes
reduce the project's schedule. Overlapping of phases can be risky and should only be
done when the risk is deemed acceptable.
Like all living things, projects have life cycles where they are born, grow, peak,
decline, and then terminate (Gido and Clements 1999; Meredith and Mantel 2000).
Although project life cycles may differ depending upon the industry or project, all
project life cycles will have a beginning, a middle, and an end (Rosenau 1998; Gido
and Clements 1999). Figure 1.2 provides a generic life cycle that describes the com-
mon phases or stages shared by most projects.
Define Project Goal
Defining the project's overall goal should be the first step of the project. This goal
should focus on providing business value to the organization. A well-defined goal
gives the project team a clear focus and drives the other phases of the project. In addi-
tion, most projects seem to share the following characteristics:
• The effort, in terms of cost and staffing levels, is low at the start of the
project, but then increases as the project work is being done, and then
decreases at the end as the project is completed.
• Risk and uncertainty are the highest at the start of a project. Once the goal
of the project is defined and the project progresses, the probability of suc
cess should increase.
THE PROJECT LIFE CYCLE AND IT DEVELOPMENT 13
Execute Project Plan
Once the project's goal has been defined, developing the project plan is a much easier
task. A project plan essentially answers the following questions:
• What are we going to do?
• Why are we going to do it?
• How are we going to do it?
• Who is going to be involved?
• How long will it take?
• How much will it cost?
• What can go wrong and what can we do about it?
• How did we estimate the schedule and budget?
• Why did we make certain decisions?
• How will we know if we are successful?
In addition, the deliverables, tasks, resources, and time to complete each task must be
defined for each phase of the project. This initial plan, called a baseline plan, defines
the agreed upon scope, schedule, and budget and is used as a tool to gauge the project's
performance throughout the life cycle.
After the project's goal and plan have been defined, it's time to put the plan into action.
As work on the project progresses, scope, schedule, budget, and people must be actively
managed to ensure that the project achieves its goal. The project's progress must be doc-
umented and compared to the project's baseline plan. In addition, project performance
must be communicated to all of the project's stakeholders. At the end of this phase, the
project team implements or delivers a completed product to the organization.
14 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS
As was mentioned, a project should have a definite beginning and end. The closing
phase of a project ensures that all of the work is completed as planned and as agreed to
by the project team and the sponsor. Therefore, there should be some kind of formal
acknowledgement by the sponsor that they will accept (and pay for!) the product deliv-
ered. This closure is often capped with a final project report and presentation to the
client that documents that all promised deliverables have been completed as specified.
Sometimes the value of an IT project is not readily known when the system is imple-
mented. For example, the goal of a project to develop an electronic commerce site
should be to make money—not to build or install hardware, software, and web pages
on a particular server platform. The technology and its subsequent implementation are
only a means to an end. Therefore, the goal of the electronic commerce site may be to
produce $250,000 within six months. As a result, evaluating whether the project met
its goal can be made only after the system has been implemented.
However, the project can be evaluated in other ways as well. The project team
should document its experiences in terms of lessons learned—those things that it
would do the same and those things it would do differently on the next project, based on
its current project experiences. This post mortem should be documented, stored
electronically, and shared throughout the organization. Subsequently, many of these
experiences can be translated into best practices and integrated into future projects.
In addition, both the project team and the project itself should be evaluated at the
end of the project. The project manager may evaluate each project team member's per-
formance in order to provide feedback and as part of the organization's established merit
and pay raise processes and procedures. Often, however, an outside third party, such as a
senior manager or partner, may audit the project to determine whether the project was
well-managed, provided the promised deliverables, followed established processes, and
met specific quality standards. The project team and project manager may also be eval-
uated in terms of whether they acted in a professional and ethical manner.
The IT Product Life Cycle
Although projects follow a project life cycle, information systems development fol-
lows a product life cycle. The most common product life cycle in IT is the Systems
Development Life Cycle (SDLC), which represents the sequential phases or stages
an information system follows throughout its useful life. The SDLC establishes a log-
ical order or sequence in which the system development activities occur and indicates
whether to proceed from one system development activity to the next (McConnell
1996). Although there is no generally accepted version of the SDLC, the life cycle
depicted in Figure 1.3 includes the generally accepted activities and phases associated
with systems development. Keep in mind that these concepts are generally covered in
great detail in system analysis and design books and courses. For some, this may be a
quick review, while for others it will provide a general background for understanding
how IT project management and information system development activities support
Planning, analysis, design, implementation, and maintenance and support are the
five basic phases in the systems development life cycle.
THE PROJECT LIFE CYCLE AND IT DEVELOPMENT 15
Planning The planning stage involves identifying and responding to a problem or
opportunity and incorporates the project management and system development
processes and activities. Here a formal planning process ensures that the goal, scope,
budget, schedule, technology, and system development processes, methods, and tools
are in place.
Analysis The analysis phase attempts to delve into the problem or opportunity
more fully. For example, the project team may document the current system to
develop an "as is" model to understand the system currently in place. In general, sys-
tems analysts will meet with various stakeholders (users, managers, customers, etc.)
to learn more about the problem or opportunity. This work is done to identify and doc-
ument any problems or bottlenecks associated with the current system. Generally, the
"as is" analysis is followed by a requirements analysis. Here the specific needs and
requirements for the new system are identified and documented. Requirements can be
developed through a number of means—interviewing, joint applications development
(JAD), conducting surveys, observing work processes, and reading company reports.
Using process-oriented, data-oriented, and/or object-oriented modeling techniques,
the current system, user requirements, and logical design of the future system called
the "to be" system are represented and documented (Dennis and Haley 2000).
Design During the design phase, the project team uses the requirements and "to be"
logical models as input for designing the architecture to support the new information
system. This architecture includes designing the network, hardware configuration,
databases, user interface, and application programs.
Implementation Implementation includes the development or construction of the
system, testing, and installation. In addition, training, support, and documentation
must be in place.
Maintenance and Support Although maintenance and support may not be a true
phase of the current project, it is still an important consideration. Once the system has
been implemented, it is said to be in production. Changes to the system, in the form of
maintenance and enhancements, are often requested to fix any discovered errors (i.e.,
bugs) within the system, to add any features that were not incorporated into the original
design, or to adjust to a changing business environment. Support, in terms of a call
center or help desk, may also be in place to help users on an as-needed basis.
Eventually, the system becomes part of the organizational infrastructure and
becomes known as a legacy system. At this point, the system becomes very similar to a
car. Let's say you buy a brand new car. Over time, the car becomes less and less new,
and parts have to be replaced as they wear out. Although, a system does not wear out
like a car, changes to the system are required as the organization changes. For
16 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS
example, a payroll system may have to be changed to reflect changes in the tax laws, or
an electronic commerce site may have to be changed to reflect a new line of products
that the company wishes to introduce. As the owner of an older or classic car, you may
find yourself replacing part after part until you make the decision to trade in the old
junker for something newer and more reliable. Similarly, an organization may find itself
spending more and more on maintaining a legacy system. Eventually, the organization
will decide that it is time to replace this older system with a newer one that will be
more reliable, require less maintenance, and better meets its needs. Subsequently, a
new life cycle begins.
Putting the SDLC into Practice
There are basically two ways to implement the SDLC. Today, an IT project will follow
either a structured approach or a newer approach called Rapid Applications
Structured Approach to Systems Development A structured approach to systems
development has been around since the 1960s and 1970s when large mainframe appli-
cations were developed. These applications were built when (1) systems were rela-
tively simple and independent from each other, (2) computer hardware was relatively
more expensive than the labor, and (3) development and programming tools were
primitive compared to today (Satzinger, Jackson, Burd 2002).
The Waterfall method in Figure 1.4 follows the SDLC in a very sequential and
structured way. Planning overhead is minimized because it is all done up-front and a
tangible system is not produced until the end of the life cycle (McConnell 1996). The
idea of a waterfall is a metaphor for a cascading of activities from one phase to the
next. This approach stresses a sequential and logical flow of development activities.
For example, the design activities begin only after the analysis and requirement activ-
ities are complete. Subsequently, the actual development, or programming activities,
will not start until the design phase is complete. Although one can go back to a pre-
vious stage, it is not always easy or desirable.
This approach is suitable when developing structured systems and assumes, or at
least hopes, that the requirements defined in the analysis stage do not change very
much over the remainder of the project. In addition, because it will provide a solid
structure that can minimize wasted effort, this method may work well when the project
team is inexperienced or less technically competent (McConnell 1996).
Rapid Applications Development (RAD) On the other hand, one can take a
less-structured approach to developing systems. Today, taking less time to
Figure 1.4 Waterfall Model
THE PROJECT LIFE CYCLE AND IT DEVELOPMENT 17
develop, and implement an information system can provide the organization with a
competitive advantage. In addition, as evidenced by the CHAOS study, larger projects
that take longer to develop are riskier than smaller and shorter projects. Satzinger,
Jackson, and Burd (2002, 533) define RAD as "a collection of development approaches,
techniques, tools, and technologies, each of which has been proven to shorten develop-
ment schedules under some conditions." This means that different development
approaches, tools, techniques, and so forth can be mixed and matched depending on the
project. For some projects, it means that the Waterfall approach is the most appropriate;
however, RAD often follows one of the following iterative approaches:
• Prototyping—Prototyping is an iterative approach to systems development
where the developer and user work together very closely to develop a par
tially or fully functional system as soon as possible, usually within a few
days or weeks. The prototype application will go through a number of itera
tions as functional requirements are defined or changed. This approach is
most useful when the requirements of the new system are difficult to define
or when working with a new technology where the capabilities of that tech
nology are unknown or not understood very well. A prototype may be
either a throwaway system or a fully usable system. A throwaway prototype
may be used to discover or refine system requirement specifications that
can be used as a model for developing the real system. On the other hand,
the prototype may become the actual system after it has gone through a
number of refinements over time.
• Spiral Development—Another way to expedite the SDLC is the spiral
approach first proposed by Barry Boehm (1988). The spiral model provides
a risk-oriented approach where a software project is broken up into a num
ber of miniprojects where each addresses one or more major risks until all
major risks have been addressed (McConnell 1996). A risk can be defined
as a poorly understood requirement or architecture or as a potential prob
lem with the technology or system performance. The basic idea is to begin
development of the system on a small scale where risks can be identified.
Once identified, the development team then develops a plan for addressing
these risks and evaluates various alternatives. Next, deliverables for the
iteration are identified, developed, and verified before planning and com
mitting to the next iteration. Subsequently, completing each iteration brings
the project closer to a fully functional system. Reviews after each iteration
provide a means of controlling the overall risk of the project. Major prob
lems or challenges will surface early in the project and, therefore, provide
the potential to reduce the total cost of the project. The disadvantages to the
spiral development approach center on its complexity (Satzinger, Jackson,
Burd 2002). These types of projects are more complex to manage because
many people may be working on a number of different parallel activities.
• Extreme Programming (XP)—Kent Beck introduced the idea of XP in the
mid-1990s. Under XP, the system is transferred to the users in a series of
versions called releases. A release may be developed using several itera
tions and should be developed and tested within a few weeks or months.
Each release is a working system that only includes one or several func
tions that are part of the full system specifications. XP includes a number
of activities where the user requirements are first documented as a user
story. The user stories are then documented using an object-oriented model
18 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS
called the class diagram, and the release is developed over the course of
several iterations. A set of acceptance tests for each user story is then developed.
Releases that pass the acceptance test are then considered complete. XP
provides the continuous testing and integration of different software modules
and components while supporting active user involvement. In addition, XP
often incorporates team programming where two programmers work together
on the same workstation. Small teams of developers often work in a common
room where workstations are positioned in the middle and workspace for each
team member is provided around the perimeter. Developers often are
prohibited from working more than 40 hours a week in order to avoid burnout
and the mistakes that often occur because of fatigue (Satzinger, Jackson, Burd
The PLC versus the SDLC
You may be still wondering about the difference between the project life cycle and the
systems development life cycle. Although they may seem to be quite similar, the dif-
ference is that the product life cycle focuses on the processes of managing a project,
while the SDLC focuses on creating and implementing a product—the information
system. In this text we will focus primarily on the PLC, although the SDLC and the
particular approach we choose will have a direct bearing on the project's scope (i.e.,
the deliverables that the project team must provide) and the work activities needed to
produce those deliverables. Consequently, the number of activities, their sequence,
time-to-complete, and resources required will directly determine the project's schedule
As illustrated in Figure 1.5, the SDLC is really part of the PLC because many of
the activities for developing the information system occur during the execution phase.
The last two stages of the PLC, closing and evaluating the project, occur after the
implementation of the information system.
The integration of project management and system development activities is one
important component that distinguishes IT projects from other types of projects. A
THE PROJECT MANAGEMENT BODY OF KNOWLEDGE 19
methodology will be presented in Chapter 2 and will illustrate how the project life
cycle and systems development life cycle can be combined to manage the process and
product of IT projects. This methodology will provide a foundation for the concepts,
processes, tools, and techniques throughout this text.
THE PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK)
As was mentioned earlier, the Guide to the Project Management Body of Knowledge
is a document available from the Project Management Institute (PMI) — an interna-
tional, nonprofit, professional organization with more than 55,000 members world-
wide. The original document was published in 1987, and the updated version provides
a basis for identifying and describing the generally accepted principles and practices
of project management. However, as PMBOK is quick to point out, "generally
accepted" does not mean these principles and practices work the same way on each
and every project. It does mean that many people over time believe that these princi-
ples and practices are useful and have value. Determining what is appropriate is the
responsibility of the team and comes from experience. (Perhaps experiences that can
be documented and shared?)
This text will use the PMBOK Guide as a foundation but will also integrate a
number of concepts and ideas that are part of the body of knowledge that makes up
the field of information systems. Ideally, you will then understand not only what
many IT project managers and organizations throughout the world think are impor-
tant, but also the language and the processes.
PMI provides a certification in project management through the Project
Management Professional (PMP) certification exam. This text can also help you pre-
pare for the PMP certification exam. To pass, you must demonstrate a level of under-
standing and knowledge about project management, satisfy education and experience
requirements, and agree to and adhere to a professional code of ethics.
Project Management Knowledge Areas
The Guide to the Project Management Body of Knowledge defines nine knowledge
areas for understanding project management. These nine knowledge areas are illus-
trated in Figure 1 .6 and will be covered in more detail in later chapters.
• Project Integration Management — Integration focuses on coordinating the
project plan's development, execution, and control of changes.
• Project Scope Management — A project's scope is the work to be completed
by the project team. Scope management provides assurance that the pro
ject's work is defined accurately and completely and that it is completed as
planned. In addition, scope management includes ways to ensure that
proper scope change procedures are in place.
• Project Time Management — Time management is important for developing,
monitoring, and managing the project's schedule. It includes identifying the
project's phases and activities and then estimating, sequencing, and assign
ing resources for each activity to ensure that the project's scope and objec
tives are met.
• Project Cost Management — Cost management assures that the project's
budget is developed and completed as approved.
20 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS
Figure 1.6 Project Management Body of Knowledge (PMBOK)
Project Quality Management—Quality management focuses on planning,
developing, and managing a quality environment that allows the project to
meet or exceed stakeholder needs or expectations.
Project Human Resource Management—People are the most important
resource on a project. Human resource management focuses on creating and
developing the project team as well as understanding and responding
appropriately to the behavioral side of project management.
Project Communications Management—Communication management
entails communicating timely and accurate information about the project to
the project's stakeholders.
Project Risk Management—All projects face a certain amount of risk.
Project risk management is concerned with identifying and responding
appropriately to risks that can impact the project.
Project Procurement Management—Projects often require resources (peo-
ple, hardware, software, etc.) that are outside the organization. Procurement
management makes certain that these resources are acquired properly.
REVIEW QUESTIONS 21
This chapter provides an introduction to the text and to
the area of information technology project management
(ITPM). As evidenced by the CHAOS report published
by The Standish Group, many IT projects are late and
over-budget and include only a fraction of the function-
ality originally envisioned. Although many factors con-
tribute to a project's success or failure, the product and
process associated with the development of an informa-
tion system must be actively managed. This manage-
ment includes taking a socio-technical approach that
focuses not only on the technology, but also on the orga-
nizational side. In addition, individuals and organiza-
tions can learn and share their experiences. These
experiences, in the form of lessons learned, can be used
to develop new ideas and best practices that can be
implemented in an organization's systems development
and project management policies and methods.
The Guide to the Project Management Body of
Knowledge (PMBOK Guide) defines a project as a tem-
porary endeavor undertaken to accomplish a unique pur-
pose and project management as the application of
knowledge, skills, tools, and techniques to project activ-
ities in order to meet or exceed stakeholder needs and
expectations. Projects can also be viewed in terms of
their attributes. These attributes include the project's
time frame, purpose, ownership, resources, roles, risks
and assumptions, tasks, and the impact the project will
have on the organization. Projects also operate in an
environment larger than the project itself. The com-
pany's culture, environment, politics, strategy, structure,
policies, and processes can influence the selection of
projects, the IT infrastructure, and the role of IT within
the organization. Similarly, the selection of projects, the
IT infrastructure, and the role of IT within the organiza-
tion can influence the organizational variables.
The project life cycle (PLC) is a collection of logical
stages or phases that maps the life of a project from its
beginning to its end. It also helps in defining, building, and
delivering the product of a project. Projects are broken up
into phases to make the project more manageable and to
reduce risk. In addition, each phase should focus on pro-
viding a deliverable—a tangible and verifiable product of
work. A generic project life cycle was introduced. Its
phases included (1) defining the project goal, (2) planning
the project, (3) executing or carrying out the project, (4)
closing the project, and (5) evaluating the project.
Although projects follow a project life cycle, information
systems development follows a product life cycle.
The Systems Development Life Cycle (SDLC) rep-
resents the sequential phases or stages an information
system follows throughout its useful life. The SDLC
described in this chapter includes the following phases:
(1) planning, (2) analysis, (3) design, (4) implementa-
tion, (5) maintenance and support. In addition, the
SDLC can be implemented using a structured approach
(the Waterfall model) or by means of more iterative
approaches. By following a rapid applications develop-
ment (RAD) approach, systems developers can combine
different approaches, tools, and techniques in order to
shorten the time needed to develop an information sys-
tem. The SDLC is really a component of the PLC, and
choice of a particular approach for systems development
will influence the activities, their sequence, and the esti-
mated time to complete. In turn, this will directly impact
the project's schedule and budget.
The Guide to the Project Management Body
Knowledge outlines nine knowledge areas for under-
standing project management. These nine areas include:
(1) project integration management, (2) project scope
management, (3) project time management, (4) project
cost management, (5) project quality management, (6)
project human resources management, (7) project com-
munications management, (8) project risk management,
and (9) project procurement management. Along with a
number of concepts and principles that make up the
body of knowledge for information systems, these nine
PMBOK areas will be integrated in the chapters
throughout this text.
1. Describe the software crisis in your own words. 5.
2. How is a successful project defined in the CHAOS
3. How is a challenged project defined in the CHAOS "•
4. How is an impaired project defined in the CHAOS
Why are many IT projects late, over budget, and
with fewer features and functions than originally
What is the socio-technical approach to systems
What are the benefits to using a project manage-
ment approach to developing information systems?
22 CHAPTER 1 / THE NATURE OF INFORMATION TECHNOLOGY PROJECTS
8. What is a methodology? What are the advantages of
following a methodology when developing an
9. How does sharing experiences in the form of les
sons learned lead to best practices in managing and
developing information systems?
10. What is a project?
11. What is project management?
12. What are the attributes of a project?
13. Describe the relationship among scope, schedule,
14. Describe the different roles and skill sets needed for
15. Describe three risks that could be associated with
an IT project.
16. Why should assumptions associated with a project
17. Discuss the statement: Projects operate in an envi
ronment larger than the project itself.
18. Describe the project life cycle.
19. What are phase exits, stage gates, and kill points?
What purpose do they serve?
20. What is fast tracking? When should fast tracking be
used? When is fast tracking not appropriate?
21. Describe the Systems Development Life Cycle
22. Describe the Waterfall model for systems develop
ment. When should the Waterfall model be used?
23. Describe the prototyping approach to systems
development. When is prototyping appropriate?
24. Describe the Spiral approach for iterative develop
ment. What advantages does this model have in
comparison with the Waterfall model?
25. Describe extreme programming (XP). How does
XP accelerate the SDLC?
26. What is knowledge management? Although many
people believe knowledge cannot be managed, why
do you think many companies are undertaking
knowledge management initiatives?
27. Although the Guide to the Project Management
Body of Knowledge describes the generally
accepted principles and practices of project man
agement, why wouldn't these principles and prac
tices work for every project?
EXTEND YOUR KNOWLEDGE
Using the web or library, find an article that describes
either a successful or an unsuccessful IT project.
Discuss whether any of the project factors listed in
Table 1.2 had any bearing on the project. 2. Design a
template that could be used by a project team to
document its experiences and lessons learned.
Describe or show how these experiences
could be catalogued and shared with other members
and other teams.
3. Using the web or library as a resource, write a
one-page position paper on knowledge management.
You should provide a definition of knowledge
management and your opinion as to whether an
organization should invest in a knowledge
Boehm, B. W. 1988. A Spiral Model of Software Development and
Enhancement. Computer (May): 61-72. Dennis, A. and W. B.
Haley. 2000. Systems Analysis and Design: An
Applied Approach. New York: John Wiley. Gido, J. and J. P.
Clements. 1999. Successful Project Management.
Cincinnati, OH: South-Western College Publishing. Hoffman, T.
and J. King. 2000. Y2K Freeze Melts In January Thaw.
Computer-world, January 17. http://www.computerworld.com
/home/print.nsf/all/000117E04A. Laudon, K. C. and J. P.
Laudon. 1996. Management Information
Systems: Organization and Technology. Upper Saddle River, NJ:
Prentice Hall. McConnell, S. 1996. Rapid Development: Taming
Schedules. Redmond, WA: Microsoft Press.
Meredith, J. R. and S. J. Mantel, Jr. 2000. Project Management: A
Managerial Approach. New York: John Wiley. Project
Management Institute (PMI). 2000. A Guide to the Project
Management Body of Knowledge (PMBOK Guide). Newtown
Square, PA: PMI Publishing. Rosenau, M. D. J. 1998. Successful
Project Management. New York:
John Wiley. Satzinger, J. W, R. B. Jackson, and S. D. Burd.
Analysis and Design in a Changing World. Boston: Course
Technology. Standish Group. 1995. CHAOS. West Yarmouth,
MA: The Standish
Conceptualizing and Initializing
The IT Project
Chapter 2 describes how IT projects are conceptualized and initialized. After study-
ing this chapter, you should understand and be able to:
• Define what a methodology is and describe the role it serves in IT projects.
• Identify the phases and infrastructure that make up the IT project methodology
introduced in this chapter.
• Develop and apply the concept of a project's measurable organizational
• Describe and be able to prepare a business case.
• Distinguish between financial models and scoring models.
• Describe the project selection process as well as the Balanced Scorecard
GLOBAL TECHNOLOGY SOLUTIONS
Tim Williams sat across from Kellie Matthews as the waiter brought their orders and
refilled the water glasses. After the waiter left, Tim handed a folder with GTS
embossed on the cover to Kellie. "I've been giving this a great deal of thought," Tim
said as he reached for the peppershaker. Kellie began to look over the contents of the
folder while Tim waited.
"It's a methodology that I'm working on to help us organize the Husky Air proj-
ect," Tim explained. "In fact," he added, "I think we can use it as a blueprint for all of
our projects. Of course, I'm trying to make it flexible so we can add to it or change it
over time as we learn better ways of doing things."
Kellie thought for a moment. "Will it restrict the project team's creativity?" she
asked. "Husky Air's management is counting on us to come up with some innovative
24 CHAPTER 2 / CONCEPTUALIZING AND INITIALIZING THE IT PROJECT
solutions for them. I know I've always hated the feeling of being constrained by too
Tim was ready with his answer: "Think of this methodology as a road map. If you
were planning a trip, the first thing you would have to do is decide on a destination
based upon your interests. For our purposes, that would be similar to defining the pro-
ject's goal. Once you decide where you're going, you then need to figure out how to
get there and how much it will cost."
"Some kind of plan?" Kellie interjected.
"Exactly!" exclaimed Tim. "A travel plan would help you figure out whether to
drive, fly, take a train, or use a combination to get to your destination. It really
depends on where you're going and how much you want to spend."
Kellie reflected for a moment. "But when I'm on vacation, I like to be sponta-
neous!" she said. "Planning every minute of a vacation takes the fun out of it."
"Aha!" Tim replied. "You see that's the difference between a methodology and a
plan. The methodology would help you to plan your plan."
"What?" said Kellie, "Are you playing a game with words?"
Tim grinned. "No, not really," he answered. "Let's say you went on vacation and had
a terrible time. And maybe you even spent more than you budgeted for your vacation."
"I've had a few of those experiences," Kellie reflected.
"So the next time you decide to take a vacation, you might want to do things dif-
ferently," Tim explained. "What you might do is organize the way you plan your
vacation. First, you may try to come up with a better way of choosing a vacation spot.
Then, you go about picking a mode of travel and reserve your accommodations.
Finally, you figure out what you want to see and do while on your vacation. You may
schedule your vacation by the minute, or you can have a list of places to visit or see
while you're there—it really depends on what would make your vacation enjoyable."
The waiter returned and refilled their water glasses. Kellie thought for a moment.
"I guess we really owe it to our client to have a game plan," she said. "After all, we
can't really just wander in any direction and hope we'll somehow end up at our des-
tination. They're paying us by the hour, and time is money. Besides, we owe it to them
to meet their needs in the most efficient and effective way possible. So, what's our
first step? We're meeting with Husky Air's management tomorrow morning."
"Glad you asked," Tim smiled. "If you take a look at the methodology, you'll see
that the first thing we need to do is prepare a business case. That's where we'll figure
out our destination—I mean, the overall goal of this project. Once we know where
we're headed, we can identify several options for Husky Air. After one is approved,
we'll develop a project charter and plan that defines the detailed schedule and budget.
That will tell us what needs to be done, when, by whom, and how much it will cost. In
addition, the methodology will help make sure that our plan is being followed, or
changed when necessary."
"Sounds good," said Kellie, "But there's just one more thing."
"What's that?" asked Tim.
Kellie grinned. "It's your turn to buy lunch."
Things to Think About:
1. What are the advantages of having and following a project methodology?
2. Why should a methodology be flexible?
3. What perceptions might a client have if GTS has a methodology in place?
If they don't?