About the Authors

Cynthia Snyder, PMP, MBA, is a professional project management consultant, instructor, and author. She provides consulting and training services to government and private industry. Her consulting focuses on project management maturity, PMO startups, and positioning project management as a core competency for organizations.

Cyndi has experience in training in the corporate, public, and academic environment. Clients have included IBM, Kaiser, Toyota, and Southern California Edison. In an academic environment, she has taught online and in the classroom for UC Irvine, CalTech, and USC.

She has written two books on project management and has been the technical editor on many others.

Cyndi is an active volunteer with the Project Management Institute. She is the project manager for the 2008 editions of the PMBOK^® Guide and the Standard for Program Management. In the past she has served on the Standards Member Advisory Group and was Chair of the Chapter Leadership Development and Excellence Committee for 2003–2005. She was President of the PMI^® Orange County Chapter for 2001 and 2002. In 2002 she received the award for Outstanding Chapter President of the Year. Cyndi is a certified Project Management Professional (PMP) and earned her master’s in business administration from Pepperdine University.

Frank Parth, MS, MSSM, MBA, PMP, is the President of Project Auditors, LLC, a project management consulting, training, and auditing company. After ending a career in aerospace as the assistant technical director on a $12 billion satellite program, he branched out in 1993 and began consulting in technology management to major U.S. companies, national governments, and the U.N. He was CTO for a small but successful e-commerce company, headed up systems engineering at TRW Information Systems during a major infrastructure upgrade, and created PMOs for several major corporations. He taught systems analysis and management at the Graduate School at the University of Southern California, has been an instructor at the University of California, Irvine PM Certificate program since 1994, and has taught at the Claremont Graduate School. Mr. Parth has undergraduate and graduate degrees in physics, a master’s in systems management from USC, and an MBA from the Peter F. Drucker Graduate School of Management. He has published numerous papers on project management and systems engineering and is an international speaker. He has been in Who’s Who in the United States and Who’s Who in the World for many years. He is active in PMI^®, serving on various committees both at the local and at the national level and is the 2006 Chair for PMI’s Consulting SIG.

1 Projects and Operations

After reading this chapter, you will be able to:

•  Define how projects and operations are different.

•  Describe how IT projects differ from non-IT projects.

•  Explain the value of project management for IT projects.

•  Define key terms in project management.

Welcome to the world of information technology project management. In reading this book, you will find that managing IT projects can be highly rewarding and, often, equally frustrating. You will discover that project team members, project customers, and other project stakeholders can be very easy to work with and at the same time can be very challenging. It is not uncommon in project management to get a high-priority project from upper management one week and then find the next week that things have changed and a new project is the number one priority. You will almost never have enough resources to do the work and never have enough time to produce the best product possible. You will be told not to spend time planning the project but to just begin working, and you won’t have enough time to gather the user requirements before you need to start development. Your resources will be working on three other projects as well as normal daily operations, while you’re trying to get them to work on your project.

However, when the project is over you will have produced something that makes work easier for the other people in your organization, saves your organization a significant amount of money, keeps private data secure, or upgrades a legacy system into something much more effective and efficient. When all the work of the project is over, you will have made a real contribution to the organization.

WHAT IS PROJECT MANAGEMENT?

Project management is the application of skills, knowledge, and abilities to produce a unique product, service, or result. Three components that lead to successful projects are technical knowledge, general management abilities, and project management skills.

The project manager must have knowledge of the technical aspects of the project. Although some will debate this point, in IT projects particularly the project manager needs to know enough to detect when something is amiss and to understand the general principles of the project. He or she certainly does not need to be a subject matter expert in every facet, but some amount of knowledge is a necessity.

The project manager also needs some capability in the area of general management, including skills in budgeting, analysis, planning, and coordinating. Finally, the project manager must apply project management skills, tools, and techniques to make the project a success. This book focuses on the project management component while referencing technical knowledge and some general management abilities (see Figure 1-1).

Managing IT projects is similar to managing other types of projects, such as projects in the fields of construction and pharmaceutical development. However, IT project management has unique aspects, including:

•  Technical projects require team members with specific technical skills.

•  For small projects, team members are typically working on multiple projects at the same time.

•  Most team members have operational responsibilities as well as project responsibilities.

•  Larger IT projects tend to form the very infrastructure of the organization, and failure can cost millions of dollars.

•  Because of the pervasiveness of information systems, a simple IT project may become complex because of the number of other systems it touches.

•  Technology is evolving so rapidly that software and hardware are almost always out-of-date before they are deployed.

•  Technology requires continual upgrading, maintenance, and improvement.

•  The changing nature of technology can make it difficult to estimate accurately or to learn from previous projects.

