THE CHALLENGE OF MANAGING PROJECTS

Work that is unique and temporary requires different management disciplines. Because projects have different characteristics than ongoing operations, they pose a brand‐new set of challenges. Here are some of the challenges that face project managers:

• Personnel. Every project has different personnel needs. The number of people needed and their different skill sets are different for each project. Where do these people come from? Where do they go, once they are no longer needed? These staffing problems may be compounded if several projects are running simultaneously. If all projects hit their resource peak at the same time, it could place an impossible burden on an organization. And if all the projects should end around the same time, the company may be forced into layoffs.
• Estimating. In order to evaluate potential projects, organizations need accurate estimates of costs and schedules. But because each project is different, estimates may contain more assumptions than facts.
• Authority. Organization charts define authority within a firm, but they usually represent the ongoing operations of the firm. When projects cross organizational boundaries, it is no longer clear who has authority for many decisions. This can lead to political maneuvering and a gridlock that blocks progress.
• Controls. Normal accounting practices match operational budgets to operational costs on a quarterly or an annual basis. But these time frames are not sufficient to keep a project on track. By the time quarterly accounting reports show a project to be over budget, it may be so far out of control that it's beyond recovery.

This list of difficulties and challenges could go on, but it should be clear by now that managing projects is not the same as managing ongoing operations. Notice that this does not mean project management is more difficult than managing ongoing operations—only that managing projects presents a different set of challenges.

The project management techniques within this book have evolved to meet these challenges. As you progress through the book, you can review this list of problems to see just how the tools and techniques you are learning address each one.

Clearly, projects and ongoing operations overlap and interact. Projects initiate or change ongoing operations. At times, projects exist within an ongoing operation, while at other times the reverse is true. Both may be funded out of the same budget process and use many of the same people. Both require a wide range of the same management skills: written and oral communication, conflict resolution, motivation, accounting, and negotiating, to name just a few.

But these similarities can obscure the real differences between projects and ongoing operations. Recognizing these differences leads to a better understanding of their different challenges. Projects, as we have seen in the preceding section, have unique problems that require different management disciplines. Project managers must learn these disciplines to become effective leaders.

THE EVOLUTION OF A DISCIPLINE

If one of you decides to build a tower, will he not first sit down and calculate the outlay to see if he has enough money to complete the project? He will do that for fear of laying the foundation and then not being able to complete the work.

—Luke 14:28–29

From the time humans first worked together to build a shelter or cultivate a crop, there have been projects and project management. Yet it has been only since World War II that a formal project management discipline has emerged. During and immediately after the war, the U.S. government was engaged in enormous weapons development projects. The Manhattan Project, in which the first atomic bomb was designed and built, is generally recognized as the first project to use modern project management techniques.

Subsequent government initiatives to build nuclear‐powered submarines and warships required so much innovation and invention and were so hugely expensive that they could not be governed by existing management techniques. The first modern project management methods were constructed to deal with these enormous projects. Their names—program evaluation and review technique (PERT) and critical path method (CPM)—are still well known today.

Understanding the development of project management as a discipline can lend insight into its role in the world today. Before World War II, project management was considered a subset of technical knowledge. For example, John Roebling, who conceived and led the building of the Brooklyn Bridge with his son, Washington, was a civil engineer who pioneered the building of suspension bridges with steel cables. But even though Roebling was known as a great civil engineer, his triumphs building this and other bridges were due at least as much to his management skills. Similarly, Michelangelo, the architect of Saint Peter's Basilica in Rome, also managed the project, which included tasks such as wrangling with the popes over finances. Even today, as project management gains recognition as an independent discipline, it is still common to view it as the rightful domain of the lead technician, whether this individual is an engineer, an accountant, or a physician.

The experience of the U.S. government with the aforementioned atomic and nuclear projects began to change this notion. Because there were so many facets to these giant projects, no one person could be responsible for all the technical decisions. Bottlenecks involving coordination and communication began to restrict progress. In addition, Congress demanded some accounting of the enormous amounts of money pouring into these programs. This crucible of change forged the first formal management procedures for planning and managing projects. Even though expert knowledge of nuclear physics or submarine warfare was still necessary, the managers of these projects were no longer required to be the leading experts in their field.

Since then, the U.S. government has been a leader in developing and promoting project management techniques, for the very good reason that these techniques continue to be necessary to manage its huge defense, space, and civil projects.

Despite its long history, project management has only enjoyed widespread recognition since the mid‐1990s. At that time it became a central focus of improving information technology projects and was embraced by the telecommunications industry, which was convulsed by changes that included the explosion of cellular telephone technology. The focus on excellence in project management quickly evolved to include multi‐project management, giving rise to the project management office (PMO).

Project management has rapidly evolved from an unacknowledged skill set into a recognized profession, complete with academic degrees and certifications. But one key question remains: Is project management a set of knowledge and techniques that can be understood and applied independent of a technical specialty? To what degree is technical knowledge required to effectively lead a project? Could John Roebling have designed the Brooklyn Bridge and then employed a project manager with no engineering skills to complete it?

