The Nature of Information Technology Projects

Information Technology Project Management. Providing Measurable Organizational Value, Third Edition
Chapter 1: The Nature of Information Technology Projects

ISBN: 9780470371930 Author: Jack T. Marchewka
copyright © 2009 John Wiley & Sons Inc.
The Nature of Information Technology Projects

Chapter Objectives

Chapter 1 provides an overview of information technology project management (ITPM). After studying this chapter, you should understand and be able to:

* Describe the dominant eras of information systems called the electronic data processing (EDP) era, the micro era, the network era, and the globalization era, and understand how managing IT projects has evolved during these eras.
* Understand the current state of IT project management and how successfully managing IT projects remains a challenge for most organizations.
* Explain the value-driven, socio-technical, project management, and knowledge management approaches that support ITPM.
* Define what a project is and describe its attributes.
* Define the discipline called project management.
* Describe the role and impact IT projects have on an organization.
* Identify the different roles and interests of project stakeholders.
* Describe some common approaches to structured systems development and iterative systems development.
* Describe the project life cycle (PLC), the systems development life cycle (SDLC), and their relationship.
* Describe Extreme project management.
* Identify the Project Management Body of Knowledge (PMBOK®) core knowledge areas.

Introduction

Information technology (IT) projects are organizational investments. When an organization builds or implements an IT solution, it often commits considerable time, money, and resources to the project with an expectation of receiving something of value in return. To improve the chances of success, you will be introduced to a relatively new discipline called information technology project management (ITPM). Some may argue that managing an IT project is like managing any other project, so all we need to do is apply the processes, tools, and techniques of traditional project management. This may be true to some degree, but a one-size-fits-all approach has not served us all that well in the past. Moreover, building an information system is different from building a house, a bridge, or a rocket for space travel. Although many of the project processes are similar, an entirely different approach to engineering each of these examples is needed. By combining the body of knowledge of modern-day project management with the body of knowledge of management information systems (in particular, software engineering and systems analysis and design), we can craft a better philosophy and method for planning and managing IT projects. This will provide a foundation for a logical and repeatable approach that improves the likelihood of IT project success.

Modern-day project management is often credited to the U.S. Navy, with its initiation of the Polaris missile project as a way to deter potential Soviet nuclear aggression in the early 1950s. The Polaris project was complex and risky, but the Navy used a project management approach to take the project from concept to deployment. This approach was viewed as a great success, and other organizations in various industries began to adopt project management as a way to define, manage, and execute work to achieve a specific objective.

Today, project management is viewed as an effective approach that addresses a wide variety of organizational opportunities and challenges. Project management focuses on reducing costs and product cycle times and provides an important link between an organization’s strategy and the deployment of that strategy. In turn, this will have a direct impact on an organization’s bottom line and competitiveness.

The field of information systems also evolved in parallel with the field of modern project management. According to Richard Nolan, a consultant and Harvard business professor, the use of the business computer has gone through a series of three dominant eras: the electronic data processing (EDP) era, the micro era, and the network era. However, some people believe that we are entering into a new era called globalization. We can look at each of the first three eras to understand how technology supported organizations and the approaches used to manage these projects. As we enter a new era of globalization, many projects can benefit from a foundation built upon past experience and knowledge, but new ways will be needed to overcome many of the challenges and issues that will be encountered.

The EDP era began in the early 1960s and is characterized by the purchase of the first centralized mainframe or a minicomputer by large organizations. The IT projects during this era focused generally on automating various organizational transactions such as general accounting tasks, inventory management, and production scheduling. The manager of this technology resource was often called the data processing (DP) manager and usually reported to the head accounting or financial manager. The goal of using technology was to improve efficiency and reduce costs by automating many of the manual or clerical tasks performed by people. As Richard Nolan (2001) points out, software programmers applied computer technology similar to the ways that farmers or engineers applied steam engine technology to mechanize agriculture. The process remained relatively unchanged, while the means for realizing the process became more efficient. Subsequently, IT projects during this era were generally structured, and therefore a structured approach for managing these projects could be used. Since the requirements or business processes were fairly stable, changing requirements were not a major issue and large, multiyear projects were common. Unfortunately, in many cases these legacy systems created information silos, as projects supported specific business functions that often employed different technology platforms and programming languages.

In the early 1980s, the IBM personal computer (PC) and its subsequent clones signaled the beginning of the micro era. However, the transition or integration from a centralized computer to the PC did not happen immediately or without conflict. The often uncontrolled proliferation of the PC in many organizations challenged the centralized control of many MIS managers. For example, the first PCs cost less than $5,000 and many functional department managers had the authority to bypass the MIS manager and purchase these machines directly for their department. This often led to the rise of user-developed, independent systems that replicated data throughout the organization. Security, data integrity, maintenance, training, support, standards, and the sharing of data became a rightful concern. The organization often had an IT resource that was split between a centralized computer and a collection of decentralized user-managed PCs.

The organization needed to regain control of its IT resource while using IT strategically. Many organizations created the new position called the chief information officer (CIO) to expand the role of IT within the organization. While the DP manager often reported to the head accounting or financial manager, the CIO often reported to the chief executive officer (CEO). Therefore, IT increasingly became viewed as more than just a tool for automating low-level transactions and more of a tool for supporting the knowledge worker. Shoshana Zuboff (1988) coined the term “infomate” to describe the role of computers in this era.

The computer no longer remained under the direct control of the IT function and its spread throughout the various levels of the organization made IT ubiquitous. IT projects had to take more of an organizational view so that policies, standards, and controls become a part of all systems in order for existing mainframe or minicomputer applications to coexist or integrate with a growing surge of PCs. Moreover, a project manager and team could no longer rely on stable business processes, requirements, or technology that would allow for longer project schedules; otherwise, they would face the risk of implementing an obsolete IT solution. Shorter project horizons that crossed functional lines became the norm, while software development methodologies attempted to shorten the development life cycle.

Meanwhile, in the late 1960s and early 1970s, a defense project called ARPANET allowed university researchers and scientists to share information with one another even in the event of a nuclear war. By the mid-1980s, this network of computers became known as the Internet and led to the network era that began around 1995. In the network era, IT projects focused primarily on the challenge of creating an IT infrastructure to support many partners, strategic alliances, vendors, and customers. The network architecture had to be scalable so that potentially thousands of networked computers could function in an efficient and timely manner. Moreover, digital convergence or the integration of data, voice, graphics, and video allowed for new and innovative ways to deliver new products and services to customers. While the micro era focused on creating an internal network within the organization, the thrust of the network era was to extend this network externally. Network era projects not only faced the challenge of coordination and control, but also how to support a dynamic business strategy and new organizational structures. IT project members not only needed to understand the technology, but the organization and its competitive environment. As witnessed by the rise and fall of many dot com businesses in the late 1990s, the benefits and risks of managing IT projects were much higher than the two previous eras.

With the new millennium, IT received a great deal of attention in the media and the boardroom. Some people at the end of the century emptied their bank accounts and stockpiled food and water for fear that computers would crash and civilization would fall into mass confusion. Fortunately, the reported Y2K computer-related problems were few and not too critical. But what made the Y2K problem fascinating was that just about everyone was in it together and the project had an immovable deadline. To fix the Y2K date problem in the millions of lines of code, many organizations took advantage of cheaper wage rates and outsourced the rewriting of its code overseas to such countries as India.

After Y2K, it appeared that organizations now had the time and money to start on the IT projects that had been put on hold. Electronic commerce, enterprise resource planning (ERP) and customer relationship management (CRM) systems were at the top of the IT project list for many organizations. Together with large, global investments in fiber optics and the rise of the dot coms, the demand for skilled IT professionals and IT project managers to head up these new initiatives had never been stronger. Recruiters couldn’t hire experienced professionals and university graduates fast enough to meet the demand.