The differences inherent in IT projects create a need for specialized approaches to manage IT projects effectively. The basic methodology of project management continually advances as we learn what works under what conditions and what does not work. Although it is tempting to use a recipe approach to managing IT projects, the reality is that each organization must start with the basic principles of project management—which are presented in this book—and develop a detailed approach that works for its organizational structure, culture, and environment.

Project management practices and methods are evolving. As organizations change and evolve, the approaches needed to effectively manage projects also change and evolve. The largest professional organization dedicated to project management is the Project Management Institute (PMI^®) with over 200,000 members worldwide at the time this book was written. PMI’s book A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) was developed by practicing project managers, and it is the American national standard for project management. ¹ This guide is continually evolving as new approaches and new practices are integrated into project management. However, it is not the only approach to managing IT projects. An approach called Projects in Controlled Environments (PRINCE2) was developed by the IT Directorate of the British Government. PRINCE2 places a heavy emphasis on creating a strong business case for IT projects and continually monitoring the project against the business case. The Information Systems Audit and Control Association (ISACA) has developed Control Objectives for Information and Related Technology (CoBIT), which emphasizes controlling and auditing IT projects.

WHY USE PROJECT MANAGEMENT?

Why are there so many approaches to managing IT projects? Because the failure rate of IT development work is high. The baseline study of IT project success is the CHAOS Report released by the Standish Group in 1995. ² This report showed that 31 percent of projects were canceled before completion and 52.7 percent of projects cost over 189 percent of their original estimates.

Based on this research, the Standish Group estimated that in 1995 American companies and government agencies spent $81 billion for canceled software projects and had to pay an additional $59 billion for software projects that exceeded their planned schedules. It estimated that almost 80,000 projects were cancelled in 1995. Although large IT projects are always risky, many of these projects were as straightforward as a drivers’ license database, a new accounting package, or an order entry system. This book will help you understand the unique aspects of managing IT projects and how to improve the success rate of your projects significantly.

This book is about how to manage IT projects. It is not a book on software project management and it is not a book on implementing enterprise-wide software applications. It is not a book on how to manage local area network (LAN) design and installation. All of these are types of IT projects, but IT is a much broader field than any one of those areas. We will use a working definition that IT project management is about managing projects where a significant portion of the product or result is dependent on some aspect of information technology. This book will give you a strong start towards managing those projects.

HOW IS PROJECT MANAGEMENT DIFFERENT FROM OPERATIONAL MANAGEMENT?

When most of us consider an organization, we think of a hierarchical assortment of departments that collectively produce some type of product or service. Most organizations have a marketing department, a finance department, a human resources department, some type of production or manufacturing department, and, of course, an IT department. These departments work more or less collaboratively to create something of value that the organization provides to its customers in order to sustain the organization. In the world of operations management, departments work towards company objectives.

For example, in operations management the goal could be to produce and sell the best widget for the least amount of money and to sustain those operations. At that point, production becomes repetitive and static. However, projects are not repetitive; projects are one-time events designed to produce specific results and then to end. The PMBOK^® Guide defines a project as a temporary endeavor undertaken to create a unique product, service, or result. ³

Although departmental operations tend to focus on the objectives that each department is working to achieve, projects focus on a client or business objective. Operations management is concerned primarily with keeping the lights on and ensuring that the company continues and grows. Projects produce a specific deliverable and then dissolve.

The structure of management is also different. Operational departments have managers and staff assigned full-time with well-established roles, responsibilities, and authority. Projects are temporary in nature; the project manager and team members are brought together for a short period, complete the work, and then disband. The project may be comprised of people at varying levels of skill, responsibility, and authority. Depending on the organization, project managers may have full authority or very little authority when it comes to making decisions and managing people and budgets. Although their level of authority varies, their level of responsibility does not—they are always fully accountable for bringing the project in on time and on budget and for satisfying all the requirements.

For projects, time, budget, and scope are constraints—limitations within which the project manager must work. By comparison, in production environments these constraints are incorporated into the process. For example, a production line produces 750 widgets each day, the staffing is sufficient to manufacture the widget, and material costs are negotiated upfront with a fixed percentage factored in for rework or failure.

Table 1-1 summarizes some of the primary differences between projects and ongoing operations.

Although this is a somewhat simplified version of operations, you can see that managing an outcome in the world of project management can be much more challenging than managing an outcome in an operations environment.

SUCCESSFUL PROJECT MANAGEMENT

Now that we have provided a summary definition of successful projects and project management, let’s take a closer look at project management. Project management includes identifying requirements; establishing clear and achievable objectives; balancing demands for quality, scope, time, and cost; and adapting the specifications, plans, and approach to the needs and concerns of various stakeholders. But this is just one aspect of what it takes to call the project a success.

