Quasi project

Projects in Contemporary Organizations The past several decades have been marked by rapid growth in the use of project management as a means by which organizations achieve their objectives. In the past, most projects were external to the organization—building a new skyscraper, designing a commercial ad campaign, launching a rocket—but the growth in the use of projects lately has primarily been in the area of projects internal to organizations: developing a new product, opening a new branch, implementing a new enterprise software system, improving the services provided to customers, and achieving strategic objectives. As exhilarating as outside projects are, successfully executing internal projects is even more satisfying in that the organization has substantially improved its ability to execute more efficiently, effectively, or quickly, resulting in an agency or business that can even better contribute to society while simultaneously enhancing its own competitive strength. Fundamentally, project management provides an organization with powerful tools that improve its ability to plan, implement, and control its activities as well as the ways in which it utilizes its people and resources.

In this introductory chapter to project management, we begin by defining precisely what a project is. Both the objectives and characteristics of projects are also discussed to help further define them. Next, we address the emergence of project management, the forces that have fostered project management, and recent trends in project management. Following this, we describe the project life cycle. Finally, the chapter concludes with an overview of the structure of the remainder of the text.

THE DEFINITION OF A “PROJECT” PMBOK Guide Glossary

Formally, a project may be defined as “A temporary endeavor undertaken to create a unique product, service, or result” (PMBOK, Project Management Institute, 2013, p. 417). Consistent with this definition, there is a rich variety of projects to be found in our society. Although some may argue that the construction of the Tower of Babel or the Egyptian pyramids were some of the first “projects,” it is probable that cavemen formed a project to gather the raw material for mammoth stew. It is certainly true that the construction of Boulder Dam and Edison’s invention of the light bulb were projects by any sensible definition. Modern project management, however, is usually said to have begun with the Manhattan Project. In its early days, project management was used mainly for very large, complex research and development (R & D) projects like the development of the Atlas Intercontinental Ballistic Missile and similar military weapon systems. Massive construction programs were also organized as projects, including the construction of dams, ships, refineries, and freeways.

As the techniques of project management were developed, mostly by the military, the use of project organization began to spread. Private construction firms found that organizing work on the basis of projects or a project–based organization was helpful on smaller projects, such as the building of a warehouse or an apartment complex. Automotive companies used project organization to develop new automobile models. Both General Electric and Pratt & Whitney used project organization to develop new jet aircraft engines for airlines, as well as the Air Force. Project management has even been used to develop new models of shoes and ships. More recently, the use of project management by international organizations, and especially organizations producing services rather than products, has grown rapidly. Advertising campaigns, global mergers, and capital acquisitions are often handled as projects, and the methods have spread to the nonprofit sector. Weddings, scout-o-ramas, fund drives, election campaigns, parties, and recitals have all made use of project management. Most striking has been the widespread adoption of project management techniques for the development of computer software.

To add to our vocabulary, in discussions of project management it is sometimes useful to make a distinction between terms such as project, program, task, and work packages. The military, the source of most of these terms, generally uses the term program to refer to an exceptionally large, long-range objective that is broken down into a set of projects. These projects are divided further into tasks, which are, in turn, split into work packages that are themselves composed of work units. Of course, exceptions to this hierarchical nomenclature abound. For example, the Manhattan Project was a huge “program,” but a “task force” was created to investigate the many potential futures of a large steel company. In the broadest sense, a project is a specific, finite task to be accomplished. Whether large- or small-scale or whether long- or short-run is not particularly relevant. What is relevant is that the project be seen as a unit. There are, however, some objectives that all projects share and some attributes that characterize projects. Three Project Objectives: The “Triple Constraint” PMBOK Guide Glossary While multimillion-dollar, 5-year projects capture public attention, the overwhelming majority of all projects are comparatively small—though nonetheless important to doer and user alike. They involve outcomes, or deliverables, such as a new floor for a professional basketball arena, a new insurance policy to protect against a specific casualty loss, a new Web site, a new casing for a four- wheel-drive minivan transmission, a new industrial floor cleanser, the installation of a new method for peer review of patient care in a hospital, even the development of new software to help manage projects. The list could be extended almost without limit. These undertakings have much in common with their larger counterparts. Importantly, they have the same general objectives— specified deliverables (also commonly known as scope*), a specific deadline (time), and budget (cost). We refer to these as “direct” project objectives or goals. There is a tendency to think of a project solely in terms of its outcome—that is, its scope. But the time at which the outcome is available is itself a part of the outcome, as is the cost entailed in achieving the outcome. The completion of a building on time and on budget is quite a different outcome from the completion of the same physical structure a year late or 20 percent over budget, or both. *The term “scope” is typically used when differentiating between what is included and what is excluded in something, but in project management the term has come to mean the specified deliverables. The Project Management Institute’s Project Management Body of Knowledge (“PMBOK”) defines Scope as: “The sum of the products, services, and results to be provided as a project.” We will refer to the PMBOK guide frequently throughout this book and use the icon seen here in the margin to draw the student’s attention to this important reference (see the PMI reference in the chapter bibliography). If particular PMBOK figures, tables, sections, or chapters are relevant to the discussion, we note this under the icon as, for example, 3.2, which means Chapter 3, Section 2.