Unfortunately, this golden time for IT did not last, especially in the United States. The tragic events of September 11, 2001 had a profound impact on the world and the global economy. As a result, many organizations were forced to make some difficult choices in order to survive. Seasoned IT professionals and new graduates who once commanded high salaries and choice assignments found themselves facing a tough job market. The bubble had burst. People learned that things can change quickly and without warning.

According to Richard Nolan, people, organizations, and even society goes through a period of discontinuity whereby people try to make sense of the changes created by the transition from one era to the next. Some people such as Thomas L. Friedman (2007) suggest that we may be entering into a new era called globalization. According to Friedman, the combination of technology and lowering of political barriers has flattened the world so that it is possible for people and organizations to work with almost anyone in any place and at any time. Moreover, the real IT revolution is just beginning as the global competitive playing field becomes leveled for everyone.

What does this mean for you? As a project manager or member of a project team you will be involved in projects that are more dynamic, geographically dispersed, and ethnically or culturally diverse than ever before. The risk and rewards will be greater than the previous eras. Therefore, a solid set of technical, nontechnical, and project management skills founded upon past experience and adapted to this new environment will be needed to manage IT projects successfully.

In both good times and bad, senior management will make a certain level of funding available for IT projects. The budgeted amount will depend on such things as the economy, competitors’ actions within the industry, and the organization’s strategic plan. Regardless whether an organization’s budget for IT projects shrinks or grows, the resources available for any given period will be relatively fixed. Quite often the total funding requests for proposed projects will be greater than the available budget. As a result, any project that receives funding will do so at the expense of another project. The competition for funding IT projects proposed by the various business units or departments within an organization will be especially keen when the budget is tight. Projects that do not receive any funding will either have to wait or fall by the wayside. Therefore, the decision to fund a specific project will always be an important management decision because it will have a major impact on the organization’s performance.

The decision to fund or invest in an IT project should be based on the value that the completed project will provide the organization. Otherwise, what is the point of spending all that time, effort, and money? Although senior management must make the difficult decision as to which IT projects receive funding and which ones do not, others must plan and carry out the project work. Which situation is worse: successfully building and implementing an information system that provides little or no value to the organization, or failing to implement an information system that could have provided value to the organization, but was developed or managed poorly? It’s probably a moot point: In either situation everyone with a direct or indirect interest in the project’s success loses.
The Purpose of This Book

The goal of this book is to help you to plan and manage information technology projects. We will focus on a number of different theories, but the main emphasis will be on applying the methods, tools, techniques, and processes for planning and managing an IT project from start to finish. If you are a project manager (or will be one soon), this book will help you to understand and apply project management principles in order to better manage your IT project. If you are just starting out in the field, this book will help you to understand the big picture of what an IT project is all about. This knowledge will help you to become a better team member and prepare you for the next several progressions in your career.

Many of the principles of project management can be applied to just about any project, but IT projects are unique in several ways. Throughout the text, we will discuss what makes IT projects different from other types of projects and how the principles and methods of system development can be integrated to define the IT project management discipline. Although many of the concepts for developing an information system will be integrated throughout, this is not a systems analysis and design text. More specifically, we will not delve too deeply into the systems analysis and design techniques that are used during systems development. We will leave that for other books and classes.

The remainder of this book provides a foundation for understanding project planning processes, methods, and tools. We will begin by understanding the nature of IT projects and then follow the project life cycle from project initiation through implementation and closure. Throughout the book you will be introduced to a number of project management knowledge areas and related software engineering concepts. While the goal of this book is not to prepare you for a professional certification in project management, it will provide a solid base to help you in your career and later on should you choose to become a certified project manager.
The State of IT Project Management

Although IT is becoming more reliable, faster, and less expensive, the costs, complexity, and risks of managing IT projects continues to be a challenge for many organizations. Although IT projects have experienced challenges since the DP era, a survey conducted by the Standish Group of 365 IT managers in 1994 drew attention to what many called the software crisis. The study was called CHAOS and reported that only 16 percent of the application development projects were successful in terms of being completed on time and within budget. Moreover, about 31 percent of the projects were canceled before completion, while 53 percent were completed but over budget, over schedule, and not meeting original specifications. The average cost overrun for a medium-size company surveyed was about 182 percent of the original estimate, while the average schedule overrun was about 202 percent. That is, the results of the survey suggest that a medium-size project estimated to cost about $1 million and take a year to develop actually cost about $1.8 million, took just over two years to complete, and only included about 65 percent of the envisioned features and functions. Many took this to mean that IT project management was in a state of crisis, especially since 48 percent of the IT managers surveyed believed that there were more failures at the time than five or ten years earlier.

The 1994 CHAOS study has become one of the most cited, and Robert Glass (2005) raises the issue that people tend to quote the original 1994 figures while ignoring the fact that the Standish Group has updated the CHAOS reports every two years. A key reason may be that the 1994 study is free and easily attainable from the Standish Group, while the later studies must be purchased and thus are an expensive barrier for many researchers and practitioners. Fortunately, a summary of the later studies can be found using a good Internet search engine. The findings of these studies from 1994 through 2006 are summarized in Figure 1.1. Overall, it appears that IT projects are showing a higher success rate. For example, the latest study in 2006 reports that 35 percent of the IT projects were classified as successful in terms of being completed on time, within budget, and including all of the features or requirements envisioned. The Standish Group attributes this continuing improvement to better project management tools and processes, smaller projects, improved communication, more skillful IT project managers, and iterative development.

Figure 1.1 Summary of CHAOS Studies from 1994 to 2006

[Click to enlarge]

SOURCE: http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS.

Interestingly, the CHAOS studies also report factors for successful and unsuccessful projects. Table 1.1 provides a summary of key factors for successful projects for three different time periods. It appears that successful projects have a strong nontechnical component in terms of executive support and user involvement that may lead to clearly defined requirements and project objectives, while the technology, tools, and methods play an important, but lesser, role.

Table 1.1 Summary of CHAOS Study Factor Rankings for Successful Projects
Rank 1994 2001 2006
1
User involvement
Executive support
User involvement
2
Executive management support
User involvement
Executive management support
3
Clear statement of requirements
Experienced project manager
Clear business objectives
4
Proper planning
Clear business objectives
Optimizing scope
5
Realistic expectations
Minimized scope
Agile process
6
Smaller project milestones
Standard software infrastructure
Project management expertise
7
Competent staff
Firm basic requirements
Financial management
8
Ownership
Formal methodology
Skilled resources
9
Clear vision & objectives
Reliable estimates
Formal methodology
10
Hard-working, focused team
Other
Standard tools and infrastructure

SOURCE: Adapted from the Standish Group, CHAOS (West Yarmouth, MA: 1995) and http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS.

However, a study of 800 senior IT managers from the U.K., United States, France, Germany, India, Japan, and Singapore conducted by Tata Consultancy Services (2007) reports dire results similar to the CHAOS studies:

* sixty-two percent of the IT projects failed to meet their schedules
* forty-nine percent experienced budget overruns
* forty-seven percent experienced higher than expected maintenance costs
* forty-one percent failed to deliver the expected business value and return on investment (ROI)

A recent study of 114 IT professionals by Marchewka (2007) looked at perceived project performance and customer satisfaction over the past three years. A segment of this study’s results are summarized in Table 1.2. A majority of respondents reported that their organization’s ability to meet project schedules, budgets, and requirements has gotten better or much better in the past three years. Similarly, only a minority of the IT professionals surveyed believe that internal or external customer satisfaction has become worse over the past three years.

Table 1.2 Project Performance and Internal/External Customer Satisfaction
  Much Worse Worse Same Better Much Better