Project Management Is Industry‐Independent—Project Managers Are Not

The popularity of project management in recent years owes much to its ability to transcend boundaries. The techniques put forth in this book can be applied to projects in any industry. From Silicon Valley to Broadway, projects of every size are becoming more efficient, and their products are improving in quality, thanks to the use of solid project management methods.

This industry independence has been a major factor in the development of project management as a discipline, but that independence doesn't extend to the people practicing the discipline. Project managers must not only know how to operate in business and project environments, they must also be well acquainted with the focus of the project. Specifically, project managers require skills in three different areas:

1. Project management. This is the pure discipline described in this book.
2. Business management. Negotiating, finance, customer recruitment, organizational development, communication, and motivation are skills that any good manager should have, whether managing projects or operations.
3. Technical. Nearly every company that has developed a career path for project managers begins the path with technical competence. Whether it's accounting, advertising, computer chips, or oil pipelines, the person leading the work needs to know it thoroughly. These same career paths, however, don't require candidates for project lead roles to be the best technicians in the group.

Project managers are more likely to be involved in technical decisions on small projects, but even on large programs, managers need to understand the work being performed. If they don't, they might be able to act as facilitator, catalyst, motivator, and cheerleader, but they won't be able to understand or participate in technical problem‐solving. “Good,” you might be thinking. “I don't want to be involved in the detail work.” But project managers who don't understand the technology they are managing can lose the confidence of their teams, particularly teams that are proud of their technical ability.

It makes sense that the best project managers bring a mix of skills to their job, and that the larger the project, the more project management skills are required. But even the leader of a one‐person project needs to be able to organize work and communicate clearly with customers and management. Figure 3.1 uses a three‐axis graph to illustrate how the project environment dictates different skill requirements for project managers.

Perhaps the best proof that management theory is portable comes from the companies that work with the discipline the most—that is, the project management consulting firms. These firms work effectively in all industries, not by having all the right answers, but by having all the right questions. Bring them in to kick off a project and they'll focus your team on the key issues, help you to perform risk assessments, and build project plans. Throughout this process, however, they will be acting as a catalyst and facilitator—not as a decision maker. The decisions will be made by the project manager with the help of their team, because they are the ones who possess the technical skills demanded by the specific project.

Project management is industry‐independent—the theory works in all kinds of industries. But project managers are not industry‐independent—they must have good technical skills in their field.

THE DEFINITION OF PROJECT SUCCESS

Each project is initiated in order to make an important change for the organization. Whether that change is actually valuable can be understood through the success criteria of time, budget, and scope.

• On time. The product is delivered according to schedule. Some projects are essentially worthless if they aren't on time. For example, the information technology (IT) infrastructure required to operate the Olympic Games is no good if it's not ready until after the games are complete.
• On budget. The project meets forecasted cost estimates. Projects are investments, and those that run over budget can end up costing the organization more than they bring in.
• On scope. The outcome of the project that the customer expects to receive. Setting the scope target is far more difficult to measure than on time or on budget. The customer expects a deliverable that will fulfill a purpose, that delivers the value envisioned when the project was launched. Scope targets are set with requirements. Here are a few examples:
  • Business requirements. What the product is supposed to do. How many people will the airplane carry? How many operating rooms will be in the hospital wing? What features will the website have?
  • Performance requirements. A measure of how well the functionality works. For example, compare the audio systems in a luxury sedan and an economy car. Both can connect wirelessly to your phone's music (a feature), but one probably sounds a lot better.

The Cost‐Schedule‐Scope Equilibrium

Cost, schedule, and scope are the three primary variables of a project. Change one or more of these variables, and the ones remaining will also be changed. For example, if the amounts of time and money available for a project are reduced, this will almost certainly limit the scope of the product. Similarly, to deliver the same scope in a shorter period will cost more. This relationship also leads to the term triple‐constraint. Your challenge, as a project manager, is to balance these variables to create the optimal cost‐schedule‐scope equilibrium.

To add complexity to this equilibrium, the term scope has another dimension. Product scope, as described above, is what will be delivered. Project scope is all the work required to satisfy the project objectives. For example, if the product scope in an elaborate hotel lobby includes a chandelier, the work related to hanging that chandelier will change depending on the height of the ceiling. It could take twice as much effort to hang the same chandelier in one location as another, depending on the lobby's height.

Meet Stakeholder Expectations of Value

Unfortunately, delivering a project on time, on budget, with the promised scope doesn't always mean you are successful. Why not? Because your definition of the cost‐schedule‐scope equilibrium may not have been the same as your customer's or manager's definition. Even if their expectations of cost and speed are unrealistic, nevertheless they are the final judges of your project, and in their eyes it may be late, over budget, or the delivered product misses the mark.

This may seem unfair, but it does happen. This kind of disagreement, however, is preventable. Recognizing that our project's success is defined by the perceptions of others is a powerful incentive to make sure that all parties involved in the project agree on how the cost‐schedule‐scope equilibrium relates to the original purpose of the project. This leads us to a new success formula for project managers:

1. Set realistic expectations about the cost‐schedule‐scope equilibrium with all the project's stakeholders and connect these constraints to the business case used to justify the project.
2. Manage expectations throughout the project. If the equilibrium changes, make sure everybody knows and accepts the new equilibrium.
3. If at any point it appears that delivering to the cost‐schedule‐scope target will fail to meet the original business objective, reevaluate the target.
4. Deliver the promised product, on time and within budget.
5. Managing this dynamic equilibrium and the related stakeholder expectations is a key project leadership opportunity.

The Ultimate Challenge: No Damage

In an environment where the focus is delivering a high‐quality product on time and under budget, project managers can be tempted to meet impossible goals by sacrificing the people on the team. It happens in every industry, and always for the same reason: Meeting the project goals outweighs the needs of the individual team members. And this attitude isn't reserved just for the project team; vendors and even customers are often put through the wringer to satisfy the project goals. But asking people to give 120 percent, project after project, just doesn't work. They get worn out, demoralized, and just plain angry. The ultimate challenge for project managers is to meet the cost, schedule, and scope goals of the project without damage to the people. That means the project ends with high morale, great relationships with customers, and vendors that can't wait to work with you on the next project.

A Product Development Life Cycle May Contain Many Projects

One of the reasons project management techniques are increasing in popularity is due to their role in new product development. Whether the effort is a new drug, a new software product, a new model car, or a new baseball stadium, it is done one time and produces a unique product. Since product development has the same characteristics as a project, creating these new products provides excellent opportunities for applying project management. The steps necessary to create a new product are known as the product development life cycle. Chapter 4 provides examples of how a product development life cycle will change depending on what is being created. For purposes of discussion, this book will use a simple, four‐phase process that highlights the most common activities in a development process:

1. Requirements. This step defines the function and performance requirements for the product. Whether you're building a house, an airplane, or an information system, requirements describe how the product will meet the needs of the customer.
2. Design. Design conceives a product that will meet the requirements and describes it in detail. For instance, a blueprint is a detailed description of a house.
3. Construct. Next, the product is built, and any documentation necessary for its operation is written. If a building is being constructed, this is where workers dig the holes and pound the nails. In the case of a new model of an aircraft, construction might encompass a wide range of activities, including the creation of new manufacturing processes. (In this case, the product isn't exactly a new airplane, but rather a new process for building airplanes.)
4. Operate. After the product is developed, it has a life span in which it is actually used. Projects then turn into ongoing operations: a baseball stadium holds games, a manufacturing process turns out new automobiles, or a software product company supports its users. The operation phase can last for years and may contain many projects.

Chapter 4 elaborates on the role a consistent development process plays in creating useful products and services and the evolution of new development approaches that are suited to innovation.

Even though it is simplified, the product development life cycle model (as portrayed in Figure 3.4) can serve as a conceptual model to show the basic differences between product development life cycles and a project life cycle.

Product Life Cycle Versus Project Life Cycle

Although new product development, like a project, has a beginning and an end and produces a unique product, it may consist of more than a single project (see Figure 3.5). Anyone wishing to apply project management to new product development must understand the differences between a product life cycle and a project life cycle:

• The product development life cycle describes the work required to create the product. The project life cycle focuses on managing the work.
• A product development life cycle may contain many projects, each of which must go through the full project life cycle.

Understanding that any development effort can contain multiple projects and that each one needs to be managed as a complete project is one of the keys to success in project management.

Waterfall and Agile Development Approaches

The product development life cycle portrayed in Figure 3.4 makes the assumption that each development phase completes before the next one begins. This linear, sequential approach is often referred to as a waterfall development life cycle. The waterfall may be appropriate for constructing an apartment building, but other product development life cycles don't follow this simple progression. One of the biggest changes to software and information technology projects in the past two decades is the advent of the agile methods that repeat requirements, design, and construction multiple times.

The distinctions and benefits of waterfall and agile are discussed in detail in Chapter 4. The key lesson does not change, however; managing a project means keeping an eye on the scope, schedule, resources, risks, and so on, no matter which type of development approach is used.

PROJECT MANAGERS ARE LEADERS

The discipline of project management can be compared to a set of woodworking tools. Both are designed for specific purposes, and both are capable of amazing results in the hands of a master.

Every project needs someone who, regardless of their title, performs the functions of project management. It is a role that can be fulfilled in a few hours a week on small projects or spread among many people on very large projects. But this role cannot be defined purely in terms of the functions of project management or the project management tool set. It must also be understood that the primary responsibility of a project manager is to lead all the stakeholders—the customers, management, vendors, and project team—and encourage them to work together during the course of the project.

Bringing a project to a successful conclusion may require every technique in this book, but none of these techniques will be enough unless the manager wants to lead. The project manager is the catalyst—the initiator who lifts the entire project and puts it into motion. As you learn the techniques presented here, never forget that your energy and attitude are what give them power!

PMP Exam Prep Questions