Projects are usually performed by a team rather than by just one person, so a major component of being a successful project manager is managing people to achieve the project goals. Many new project managers mistakenly think that project management is just another task to be done on top of developing the product. As an IT project manager, you are primarily responsible for ensuring the work is done, not for doing it yourself. This is a difficult transition for many technical people to make. You are a manager now, not a technical person doing coding or designing a LAN.

Another common misconception is that if you have Microsoft Project or some other project software you can manage a project. There is an old saying in project management that having a copy of MS Project makes you a project manager to the same extent that having a copy of MS Word makes you an author. Managing schedules and using software are pieces of project management, but certainly do not, by themselves, lead to successful projects.

One of the most challenging jobs a project manager faces is defining and balancing the expectations of project stakeholders. If you meet the scope of the project, on time and within budget, but the customer is not satisfied, the project is not a success. Additionally, even if the customer is satisfied, if the project team is burned out—or worse, feels abused—the project should not be considered a success. One criteria of success can be whether the team would want to work with the project manager again. If the answer is no, then the project manager did not successfully manage the team.

So then, what is a successful project? One view says that a project is successful when all stakeholders are satisfied. For the most part that means that the customer’s requirements were met in a timely fashion for the agreed upon budget. However, it also means that the project is a strategic success, is consistent with the organization’s strategy (more on this in a later chapter), and meets the needs for which it was undertaken. It also means that the team members are satisfied. Sometimes the biggest challenge is how to meet tight deadlines without creating team burnout. Figure 1-2 shows the project management balancing act.

PROGRAMS AND PORTFOLIOS

Although this book will focus on projects and project management, understanding the context of projects in the bigger picture is useful. Some organizations do projects (sometimes many projects) that too often are not organized or prioritized in any particular manner. The entire suite of projects within a company or department is called the project portfolio.

Earlier we defined a project as a temporary endeavor undertaken to create a unique product or service. Some projects are so large that they have to be subdivided into multiple projects, each of which contributes to the accomplishment of the larger project. A project that consists of subprojects is called a program. Each of the smaller projects is managed separately, but all of them have goals that support the program. An example of a program is a large corporate initiative such as installing an enterprise resource planning (ERP) system. Each department affected by this program may have a series of projects related to the program, such as requirements definition, process engineering, identifying the business rules, and so on.

A project portfolio is a collection of projects and/or programs managed as a single group to support organizational or departmental goals. The projects in a portfolio may be related, such as a portfolio of defense programs and projects or a portfolio of commercial programs and projects. They may be unrelated, such as when a portfolio is managed to ensure the proper balance among infrastructure projects, security projects, and business development projects. Figure 1-3 shows a possible project portfolio composed of various projects and programs.

A BRIEF HISTORY OF IT PROJECT MANAGEMENT

Modern project management traces its roots back to the late 1950s when the Project Evaluation and Review Technique (PERT) and the Critical Path Method (CPM) were developed. These methods were created to handle projects that were growing increasingly complex. PERT was developed and used in the defense field and CPM in the construction field.

Projects from both of these fields shared common characteristics: they were large and complex, had significant technical risk associated with them, and had dedicated project managers and dedicated project teams. This environment existed for more than 20 years, and it worked very well. NASA’s ability to develop large, complex, risky rockets and manned space systems under tight schedules during the 1960s was due to its strong project management skills.

Electrical machines have been able to perform calculations since the first large computer was wired together by hand. As mainframe computers grew, the field of software engineering also grew, and much of the development took place under government funding by NASA and the military. However, often these programming efforts were not managed as separate projects but as subsets of large programs. It was not until early in the 1980s that the practice of managing software development as a separate project began to mature in private industry. This development occurred as commercial applications grew in size and complexity.

For commercial applications, speed to market was the key to success and shortcuts, especially in testing, were common. The term vaporware began to appear as companies made promises about upcoming software to reduce sales to competitors. Over the course of the 1980s and 1990s, software grew increasingly large and complex, but speed to market remained the project driver. The need to balance the scope of the project against the time to market and to do so without bankrupting the company created the perfect environment for project management.

CHALLENGES OF IT PROJECTS

Unlike the staff of traditional projects, where the team forms, develops, and releases the product, then dissolves and never interacts with the product again, IT people develop the product and, quite often, they maintain it after implementation (for internal IT projects) or fix problems that users identify. As a result, their time is split between daily operations and working on projects. This almost always leads to problems in prioritizing the work and in scheduling projects, since the availability of the resources is not known

Additionally, IT projects are usually much shorter in duration, with schedules measured in weeks or months rather than in months or years (the keyword is usually). IT projects have to share resources both with daily operations and with other projects. Working on multiple projects is a fact of life in the IT world, and being dedicated to a single project is a luxury for an IT project manager. Because IT projects tend to be shorter in duration than other types of projects, there is no ability to do traditional project team development.