IT project performance over the past 3 years
Ability to meet project schedules
0.0%
12.3%
40.4%
41.2%
6.1%
Ability to meet project budgets
1.8%
10.5%
44.7%
37.7%
5.3%
 Ability to complete project scope or system requirements
2.6%
7.0%
41.2%
41.2%
7.9%
Customer satisfaction over the past 3 years (customers can be internal, e.g., HR department; or external, e.g., a particular client)
Overall satisfaction of the customer
1.8%
13.2%
34.2%
39.5%
11.4%
Perceived value of the delivered product to the customer
0.0%
9.6%
39.5%
38.6%
12.3%
Potential for future work with the customer
0.9%
3.5%
42.1%
38.6%
14.9%

SOURCE: J.T. Marchewka (2007); n = 114.

All studies have strengths and weaknesses. More research over time and broader samples will allow us to better understand the state of IT project management. While we will never be able to achieve a 100 percent success rate for all projects, we should strive to understand why certain projects are successful and others are not. While some people may argue that the success rate for IT projects is getting better, there is still ample room for improvement.
Why IT Projects Fail

One reason for high failure rates in the CHAOS studies may be the way we define “success” and “failure.” For example, Robert Glass (2005) asks, How should a project be classified if it is “functionally brilliant” but is over budget and over schedule by 10 percent? According to the CHAOS definition, this would be considered a failure, while in reality, it could be a success for the organization. However, no matter what value a project brings to an organization, a project that continues to exceed its budget and schedule will eventually exceed any potential or real value it can bring to the organization.

The CHAOS studies also provide some interesting insight as to why some projects fail. For example, Table 1.3 summarizes the project factors for not-so-successful projects to see what might be happening. Lack of user input or involvement ranks at or near the top in factors listed under challenged or failed (impaired) projects. One can almost picture that chain of events. Without close support of key users, the team will have a difficult time understanding and defining the requirements of the project. As a result, suspicion and conflicts may arise, and there can easily be an “us versus them” situation between the developers and the users. Without effective communication and a clear direction, changes to the project’s requirements always seem to appear, and both the users and developers may set unrealistic expectations. Management then begins to find fewer reasons to support an unpopular project, and more and more resources may be diverted from it. The project is barely successful, if not a failure.

Table 1.3 Summary of Factor Rankings for Challenged and Failed (Impaired) Projects
Rank Factors for Challenged Projects Factors for Failed (Impaired) Projects
1
Lack of user input
Incomplete requirements
2
Incomplete requirements
Lack of user involvement
3
Changing requirements & specifications
Lack of resources
4
Lack of executive support
Unrealistic expectations
5
Technology incompetence
Lack of executive support
6
Lack of resources
Changing requirements & specifications
7
Unrealistic expectations
Lack of planning
8
Unclear objectives
Didn’t need it any longer
9
Unrealistic time frames
Lack of IT management
10
New technology
Technology illiteracy

SOURCE: Adapted from the Standish Group, CHAOS (West Yarmouth, MA: 1995).

More recently, however, according to a Web-based poll conducted by Computing Technology Industry Association (CompTIA), nearly 28 percent of the more than 1,000 respondents said that poor communication is the number one reason for project failure, followed by insufficient resources (18 percent), and unrealistic schedule deadlines (13.2 percent) (Rosencrance, 2004). Communication is an important component throughout the project in terms of setting project expectations, requirements, as well as schedule and budget constraints. As seen in Table 1.3, a number of factors relating to challenged and failed projects can be attributed directly or indirectly to poor communication.

Insufficient resources can be tied closely to poor communication. All projects require resources in terms of people, technology, and facilities. Communication is important in understanding the appropriate number of people that will be needed, what skill sets they will need, the training that may be necessary, and the tools to do the job.

Moreover, executive sponsors may accept schedule commitments from developers who offer no evidence that they can meet those commitments, while developers may accept schedules that are unrealistic. Not getting the right resources when they are needed may risk that the schedule will not be met. Unrealistic schedules may doom the project before it even starts. According to the CompTIA poll, other factors that contribute to project failure include poor project requirements, lack of stakeholder buy-in/support, undefined project success/closure criteria, unrealistic budget, insufficient or no risk planning, and lack of control/change process.

One can look at troubled projects to identify whether there are any signs of impending failure. These warning signs may include strained relationships among the project team members or between the project team and the client or users, excessive overtime, lost confidence, threats of legal action by the customer or client, and low project stakeholder moral.

What becomes interesting is how many people have accepted IT project problems and failure as the status quo. Figure 1.2 provides a summary of Tata Consultancy Services survey in terms of how business managers and board of directors view IT project failure and problems.

Figure 1.2 Reaction to Failed IT Projects by Business Managers and Board of Directors

[Click to enlarge]

SOURCE: http://www.tcs.com/pdf/Board%20research%20statistical%20factsheet.pdf.
Improving the Likelihood of Success

How can we improve the chances for IT project success and avoid repeating past mistakes? Here are four approaches that will be focal points throughout this book.
A Value-Driven Approach

Plain and simple: IT projects must provide value to the organization. Many people and organizations define project success in terms of the project being completed on time and within budget. While schedule and budget are important, they are not sufficient definitions of project success. For example, if an organization sets a mandate that a particular customer relationship management (CRM) package must be up and running within eight months and cost no more than $1 million to implement, would the project be considered unsuccessful if it required an extra day and an extra dollar to complete? You may think this is trivial, but at exactly what point in terms of schedule or budget does the project become unsuccessful?

We can also turn things around and ask whether finishing a project early and under budget necessarily makes the project successful. Of course, any organization would like to spend less money and have its system delivered early, but what if the system does not perform as expected? More specifically, what value will the organization receive by spending six months and $1 million on this particular project? If IT projects are investments, what measurable value will it receive to offset the time, money, and opportunity cost of purchasing and implementing the CRM system? This value could come in terms of better customer service, more efficient business processes, lower costs, or expanded market share. Therefore, success should not be measured in terms of schedule or budget, but in terms of value. This will put less pressure on project stakeholders to set unrealistic schedules and budget, since the value of the project will be the true measure of success.
A Socio-Technical Approach

In the past, organizations have attempted to improve the chances of IT project success by focusing on the tools, techniques, and methodologies of IT development. A purely technical approach, however, focuses attention on the technology. We can easily end up developing an application that no one asked for or needs. Applications to support electronic commerce, supply chain management, and integration require that at least equal attention be paid to the organizational side. The days of being good order takers are over. We can no longer be content with defining a set of user requirements, disappearing for several months, and then knocking on the user’s door when it is time to deliver the new system. IT professionals must understand the business and be actively creative in applying the technology in ways that bring value to the organization. Similarly, the clients must become stakeholders in the project. This means actively seeking and encouraging their participation, involvement, and vision. The successful application of technology and the achievement of the project’s goal must be an equal responsibility of the developers and users.
A Project-Management Approach

One suggestion of the CHAOS study was the need for better project management. But, isn’t building an information system a project? Haven’t organizations used project management in the past? And aren’t they using project management now? While many organizations have applied the principles and tools of project management to IT projects, many more—even today—build systems on an ad hoc basis. Success or failure of an IT project depends largely on who is, or is not, part of the project team. Applying project management principles and tools across the entire organization, however, should be part of a methodology—the step-by-step activities, processes, tools, quality standards, controls, and deliverables that are defined for the entire project. As a result, project success does not depend primarily on the team, but more on the set of processes and infrastructure in place. A common set of tools and controls also provides a common language across projects and the ability to compare projects throughout the organization.
Quick Thinking—Hottest IT Skills

A recent article in Computerworld highlights a distinct and growing shortage of IT skills. This shortage is being augmented by dramatic declining enrollments in university computer science and information systems programs and the start of the baby boomers heading for retirement. According to CW’s Vital Signs survey, the skill sets that will be in most demand are:

1. Programming/application development—The demand for people knowledgeable in AJAX, .Net, and PHP is going to be red hot as organizations continue to expand deeper into Web-enabling their existing applications.
2. Project management—There is an increased demand for people who can oversee complex projects that deliver clear business benefits.
3. Help desk/technical support—The demand for help desk and technical support will grow as organizations expand their applications portfolios. Much more of this expertise will remain in house, with only a small part of the work being contracted offshore.
4. Security—While there will always be a demand for people with security knowledge in intrusion detection, database and wireless security projects will drive that demand even higher.
5. Data centers—Many organizations and government agencies have begun to upgrade or relocate their data centers to take advantage of recent data automation and efficiency gains such as virtualization. Moreover, the demand for data centers is also increasing due to expanding data management and storage requirements as a result of regulations such as Sarbanes-Oxley and Health Insurance Portability and Accountability Act (HIPPA). Subsequently, individuals experienced in mainframe and database technologies will be needed as organizations place greater reliance on large, open systems to run mission-critical applications.
6. Business knowledge—Information technology must align closely with the business side of the organization so there will be a strong demand for IT professionals who have a solid understanding of the business.
7. Networking and telecommunications—All types of networking skills are in demand, including general network administration, network convergence, wireless, and network security as organizations move from voice and data networks to wireless and voice-over-IP technologies.

1. Do any of the hottest skills listed above surprise you? Why or why not?
2. Why do you think project management is one of the hottest skills?
3. If you were a project manager, how might the shortage of skilled IT professionals affect your project?

In addition, other reasons for project management to support IT projects include:

* Resources—When developing or purchasing an information system, all IT projects are capital projects that require cash and other organizational resources. Projects must be estimated accurately, and cost and schedules must be controlled effectively. Without the proper tools, techniques, methods, and controls in place, the project will drain or divert resources away from other projects and areas of the organization. Eventually, these uncontrolled costs could impact the financial stability of the organization.
* Expectations—Today, organizational clients expect IT professionals to deliver quality products and services in a professional manner. Timely status updates and communication, as well as sound project management practices, are required.
* Competition—Internal and external competition has never been greater. An internal IT department’s services can easily be outsourced if the quality or cost of providing IT services can be bettered outside the organization. Today, competition among consultants is increasing as they compete for business and talent.
* Efficiency and effectiveness—Peter Drucker, the well-known management guru, defined efficiency as doing the thing right and effectiveness as doing the right thing. Many companies report that project management allows for shorter development time, lower costs, and higher quality. Just using project management tools, however, does not guarantee success. Project management must become accepted and supported by all levels within the organization, and continued commitment in terms of training, compensation, career paths, and organizational infrastructure must be in place. This support will allow the organization to do the right things and do them right.

A Knowledge-Management Approach

A socio-technical approach and a commitment to project management principles and practices are important for success. However, excellence in IT project management for an individual or an organization takes time and experience. Knowledge management is a systematic process for acquiring, creating, synthesizing, sharing, and using information, insights, and experiences to transform ideas into business value. Although many organizations today have knowledge management initiatives under way, and spending on knowledge management systems is expected to increase, many others believe that knowledge management is just a fad or a buzzword.

What about learning from experience? Experience can be a great teacher. These experiences and the knowledge gained from these experiences, however, are often fragmented throughout the organization. Chances are that if you encounter what appears to be a unique problem or situation, someone else in your organization has already dealt with that problem, or one very similar. Wouldn’t it be great to just ask that person what they did? What the outcome was? And, would they do it again the same way? Unfortunately, that person could be on the other side of the world or down the hall—and you may not even know!

Knowledge and experience, in the form of lessons learned, can be documented and made available through the technologies accessible today, technologies such as the World Wide Web or local versions of the Web called intranets. Lessons learned that document both reasons for success and failure can be valuable assets if maintained and used properly. A person who gains experience is said to be more mature. Similarly, an organization that learns from its experiences can be more mature in its processes by taking those lessons learned and creating best practices—simply, doing things in the most efficient and effective manner. In terms of managing IT projects, managing knowledge in the form of lessons learned can help an organization develop best practices that allow all of the project teams within the organization to do the right things and then to do them right. As summarized in the CHAOS report:

There is one aspect to be considered in any degree of project failure. All success is rooted in either luck or failure. If you begin with luck, you learn nothing but arrogance. However, if you begin with failure and learn to evaluate it, you also learn to succeed. Failure begets knowledge. Out of knowledge you gain wisdom, and it is with wisdom that you can become truly successful (Standish Group 2002, 4).

Quick Thinking—Top IT Projects
Rank 2005 2006 2007
1
Application integration
Voice-over-IP
Business process improvement
2
Business analytics
Outsourcing
Customer relationship management
3
Enterprise portals
Data networking
Business analytics/business intelligence
4
Customer relationship management
Customer relationship management
Desktop/laptop upgrades
5
Intrusion detection & prevention
Collaboration
Web services
6
Financial reporting
Supply chain management
Disaster planning/recovery
7
Application consolidation
Desktop upgrades
Intrusion detection & prevention
8
Data management
Application performance management
Server upgrades
9
Voice-over IP
Business analytics
Enterprise system planning
10
Desktop upgrades
Compliance tracking
Financial reporting

The following was compiled from Baseline’s Top IT Project surveys from 2005, 2006, and 2007. Organizations can spend a few thousand to a few million dollars on a project, while some projects can take a few weeks to a few years to complete.

1. Choose one of the projects from the table for consideration. How might this particular IT project meet a business or organizational need?
2. What factors might lead to an unsuccessful project?

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 nonprofit professional association in the area of project management. 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, 2004) provides widely used definitions for project and project management.

A project is a temporary endeavor undertaken to accomplish a unique product, service, or result. (5)

Project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements… . Managing a project includes:

* Identifying requirements
* Establishing clear and achievable objectives
* Balancing the competing demands for quality, scope, time, and cost
* Adapting the specifications, plans, and approaches to the different concerns and expectations of the various stakeholders (8)

Attributes of a Project

Projects can also be viewed in terms of their attributes: time frame, purpose, ownership, resources, roles, risks and assumptions, interdependent 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 determine 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 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 satisfaction, the project’s goal must be clearly defined and agreed on. A better 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 implementing and maintaining the system. Although a project may have many stakeholders (i.e., people or groups who have a vested interest in the project’s outcome), a project should have a clearly defined sponsor. The sponsor may be an executive, the end user, customer, or the client who has the ability 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 constraint. For example, the project’s scope, or work to be accomplished, is determined 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 the scope increases, then 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.3. It should be a consideration whenever making a decision that affects the project’s goal, scope, schedule, or budget.

Figure 1.3 The Scope, Schedule, and Budget Relationship—the Triple Constraint

[Click to enlarge]
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 or leader—The project manager or team leader is responsible for ensuring that all of the project management and technical development 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 organizational 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 organization 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 technical solution to an organizational problem. Technical experts can include systems analysts, network specialists, programmers, graphic artists, trainers, and so forth. Regardless of their job title, these individuals are responsible 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 estimation 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 a form of risk that we introduce into the project in terms of forecasts or predictions. They 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. In addition, projects are also characterized by progressive elaboration. This means that many of the project tasks will be conducted in steps or increments. For example, the features and functionality of an information system will be defined at a higher or abstract level early on in the project, but will eventually be defined at a much greater level of detail later on. Progressive elaboration will result as part of the systems development process or as the project manager and team gain a deeper understanding of the project or as new information becomes available.
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 system 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. 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 organizational variables can help the project team understand the political climate within the organization and identify potential risks and issues that could impede the project.
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.

Just like 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 on the industry or project, all project life cycles will have a beginning, a middle, and an end (Rosenau 2007; Gido and Clements 1999). Figure 1.4 provides a generic life cycle that describes the common phases or stages shared by most projects.