Indeed, even the concept of scope is perhaps more complex than is apparent. In particular, it is important to recognize that the expectations of the client are an inherent part of the project specifications. To consider the client’s desires as different from the project specifications is to court conflict between client and project team. All too often projects begin with the client specifying a desired outcome. Then the project team designs and implements the project. Then the client views the result of the team’s ideas. In following this approach, differences between the client’s expectations and the project team’s designs commonly develop as a project proceeds. As a result, meeting the client’s desires may not be well reflected by the initially specified scope of the project. The expectations of client and project team therefore need to be continuously realigned and integrated throughout the entire project, but they frequently are not. As a result, we believe in making an effort upfront and throughout the project to ensure the nebulous elements of the client’s evolving expectations and desires are identified and aligned with the “specified” scope stated in the project proposal.

The three direct project objectives are shown in Figure 1-1, with the specified project objectives on the axes. This illustration implies that there is some “function” that relates them, one to another— and so there is! Although the functions vary from project to project, and from time to time for a given project, we will refer to these relationships, or trade-offs, throughout this book. The two primary tasks of the project manager (the “PM”) are to manage these trade-offs and to anticipate and address risks to the project. In addition to the direct project goals, organizations often have a unique set of ancillary project objectives/goals that are often unarticulated but nevertheless important to the success of the project. Ancillary goals include improving the organization’s project management competency and methods, developing individuals’ managerial experience through project man- agement, gaining a foothold in a new market, and similar goals. In a more basic sense, those with a stake in the project (the project manager, project team, senior management, the client, and other project stakeholders) have an interest in making the project a success. Shenhar et al. (1997) have concluded that project success has four dimensions: (1) project efficiency, (2) impact on the customer, (3) the business impact on the organization, and (4) opening new opportunities for the future. The first two are clearly part of what we have defined as the project’s direct objectives; the latter two are typical of what are frequently unspecified ancillary goals. One other crucial, but unstated, trade-off that a PM must consider is the health of the project team as well as the rest of the organization. The PM cannot burn out the team in an attempt to CHAPTER1 / PROJECTSINCONTEMPORARYORGANIZATIONS achieve the direct objectives, nor destroy the organization’s functional departments in an attempt to meet the project’s goals. Another factor in making project trade-offs is the project’s environ- ment, that is, those things or persons outside the project, and often outside the sponsoring organization, that affect the project or are affected by it. Examples of this environment might be antipollution groups, trade unions, competitive firms, and the like. We will deal with these issues in more detail in Chapter 12. From the early days of project management, the direct project objectives of time, cost, and scope (as generally agreed to by the client and the organization actually doing the project) have been accepted as the primary determinants of project success or failure. In the past 25 years or so, other direct and ancillary objectives have been suggested. These did not replace the traditional time, cost, and scope, but were added as also relevant. For the most part, however, Chapters 1 through 11 will focus mainly on the traditional direct objectives.