Short timeframes and use of shared resources affect how IT projects are managed in a number of ways. Because daily operations have, or should have, priority, predicting exactly how much time each week is available for project work is difficult. Because people are working on multiple efforts, there is measurable reduction in productivity as team members jump from one effort to another. The daily schedules of many people are often driven by whoever talked to them last and asked when a particular project was going to be done.

Technology itself is a factor. Constantly increasing capabilities in both hardware and software pressure IT to incorporate the latest and greatest computer equipment.

Do these problems have solutions? Yes. A strong project management culture in the organization and a good project selection and prioritization process will help tremendously. We will talk about these solutions in the next chapters.

Table 1-2 summarizes the differences between non-technical projects and IT projects.

THE VALUE OF IT PROJECT MANAGEMENT

Now that we have shown how projects are different from operations and how IT project management is different from non-technical project management, let’s look at the value that IT project management provides to organizations. The Center for Business Practices does research and benchmarking and provides publications on project management and business practices. It performed a study with senior IT project management practitioners and found that using project management practices produced superior results compared to not using formalized project management practices. ⁶ The results were particularly compelling in the areas of time to market, customer satisfaction, alignment to strategic goals, and meeting time, budget, and quality objectives.

In fact, 97.7 percent of the organizations surveyed said that implementing project management has added value to their IT organization. (Visit www.cbponline.comfor more information.)

Earlier in this chapter, we mentioned the CHAOS Report from 1995. A more recent version shows that from 1995 to 2001, cost overruns decreased from 189 percent to 45 percent. Time overruns decreased from 222 percent to 63 percent.(For more information on the CHAOS Report, visit www.standishgroup.com.)

There are many reasons for this improvement. The most prominent are:

•  Projects are smaller in scope.

•  Projects are broken into discrete phases that are managed as separate projects, allowing subsequent phases to learn from previous ones.

•  Better tools exist to estimate, monitor, and control project work. These allow better estimates upfront and allow project managers to detect baseline variations while there is still time to correct them.

•  Having skilled project managers and better project management processes can significantly improve project success rates.

CHAPTER SUMMARY

•  Projects are one-time unique endeavors with defined starts and finishes. They are customer focused, have project managers with varying levels of authority, and use a temporary project team. Projects have scope, time, and cost constraints, and scope may evolve as the work is elaborated. Projects may be complex, involve outside stakeholders, and generally have more risk than operations.

•  Operations are ongoing, standardized, and repetitive. The focus is on the goals of the department. Operations have a functional manager with full authority over permanent dedicated staff. Departments have established objectives, and constraints have been factored into the processes. Most risks have been accommodated or eliminated over time.

•  A successful project is one that meets the triple constraints of scope, schedule, and cost. However, to be a success the project must be a strategic success, meeting the needs it was undertaken to address. Also, the team members should be satisfied with working on the project.

•  IT projects are different from non-technical projects because the IT project team is usually working on several projects at one time as well as maintaining operations. The time span is shorter and priorities tend to shift. In technical projects, the technology itself is often a risk, and the risk on each project is different. Projects are shorter in duration, and there is no time for team development.

•  Studies have shown that the use of project management increases customer satisfaction, quality, time and cost performance, alignment with strategic goals, and time to market. Significant improvements in project success have been made over the past ten years due to smaller projects; improvement in estimating, monitoring, and controlling processes; and improvement in project management skills and processes.

Key Terms

Project	Program
Project management	Project Portfolio

Key Term Quiz

Use terms from the key terms list to complete the sentences that follow. Don’t use the same term more than once.

1. A ______________ is a temporary endeavor undertaken to produce a unique product, service, or result.

2. A ______________ is group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually.

3. The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements is known as ______________

4. The term for a collection of projects and/or programs and other work grouped together to facilitate effective management of that work to meet strategic business objectives is ______________.

Review Questions

1. What three constraints do projects have?

2. Do project managers have full authority over the resources on their projects?

3. List three components that make projects different from regular operations.

4. What makes a project successful?

5. Compare projects, programs, and portfolios

6. Describe three differences between IT projects and non-technical projects.

7. Studies have shown that using project management practices brings about improvement in many areas. Which five areas showed the most improvement according to the Center for Business Practices?

8. Which of the following is an example of a project?

a. Month-end closing of the books

b. Producing 1,000 widgets

c. Shutting down production for retooling

d. Researching a new product on the market

9. An IT applications director can categorize the projects in his or her shop as maintenance, new technology, upgrades and new releases, and business support. There may be many separate projects in each of these categories at any given time. However, each category is managed collectively in order to balance resources and smooth the schedule. This is an example of:

a. Schedule-constrained allocation

b. A portfolio of projects

c. A superorganized director

d. Project management