Figure 1.4 Generic Project Life-Cycle

[Click to enlarge]
Define Project Goal

Defining the project’s overall goal should be the first step. 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. The project goal should also answer the question: How will we know if this project is successful given the time, money, and resources invested? In addition, 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 success should increase.
* The ability for stakeholders to influence the scope and cost of the project is highest at the beginning of the project. The cost of changing the scope and correcting errors becomes more expensive as the project progresses.

Plan Project

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.
Execute Project Plan

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. Progress must be documented and compared to the baseline plan. In addition, project performance must be communicated to all of the stakeholders. At the end of this phase, the team implements or delivers a completed product to the organization.
Close Project

As mentioned previously, a project should have a definite beginning and end. The closing phase ensures that all of the work is completed as planned and as agreed to by the team and the sponsor. Therefore, there should be some kind of formal acknowledgment by the sponsor that they will accept (and pay for!) the product delivered. 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.
Evaluate Project

Sometimes the value of an IT project is not readily known when the system is implemented. 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 in revenue 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 team member’s performance 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 team and project manager may also be evaluated in terms of whether they acted in a professional and ethical manner.
The Systems Development Life Cycle (SDLC)

Although projects follow a project life cycle, information systems development follows 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 logical 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 are variations of the SDLC, the life cycle depicted in Figure 1.5 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 one another.

Figure 1.5 Systems Development Life Cycle

[Click to enlarge]

Planning, analysis, design, implementation, and maintenance and support are the five basic phases in the systems development life cycle.
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, systems 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 document 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 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 altered 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.
Implementing the SDLC

There are a number of ways to implement the SDLC. The chosen method or approach depends on the size and complexity of the project, as well as the experience and skills of the project team. A particular method will not only define the software processes and tools needed, but will also be a critical factor for developing the project plan in terms of defining project phases, deliverables, tasks, and resources that will be used to estimate the project’s schedule and budget. Today, an IT project will follow a structured development approach or an iterative development approach.
Structured Approach to Systems Development

A structured approach to systems development has been around since the 1960s and 1970s, when large mainframe applications were developed. The waterfall model illustrated in Figure 1.6 was developed as a simple and disciplined method that follows the SDLC closely in a very sequential and structured way. The idea of a waterfall is a metaphor for a cascading of activities from one phase to the next where one phase is completed before the next phase is started.

Figure 1.6 Waterfall Model

[Click to enlarge]

The waterfall model stresses a sequential and logical flow of software development activities. For example, design activities or tasks begin only after the requirements are defined completely. Subsequently, the building or coding activities will not start until the design phase is complete. Although there is some iteration where the developers can go back to a previous stage, it is not always easy or desirable.

One characteristic of the waterfall model is that a great deal of time and effort is spent in the early phases getting the requirements and design right because it is more expensive to fix a bug or add a missing requirement in the later phases of the project.

An advantage of the waterfall model is that it allows us to plan each phase in detail so that the project schedule and budget can be computed by summing the time and cost estimates for all the tasks defined in each phase. In theory, the project will be completed on time and within budget if each phase is completed according to our estimates.

This approach is still used today, especially for large government systems and by companies that develop shrink-wrap or commercial software packages (NASA 2004). A structured approach is suitable when developing large, more complex systems where one assumes, or at least hopes, that the requirements defined in the early phases 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, the waterfall model may work well when the project team is inexperienced or less technically competent (McConnell 1996).
Iterative Systems Development

Critics of the structured approach to systems development argue that it takes too long to develop systems and that it does not embrace the idea that changing requirements are inevitable. Inexperienced developers often have the false belief that if they ask the users what they want, they will be rewarded with a set of clear, accurate, and complete requirements. In truth, most users do not know or are unable to articulate their needs early on in the project. And if they do, those requirements will most likely change later on. Over the years, a number of iterative approaches to systems development have been proposed. The central theme focuses on shortening the SDLC and embracing the idea that requirements are difficult to define and will change. Iterative methods tend to emphasize working software to measure progress and are rely heavily on face-to-face communication. Subsequently, a different approach to project planning will be needed. While a bottom-up planning approach tends to work best for software development using a structured approach, a box of time (e.g., two weeks) is generally allocated for each version or iterative cycle. The following summarize some common iterative approaches for systems development:

* Rapid applications development (RAD)—RAD was proposed by James Martin in the early 1990s as a less formal way to expedite the SDLC. RAD attempts to compress the analysis, design, build, and test activities of the SDLC into a series of short iterations or development cycles. For example, a small team of users and developers would work closely together to develop a set of system requirements during a workshop. Using tools such as computer-aided software engineering (e.g., CASE) or visual development environments (e.g., .NET), the developers would then work with the users to develop a functional or usable version of the system that might include only 25 percent of the total requirements. The development cycle would continue with a second usable version that would include the next 25 percent of the requirements. Subsequent iterations would continue until all of the requirements are included in the system.
* Prototyping—Similar to RAD, prototyping is an iterative approach to systems development where the user and developer work closely together to develop a partially or fully functional system as soon as possible. Often, however, a prototype may be developed to discover or refine system requirement specifications that can be used as a model for developing a real system. For example, a team may develop a nonfunctional user interface on a personal computer as a model to define the look, feel, and features of a large, multi-user system.
* Spiral development—Another way to expedite the SDLC is the spiral approach first proposed by Barry Boehm (1988). The spiral model breaks up a software project into a number of miniprojects that address one or more major risks until all the risks have been addressed (McConnell 1996). A risk, for example, could be a poorly understood requirement or a potential technical problem or system performance issue. The basic idea is to begin development of a 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 committing to the next iteration. As a result, the completion of each iteration brings the project closer to a fully functional system.
* Agile systems development—Agile methods are becoming an increasingly popular approach to systems development and include various methodologies such as SCRUM, dynamic systems development method (DSDM), and adaptive software development (ASD). However, one of the most commonly known agile methodologies is eXtreme programming (XP), which was introduced by Kent Beck 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 iterations that are developed and tested within a few weeks or months. Each release is a working system that includes only one or several functions 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 called a class diagram. A set of acceptance tests is then developed for each user story. Releases that pass the acceptance tests are then considered complete. Small teams of developers often work in a common room where workstations are positioned in the middle and a workspace for each team member is provided around the perimeter. In addition, XP often incorporates team programming, where two programmers work together on the same workstation. 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 1998).

The PLC and the SDLC

The project life cycle (PLC) focuses on the phases, processes, tools, knowledge and skills for managing a project, while the system development life cycle (SDLC) focuses on creating and implementing the project’s product—the information system. It bears worth mentioning again that how a project team chooses to implement the SDLC will directly affect how the project is planned in terms of phases, tasks, estimates, and resources assigned.

As illustrated in Figure 1.7, the SDLC is really part of the PLC because many of the development activities occur during the execution phase of the PLC. The last two phases of the PLC, close project and evaluate project, occur after the implementation of the information system.

Figure 1.7 PLC and SDLC

[Click to enlarge]

The integration of project management and systems development activities is one important component that distinguishes IT projects from other types of projects. A methodology presented in Chapter 2 will illustrate how the project life cycle and systems development life cycle can be combined to plan and manage the processes and product of an IT project. This methodology will provide a foundation for the concepts, processes, tools, and techniques throughout the text.
Extreme Project Management

Prototyping, spiral development, and extreme programming provide three approaches for implementing and shortening the SDLC. Similarly, eXtreme project management (XPM) is becoming increasingly popular as a new approach and philosophy for managing projects.

Doug DeCarlo (2004) defines XPM as:

The art and science of facilitating and managing the flow of thoughts, emotions, and interactions in a way that produces valued outcomes under turbulent and complex conditions: those that feature high speed, high change, high uncertainty, and high stress (p. 34).