Characteristics of Projects There are three characteristics that all projects share and a number of other characteristics that are common to projects but not universal. We begin our discussion with the three universal character- istics and then direct our attention to several of the common characteristics. The first universal characteristic of projects is that every project is unique. Though the desired end results may have been achieved elsewhere, every project has some unique elements. No two construction or R & D projects are precisely alike. Though it is clear that construction projects are usually more routine than R & D projects, some degree of customization is a characteristic of projects. In addition to the presence of risk, as noted earlier, this characteristic means that projects, by their nature, cannot be completely reduced to routine. The PM’s importance is emphasized because, as a devotee of management by exception, the PM will find there are a great many exceptions to manage by. The second universal characteristic is that a project is a one-time occurrence with a well- defined and specific set of desired end results. (We discuss poorly defined, or “quasi-” projects a bit later.) These end results are referred to as the “scope,” or sometimes required “performance,” of the project. The project can be divided into subtasks that must be accomplished in order to achieve the project goals. The project is complex enough that the subtasks require careful coordination and control in terms of timing, precedence, cost, and scope. Often, the project itself must be coordinated with other projects being carried out by the same parent organization.

The third universal characteristic of projects is that they have a finite duration. There is a clear date when the project is launched and a corresponding due date or deadline. Furthermore, like organic entities and their growth curve, projects have life cycles. Often starting with a slow beginning and progressing to a buildup of size, then peaking, beginning a decline, and finally must be terminated by some due date. (Also, like organic entities, they often resist termination.) Some projects end by being phased into the normal, ongoing operations of the parent organization. The life cycle is discussed further in Section 1.3 where an important exception to the usual description of the growth curve is mentioned. There are several different ways in which to view project life cycles. These will be discussed in more detail later.

Interdependencies

While not universally true, projects often interact with other projects being carried out simulta- neously by their parent organization. Typically, these interactions take the form of competition for scarce resources between projects, and much of Chapter 9 is devoted to dealing with these issues. While such inter-project interactions are common, projects always interact with the parent organization’s standard, ongoing operations. Although the functional departments of an

Project Management in Practice A Unique Method for Traveler-Tracking at Copenhagen Airport IT University of Copenhagen, Denmark was working with Copenhagen Airport to improve both the effi- ciency and effectiveness of the management of their airport through a new approach: traveler-tracking, but without invading people’s privacy. The 3-year project focused on a unique, low-cost approach—capturing the Bluetooth signals from passengers’ phones with two electronic readers that cost only $30 each. At the time, not everyone had a smartphone that emits sig- nals, of course, but about 7 percent of the passengers do, enough to provide a completely random sample for tracking. To ensure travelers’ privacy, a crucial stake- holder in this project, they collected only a portion of each signal and deleted the addresses. They also informed the public about the project on the airport’s website and on-site as well. To encourage positive traveler response to the project, they provided alerts to passengers willing to synchronize their Bluetooth to receive information regarding when their plane was boarding and a map to the gate. Knowing when people were entering and leaving Security allowed the airport to balance the staff at Security so lines didn’t build up, thereby shortening the time passengers must wait, while also reducing over- and under-staffing of screeners. In addition, the information allows them to also post wait times at the check-in gates. The data also lets the airport determine which shops and areas are getting the most traffic so they can shift usage of facility space to better serve the travelers and the friends and families accompanying them. And when construction and rerouting changes traffic flows, they can determine the impact on pas- sengers and take action to reduce the inconvenience.

Questions: 1. Arethetripleconstraintsofthisprojectclear?What are they?

2. What was unique about this project? What was the main conflict?

3. Why are the travelers themselves a stakeholder in this project, since most of them won’t even know they are being tracked?

4. How widespread do you think this technology will become? What uses will be garnered from it? Do any of them concern you? Source: S. F. Gale, “Data on the Go,” PM Network, Vol. 24.

organization (marketing, finance, manufacturing, and the like) interact with one another in regular, patterned ways, the patterns of interaction between projects and these departments tend to be changeable. Marketing may be involved at the beginning and end of a project, but not in the middle. Manufacturing may have major involvement throughout. Finance is often involved at the beginning and accounting (the controller) at the end, as well as at periodic reporting times. The PM must keep all these interactions clear and maintain the appropriate interrelationships with all external groups. Projects also typically have limited budgets, both for personnel as well as other resources. Often the budget is implied rather than detailed, particularly concerning personnel, but it is strictly limited. The attempt to obtain additional resources (or any resources) frequently leads to the next attribute—conflict. More than most managers, the PM lives in a world characterized by conflict. Projects com- pete with functional departments for resources and personnel. More serious, with the growing proliferation of projects, is the project-versus-project conflict for resources within multiproject organizations. The members of the project team are in almost constant conflict for the project’s resources and for leadership roles in solving project problems. The PM must be expert in conflict resolution, but we will see later that there are helpful types of conflict. The PM must recognize the difference.