This definition certainly characterizes many of today’s IT projects that exemplify speed, uncertainty, changing requirements, and high risks. According to DeCarlo, a traditional approach to project management often employs an orderly approach that attempts to fit “reality” to the project tools and processes, while XPM embraces the reality that projects are often chaotic and unpredictable. Since most projects are not stable or predictable, an XPM approach does not try to change that reality; rather, it attempts to deal with it through increased flexibility and adaptability.

XPM also differs from a more traditional approach to project management in that XPM takes a more holistic view of planning and managing projects. For example, a key principle of XPM is that requirement changes are inevitable so planning becomes a self-correcting and iterative process. Another important principle of XPM focuses on innovation—not only creative ideas for new products or services, but innovative processes, methods, and tools for managing the project. Therefore, people are vital to the success of the project because their thoughts, emotions, and interactions become a catalyst for new ideas. Although organizing, planning, and control are the focal points of traditional project managers, XPM leadership focuses on enabling people to discover best solutions and self-correct themselves as needed.

At this point, it is important for you to understand that, just like developing information systems, there are a number of approaches to managing projects. Each approach or paradigm has its advantages and disadvantages, proponents and critics. In this book, we will not take a pure, traditional approach to project management, even though many of the processes, methods, and tools could be considered “traditional.” On the other hand, a number of the processes, methods, and tools you will learn about later on could be classified as “eXtreme” project management. We will try to avoid labeling things as belonging under one paradigm or the other. That gets too confusing, and learning and applying only one paradigm can lead to missed opportunities since we might fall into the trap of viewing reality in a certain way. Instead, we will take the view that we have an IT project management toolbox before us. Right now, the toolbox may not have a lot in it, but as we learn about a new tool or idea, we can begin to fill this toolbox so that we can choose the right tool for the right job. While we need to be open and receptive to new ideas and approaches, we still should have an understanding of past approaches and ways so that we can begin to build on a solid foundation. This text provides a beginning. You’ll continue to fill this toolbox throughout your professional career.
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 international, nonprofit, professional organization with more than 55,000 members worldwide. 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 the PMBOK®Guide 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 principles 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 important, 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 prepare for the PMP certification exam. To pass, you must demonstrate a level of understanding 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 PMBOK®Guide defines nine knowledge areas for understanding project management. These nine knowledge areas are illustrated in Figure 1.8 and will be covered in more detail in later chapters.

Figure 1.8 Project management body of knowledge (PMBOK®)

[Click to enlarge]

* 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 project’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 assigning resources for each activity to ensure that the project’s scope and objectives are met.
* Project cost management—Cost management assures that the project’s budget is developed and completed as approved.
* 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 (people, hardware, software, etc.) that are outside the organization. Procurement management makes certain that these resources are acquired properly.

Chapter Summary

This chapter provides an introduction to the text and to the area of information technology project management (ITPM). The field of information systems (IS) has evolved in parallel with the field of modern day project management. Since the 1960s the use of the business computer has gone through a number of eras: the electronic data processing (EDP) era, the micro era, and the network era. Some propose, however, that we have entered into a new era called globalization. Each era brings new challenges and issues for organizations and society, as well as for managing IT projects. As evidenced by a number of studies since the mid-1990s, successfully managing IT projects continues to be a challenge for many organizations. Although many factors contribute to a project’s success or failure, the project and product processes associated with developing an IS must be managed actively. This includes (1) a value-driven approach, (2) a socio-technical approach, (3) a project management approach, and (4) a knowledge management approach.

The Guide to the Project Management Body of Knowledge (PMBOK®Guide) defines a project as a temporary endeavor undertaken to accomplish a unique purpose and project management as the application of knowledge, skills, tools, and techniques to project activities 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 company’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 organization 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 providing 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) represents 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) implementation, (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 development (RAD) approach, systems developers can combine different approaches, tools, and techniques in order to shorten the time needed to develop an information system. 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 estimated time to complete. In turn, this will directly impact the project’s schedule and budget.

eXtreme project management (XPM) is a new approach to project management that is becoming increasingly popular. XPM focuses on the human element of projects and embraces the reality that projects often operate in an uncertain and high-speed environment. XPM also takes a more holistic view of planning and managing projects in which changing requirements are inevitable; planning thus becomes an iterative and self-correcting process that supports innovation.

The PMBOK®Guide outlines nine knowledge areas for understanding 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 communications 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.
Review Questions

1.

Describe the EDP era in your own words.

2.

Describe the micro era in your own words.

3.

Describe the network era in your own words.

4.

Describe the globalization era in your own words.

5.

How can a value-driven approach improve the likelihood of IT project success?

6.

What is the socio-technical approach to systems development?

7.

What are the benefits of using a project management approach to developing information systems?

8.

What is a methodology? What are the advantages of following a methodology when developing an information system?

9.

How does sharing experiences in the form of lessons 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, and budget.

14.

Describe the different roles and skill sets needed for a project.

15.

Describe three risks that could be associated with an IT project.

16.

Why should assumptions associated with a project be documented?

17.

Discuss the statement: Projects operate in an environment 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 (SDLC).

22.

Describe the waterfall model for systems development. 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 development. What advantages does this model have in comparison with the waterfall model?

25.

Describe extreme programming (XP). How does XP accelerate the SDLC?

26.

Describe extreme project management. How does XPM differ from a more traditional approach to project management?

27.

What is knowledge management? Although many people believe knowledge cannot be managed, why do you think many companies are undertaking knowledge management initiatives?

28.

Although the Guide to the Project Management Body of Knowledge describes the generally accepted principles and practices of project management, why wouldn’t these principles and practices work for every project?

Extend Your Knowledge

1. 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.1 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 management initiative.

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—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 company, Tim and Kellie decided that a small, independent consulting firm could be successful 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 experience?
2. What questions would you have?
3. What might help reduce your anxiety and uncertainty as an inexperienced project manager?
4. What steps would you take to begin a new project?

Husky Air—Pilot Angels
Background

Husky Air opened for business in January 2008 when L. T. Scully and several other investors pooled their life savings and secured a rather large loan from a Chicago bank.

Located at DeKalb Taylor Municipal Airport (DKB) in DeKalb, Illinois, Husky Air is a fixed base operator (FBO) facility that offers a full range of services to the growing demands for business and private aviation. Currently, the company has 23 employees composed of pilots, mechanics, and office staff.

As a FBO, Husky Air provides:

* Business jet, propjet, helicopter, and propeller aircraft charter
* Refueling
* Airframe, engine, propeller, and avionics maintenance
* Aircraft rental
* Flight instruction
* Pilot supplies

Although FBOs at other airports offer similar services, Husky Air has been receiving increased attention throughout the Midwest for its charter service, maintenance, and flight instruction.
Pilot Angels

In addition, Husky Air coordinates a charitable service called Pilot Angels. Working with hospitals, health care agencies, and organ banks, Husky Air matches volunteer private pilots, willing to donate their time and aircraft, with needy people whose health care problems require them to travel to receive diagnostic or treatment services. In addition, Pilot Angels also will provide transportation for donor organs, supplies, and medical personnel. All flights are free of charge and the costs are paid for by the volunteer pilots who use their own aircraft.

The pilots who volunteer for the Pilot Angel program need no medical training and offer no medical assistance. The planes do not carry any medical equipment and do not have to accommodate any stretchers. Patients, however, must be medically stable and able to enter and exit the aircraft with no or little assistance. The Pilot Angel passengers typically travel to or from a hospital or clinic for diagnosis, surgery, or some other treatment. Travel companions, such as a relative, friend, or nurse, are common.

Currently, a pool of pilot volunteers is kept in a file folder. If a hospital or person with a medical or financial hardship contacts Husky Air, the name of the traveler, the destination, dates/times, and the number of travel companions are requested. Because of limited weight restrictions in small aircraft, the weights of the passengers and their luggage are needed as well.

After the initial information is provided, Husky Air contacts the volunteer pilots to determine their availability. Although a volunteer pilot may be willing and available for a Pilot Angel flight, the plane may not have the range or weight-carrying requirements. This may be an inefficient use of time since many pilots may have to be contacted until a pilot and suitable plane can be found.
The Project Description

Husky Air would like to have a computer-based system to keep track of all its Pilot Angel volunteers. Basic information about the pilots may include their name, address, phone number, and so forth, as well as their total hours, certifications, and ratings. Moreover, specific information about a volunteer’s aircraft would be useful. Such information should include the type of plane, aircraft identification number (called the N number), whether single or multi-engine, and its capacity for carrying passengers and cargo. Some pilots own more than one plane.

Husky Air also wants to know more about the people, hospitals, clinics, and organ banks who request the Pilot Angel service. In addition, they also would like basic information about the patients, their passengers, and specific needs to help match volunteers with the request for transport. Finally, Husky Air wants a list of all the Pilot Angel flights in order to recognize specific volunteers for their contributions. This would include:

* The pilot who flew the flight
* The passengers on board
* The plane that was used
* The total time of the flight
* The distance and destination of the flight
* The date and time of the flight
* The total fuel used

Husky Air Assignment
The Team Charter

Congratulations! You have been hired as a consultant to work with a new client called Husky Air. The objective of your first assignment is to organize teams for completing the various Husky Air assignments. Your instructor will either assign you to a team or allow you to select your team.

Please provide a professional-looking document that includes the following:

* Team name—You should come up with a name for your team. This will give you an identity.
* Team members—Please list the names of your team members and their phone numbers and email addresses. This will provide a directory for your team later on.
* Agreed-on meeting times—You and your team should compare schedules so that you can agree on a time or set of times that allow you to meet as a group to work on these assignments. If you discover any conflicts, you should reevaluate whether you should be a team. You may want to think about using a software collaboration tool or other available technology to help reduce the dependency on same place/same time meetings.
* A list of team rules and expectations—In the past, you probably have all worked with at least one other person. As a team, share some of those experiences and discuss whether they were positive or negative. Based on your discussion, define a set of team rules and expectations. For example, how should the team resolve conflicts? What happens if someone misses a meeting? Two meetings? Three? How will the team deal with someone who does not contribute equally? Each member of your team should agree to these rules. Do not take this lightly. You may also want to discuss and document how the team may change its charter if needed later on.
* A code of ethics—A project team has a responsibility to themselves and their client or sponsor. You may want to start by developing a list of values that you and your team members feel are important. Based on that list, create a statement or itemized list that summarizes those values to guide your team’s ethical behavior.
* Signatures—Each member of your team should sign the team charter. This will indicate that each member has read, understands, and agrees to the rules and expectations of the team.

Case Studies
Project Ocean—The Troubled Water Billing System

The city of Philadelphia entered into an agreement with Oracle Corporation to replace its antiquated, custom-built, 30-year-old water billing system that fails to collect all the revenue it should. After three years and spending $18 million on “Project Ocean,” the project was two years behind schedule and at almost twice the cost originally envisioned. Moreover, the new billing system still had not been deployed to support its 500,000 customers.

Philadelphia Chief Information Officer (CIO) Dianah Neff cited technical complexity, administrator turnover, and Oracle’s inexperience building such a system as the reasons for Project Ocean’s problems. Alan Butkovitz, the City Controller, said that his office is currently reviewing what happened with Oracle, but that it is too soon to speculate as to what went wrong with Project Ocean. An official at Oracle has said that they would deliver on their promise to complete the project and that implementation is “still in progress, and Oracle believes that the work performed to date conforms with the current agreement.”

Project Ocean is currently on hold until the Mayor’s Office of Information Services (MOIS) and other city officials can reach an agreement with Oracle to put Project Ocean back on track. Neff stated that she believes a workable solution can be delivered within 18 months to protect the city’s investment.

Former City Water Commissioner Kumar Kishinchand was a vocal critic of Project Ocean since before leaving the commission after 12 years. Kishinchand believes that Project Ocean was doomed from the start. “One reason is that they picked a company that had never done a water billing system. Oracle had only done viable customer service systems with a small portion for billing purposes. Municipal billing systems tend to be tremendously complex. The off-the-shelf components of such systems have to be heavily modified, a complex and time-consuming effort.”

Kishinchand also believes that the project managers did not have much to lose if Project Ocean failed because the city’s Finance Department was in charge of the project—not the Water Department, which is the main operator and user of the system. He believes that Neff and the MOIS were interested in building empires because the water billing system takes in over $300 million in revenues a year. Kinshinchand also accused city officials of “putting all of their eggs in one basket [Oracle], without consulting the Water Department.”

In rebuttal, Neff contends that MOIS chose the Oracle Enterprise Resources Planning E-Business suite for a number of city uses that include human resources and that the Finance Department made the decision to make water billing the first application. MOIS was then brought in to implement the system once the decision was made. As Neff contends, “it [the water billing system] was a big system, very complicated with very unique features. Hindsight is 20/20 and ERP is difficult anyway.”

In addition, the system was designed to be run by a number of city departments, but there was constant turnover among executive sponsors. Neff contemplated “Continuity was a problem, and we could have had better-defined business processes. Problems came up between the contractor and business people. As we put it, it was a project that ‘washed ashore’ for IT to handle.”

About 12 months ago, MOIS was assigned to review the work completed on Project Ocean so far. This led to a work stoppage and the suspension of several consultants, Oracle employees, and a private contractor who had been indicted by a federal grand jury in Connecticut on unrelated charges that she had paid a state senator to help her win consulting contracts.

While negotiations between the city of Philadelphia and Oracle continue, Neff is preparing to start a new job as a consultant in another city. After five years as CIO, Neff maintains that her impending departure is unrelated to Project Ocean.

1. Do you believe that the trouble with Philadelphia’s water billing system is a technical problem or a people problem? Why?
2. What factors contributed to the problems associated with Project Ocean?
3. Compare the different views the city’s MOIS and Oracle may have when negotiating a new agreement that will continue that project.
4. Can this project be saved? If so, what should the new agreement include? If not, can Philadelphia and Oracle come to an agreement that satisfies both parties? Or would this end up being a “win/lose” situation?

SOURCE: Adapted From Matt Hamblen, Philly CIO: Troubled Water Billing System Can Still Work, Computerworld, August 10, 2006.
The FBI’s Virtual Case File

After the tragic events of September 11, 2001, the Federal Bureau of Investigation (FBI) recognized the need to modernize its largely paper-based system for gathering intelligence. After years of developing information systems without an overarching organizational view, the agency found itself with an “improvised” IT infrastructure with more than 50 independent application systems written in different programming languages and running on disparate platforms. The result was a shortfall of knowledge management that became even more apparent after September 11th. The FBI concluded that it was losing intelligence as fast as it could gather it.

Robert Chiaradio, an agent in charge of the field office in Tampa, Florida, was requested by FBI Director Robert Mueller to help push a three-part modernization project called Trilogy that was started by former Director Louis Freeh. The project centered on upgrading the agency’s desktops and servers, Web-enabling a number of the most important investigative database systems, and, most importantly, an automated case file system.

As the new CIO, Chiaradio was in charge of the entire IT operation for the Bureau, and one of four officials who reported to Mueller. Recognizing that there was no time to waste, Mueller instructed that the year schedule for the project had to be put into overdrive so that the Trilogy project could completed “as soon as technically possible.” After a meeting at 6:00 AM on October 1, 2001, Chiaradio quickly developed the concept for the Virtual Case File system.

The Virtual Case File was envisioned to help FBI agents efficiently share data about cases in progress, especially terrorist investigations. The system would also enable agents anywhere in the United State quickly to search various documents and allow them to connect possible leads from different sources. In addition, the Virtual Case File would include a case management system, an evidence management system, and a records management system. The intention was to eliminate the need for FBI employees to scan hard-copy documents into computer files. A custom-developed system was needed since no existing commercial software packages were available that meet the agency’s needs when the project began in 2001. Development of the Trilogy Project was contracted to Science Applications International Corp. (SAIC) in San Diego, California and was to be completed by late 2003.

After 18 months, Robert Chiaradio left the FBI to take a new position as managing director of homeland security at BearingPoint Inc. in McLean, Virginia. By the end of 2004, SAIC had delivered only about 10 percent of what the FBI had envisioned and didn’t include many of the enhancements that were recommended by a second contractor.

In January 2005, the FBI was faced trying to salvage the $170 million project and appease a growing number of critics who believed that the four-year-old project was a waste of taxpayer money. Moreover, Robert Mueller confided to reporters that while the Virtual Case File project has not been scrapped, the FBI has asked another contractor to look for commercial or government off-the-shelf software packages that could be used instead.

The project’s lack of progress drew public criticism from Senator Patrick Leahy (D-Vt.), who said “the FBI’s long-anticipated Virtual Case File has been a train wreck in slow motion, at a cost of $170 million to American taxpayers and an unknown cost to public safety.” To the contrary, Duane Andrews, SAIC’s chief operating officer, said “The FBI modernization effort involved a massive technological and cultural change, agency wide. To add to that complexity, in the time that SAIC has been working on the Trilogy project, the FBI has had four different CIOs and 14 different managers. Establishing and setting system requirements in this environment has been incredibly challenging.”

One FBI official remarked that this experience has led to a number of lessons learned in contract management, and this particular contract has led the agency to change its IT contracting practices and develop an IT roadmap. The official also added, “It’s definitely not fair to say we haven’t gotten anyplace. We haven’t gotten the overarching program we wanted, but we’re going to take these lessons and move forward with it.”

In March 2005, the FBI officially terminated the Virtual Case File and announced that it would develop a new case management system called Sentinel. This announcement was made by Robert Mueller during his testimony before a subcommittee of the U.S. House Appropriations Committee. Mueller said “I am disappointed that we did not come through with Virtual Case File.” However, he added that he sees the decision to cancel the project as an opportunity to use off-the-shelf software to create a more up-to-date system that will allow FBI agents to share information about cases more easily.

An FBI official who wished to remain anonymous said that agency will begin to evaluate software packages next month in order to develop a more firm direction. In addition, the FBI will be conducting a test of SAIC’s most recent version of the system. Although the system developed by SAIC does not meet the agency’s requirements, “we needed to evaluate what they had given us as far as user capability and usability” was concerned.

Interestingly, Jared Adams, a spokesman for SAIC, contends that the FBI hasn’t formally killed the Virtual Case File project. Ongoing tests are proof that a final decision has not yet been made. He added, “When the tests are done at the end of March, I think then a decision will be made.”

Robert Mueller stated that the new case management system will be implemented in four phases and should take about 39 months to complete. He was unwilling, however, to estimate how much the new system will cost.

The House Appropriations Committee said that it would open a formal investigation as to why the project failed.

1.

A Computerworld article by Paul Glen1 lists a number of ways to detect disaster projects. Discuss how the following may apply to the FBI’s failed Virtual Case File.

1From Paul Glen, Opinion: Detecting Disaster Projects, Computerworld, February 06, 2006.

1. No real plan—No baseline to work from, so no one really knows that a project is late.
2. Excessive optimism—Many times there’s a perpetual optimism that just because a project is behind there’s no reason why things can’t get caught up.
3. Fear of admission—When a project is in trouble, no one wants to go to senior management and admit it, because that may be uncomfortable. And maybe things will get better.
4. Poor team morale—Although this may not be a leading cause of project failure, it may be a leading indicator.
5. Poorly understood team roles—People may not be clear as to what their role should be or how they should be interacting with others.
6. Absent sponsors—If sponsors can’t be bothered with investing time in the project up front, chances are they won’t like what they get in the end.
7. Not enough methodology—If the project team doesn’t have a common and well understood approach to completing the work, it is likely to have trouble doing so.
8. Too much methodology—A methodology is a tool for completing the work, but not a guarantee that everything will go smoothly. A team can become overburdened with a methodology where the means become more important than the ends, or become a process to further political goals.
9. Meager management—An inexperienced or unskilled manager can doom a project to failure.
10. Lacking leadership—Good leadership may be difficult to define, but we often know it when we see it. A project must have good leadership to succeed.
11. Inadequate technical skills—While not the most common cause for project failure, it can happen if we assign people to projects without the requisite skills, or training, or when we assign people because they are available at the time.
12. Too many meetings—Project team members who spend an inordinate amount of time in meetings may be trying to make up for inadequate planning. Since they may not have thought things out in advance, they are forced to coordinate on the fly.

SOURCE: Adapted from:

Dan Verton, FBI Has Made Major Progress, Former IT Chief Says, Computerworld, April 18, 2004.

Grant Gross, FBI Trying to Salvage $170 million Software Package: Its Virtual Case File Project is under Fire for Not Working as Planned, Computerworld, January 14, 2005.

Linda Rosencrance, FBI Scuttles $170 million System for Managing Investigations, Computerworld, March 14, 2005.

Frank Hayes, FBI on the Move, Computerworld, May 30, 2005.
Bibliography

Boehm, B. W. 1988. A Spiral Model of Software Development and Enhancement. Computer (May): 61–72.

DeCarlo, D. 2004. eXtreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility. San Francisco: Jossey-Bass.

Dennis, A. and W. B. Haley. 2000. Systems Analysis and Design: An Applied Approach. New York: John Wiley.

Friedman, T. L. 2007. The World Is Flat: A Brief History of the Twenty-first Century. New York: Picador.

Gido, J. and J. P. Clements. 1999. Successful Project Management. Cincinnati, OH: South-Western College Publishing.

Glass, R. L. 2005. IT Failure Rates—70% or 10–15%? IEEE Software (May/June): 109–112.

Hoffman, T. and J. King. 2000. Y2K Freeze Melts in January Thaw. Computerworld, 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 Wild Software Schedules. Redmond, WA: Microsoft Press.

Meredith, J. R. and S. J. Mantel, Jr. 2000. Project Management: A Managerial Approach. New York: John Wiley.

Marchewka, J. T. 2007. An application of the deming management model for information technology projects. Journal of International Technology and Information Management 16(2) 57–71.

NASA. 2004. http://web.archive.org/web/20040403211247/http://asdwww.larc.nasa.gov/barkstrom/public/The_Standard_Waterfall_Model_For_Systems_Development.htm

Nolan, R. L. 2001. Information Technology Management from 1960–2000. Harvard Business School. June 7.9-301-147.

Project Management Institute (PMI). 2004. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Newtown Square, PA: PMI Publishing.

Rosencrance, L. 2007. Survey: Poor Communciation Causes Most IT Project Failures. Computerworld (March 9). http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9012758.

Rosenau, M. D. J. 1998. Successful Project Management. New York: John Wiley.

Satzinger, J. W., R. B. Jackson, and S. D. Burd. 2002. Systems Analysis and Design in a Changing World. Boston: Course Technology.

Standish Group. 1995. CHAOS. West Yarmouth, MA: The Standish Group.

Tata. 2007. http://www.tcs.com/AboutUs/Research_survey.html

Zuboff, S. 1988. In the Age of the Smart Machine: The Future of Work and Power. New York: Basic Books.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License