Project Management in Practice The Smart-Grid Revolution Starts in Boulder, Colorado  ermingut/iStockphoto Boulder’s utility company, Xcel Energy, decided that it was time to create a roadmap for a 3-year, $100 mil- lion “smart-grid” electrical system that would span the entire city. There were no standards, benchmarks, or tested procedures for converting a city from a con- ventional electric-grid system to a fully integrated smart one, though it was known that if customers can monitor the true cost of their energy, they will automatically reduce their usage, by up to 30 percent in some cases. Of course, the smart grid would also allow Xcel to reroute power around bottlenecked lines, detect power outages, identify service risks, cut its use of road crews, read customer meters remotely, reduce outages, and identify false alarms more quickly. Xcel brought in a mass of partners on the project, such as Accenture consulting for engineering, energy industry consultants, leading technologists, business leaders, IT experts, and of course, Boulder city man- agers, leaders, and user-citizens. The public and pri- vate partners were divided into eight teams, all led by a senior project manager working with a Project Man- agement Office. With all these different stakeholders, with different objectives and interests, it was crucial to have steady, reliable communication to keep everyone up to date and the project on track. Security and privacy were high-priority items on the project, and communication with the community was facilitated through town hall meetings, the local media, tours of project sites, and even a touring trailer allowing citi- zens to get a hands-on demonstration of the smart-grid technology. With the completion of the project, Xcel is now measuring its many benefits and expects it will take a year to collect and analyze all the data across all the seasons. The project partners have also created an industry consortium to establish industry standards for future, larger smart-grid projects. They now see Boulder as a living laboratory from which they can continue to learn and thereby successfully deploy smart grids across the entire country.

Boulder’s utility company, Xcel Energy, decided that it was time to create a roadmap for a 3-year, $100 mil- lion “smart-grid” electrical system that would span the entire city. There were no standards, benchmarks, or tested procedures for converting a city from a con- ventional electric-grid system to a fully integrated smart one, though it was known that if customers can monitor the true cost of their energy, they will automatically reduce their usage, by up to 30 percent in some cases. Of course, the smart grid would also allow Xcel to reroute power around bottlenecked lines, detect power outages, identify service risks, cut its use of road crews, read customer meters remotely, reduce outages, and identify false alarms more quickly. Xcel brought in a mass of partners on the project, such as Accenture consulting for engineering, energy industry consultants, leading technologists, business

Questions: 1. Are the triple constraints of this project clear? List each of them. 2. Given the range of benefits listed for the new technology, what interdependencies and conflicts do you suspect smart grids will create for utilities? 3. A major portion of this project had to do with carefully managing all the stakeholders. List those mentioned in the article and divide them into the four groups mentioned above. Do any stakeholders fall into more than one of the groups? 4. What conflicts do you suspect might have occurred between all the different stakeholders in this project? 5. Why do you imagine Xcel agreed to invest $100 million in this risky experiment? What might have been their ancillary goals?

1.1 THE DEFINITION OF A “PROJECT”

Conventional thinking suggests different stakeholders (e.g., clients, the parent organization, the project team, and the public) define success and failure in different ways. For example, the client wants changes and the parent organization wants profits. Likewise, the individuals working on projects are often responsible to two bosses at the same time: a functional manager and the project manager. Under such conditions conflict can arise when the two bosses have different priorities and objectives. While the conventional view tends to regard conflict as a rather ubiquitous part of working on projects, more recently others have challenged this view. For example, John Mackey, cofounder and co-CEO of Whole Foods Market, suggests in his recent book Conscious Capitalism (2013) that satisfying stakeholder needs is not a zero-sum game where satisfying one stakeholder must come at the expense of another. Rather, Mackey suggests a better approach is to identify opportunities to satisfy all stakeholder needs simultaneously. One way to accomplish this is to identify ways to align the goals of all stakeholders with the purpose of the project. As was mentioned earlier, the primary role of the project manager is to manage the tradeoffs. However, as Mackey warns, if we look for tradeoffs we will always find tradeoffs. On the other hand, if we look for synergies across the stakeholder base, we can often find them too. The clear lesson for project managers is to not be too quick to assume tradeoffs exist among competing project objectives and stakeholder groups.