CHAPTER 2
Managerial Decision-Making
Are project management decisions different from the types of everyday decisions that we make? Indeed they are. They are not traditional common-sense decisions like those we make in the normal course of living. They are complex decisions about problems that require a great deal of analysis. Project management decisions have a large impact on project success. Projects such as designing new products, building a house, installing new systems, constructing new facilities, designing information systems, and designing a political campaign are good examples of projects that require a great deal of management decision-making. Project management decisions include not just decisions about spending and specifications, but also decisions about achieving long-term goals such as customer satisfaction and larger business goals.
In project management, decisions cannot be random and must be planned in support of project, product, and organizational objectives. Managerial decisions, based on their specific context and nature, have a significant effect on the organization (Braverman 1980) and require a commitment of fiscal, physical, or human resources (Harrison 1987).
This chapter presents the nature of managerial decisions, the importance of planning managerial decisions, and several examples of successful and failed projects. We also look at some of the specific decisions that project managers have to make. Several case studies are presented that highlight decisions that contributed to project success or project failure.
This chapter presents the following sections:
Managerial Decisions Defined
Strategic, Operational, and Tactical Decisions
Generic Project Management Decisions
The Importance of Project Management Decisions
Project Management Decisions Contribute to Project Success
A Management Perspective on Failed Projects: Two Case Studies
The Solution—Good-Quality Decisions.
Managerial Decisions Defined
As stated in Chapter 1, project managers are generally concerned with three objectives:
Meeting the budget
Finishing on schedule
Meeting client specifications (product performance).
Project managers are also responsible for successfully achieving these additional objectives:
Successfully managing stakeholders (e.g., CEO, program manager, contractors, consultants, clients)
Successfully managing the project team (e.g., finding the right people, finding the right number of people, assigning the right people to the right tasks at the right time with the right information)
Successfully managing risks.
Projects run the risk of failing when these six project, product, organizational, and business objectives are not attained. Project managers must not assume, however, that they are responsible for making all the decisions that are required to successfully manage projects. Some decisions will be made by others. For example, program managers are responsible for making decisions about project resources, and clients and end-users are responsible for making decisions that affect the operation of the product or system being managed.
It is, therefore, a major responsibility of the project manager to make sure that members of the project management team use a structured decision process that uses a consistent set of objectives and a planned methodology.
In short, project managers are specifically responsible for making project management decisions (decisions related to the six objectives presented earlier in this section). Some decisions result in short-term success, while others effect long-term success. Project management includes both short-term and long-term objectives.
Table 2-1 shows the categorization of project management decisions. Project management decisions are broad in nature and affect the project, the product, and the organization. Project and product decisions are narrow in scope, while organizational decisions are broad in scope. Project decisions focus on meeting project requirements—cost, schedule, and product performance. Organizational decisions focus on meeting organizational objectives.
TABLE 2-1: Categorization of Project Management Decisions
Project management decisions focus on achieving business results and include budget, schedule, and product performance decisions. They are decisions that (1) relate to defining processes, activities, and events that have to be carried out to attain the objectives specified for the project, product, and organization; (2) reflect the overall management and discipline of the project; and (3) define the necessary resources for product development and resources for operation (Powell 2002). These decisions are used as the control parameter during management of the integrity of the development process and quality of the product. As a result, each decision made must be a conscious decision intended to guide and control all events occurring in the project management process that satisfy project, product, and organizational objectives.
Managerial decisions tend to focus on at least the following five dimensions that contribute to a project’s success (Shenhar and Dvir 2007):
Project efficiency: Meeting time and budget goals
Impact on customer: Meeting requirements and achieving customer satisfaction, benefits, and loyalty
Impact on team: Satisfaction, retention, and personal growth
Business and direct success: Return on investment, market share, and growth
Preparation for the future: New technologies, new markets, and new capabilities
Each dimension includes several possible submeasures, shown in Figure 2-1 (Shenhar and Dvir 2007). Making effective decisions within each dimension is a complex task. For example, there are schedule decisions and budget decisions, and there are requirements decisions and customer-related decisions. There are decisions related to the team and additional decisions that impact the organization.
FIGURE 2-1: Dimensions and Submeasures that Contribute to Project Success
Because project managers concern themselves with the future, decisions must be made that impact an organization’s future. Due to the dynamic nature of the decision-making required, it is easy to understand why effective decision-making is no easy task. Project managers must simultaneously focus on all five dimensions because decisions made in one dimension will have an impact on decisions that need to be made in another dimension. For example, schedule decisions have an impact on decisions related to customer decisions, and customer decisions affect project team decisions.
Strategic, Operational, and Tactical Decisions
Every organization has a structure—flat or hierarchical. Companies involved in project management traditionally have a hierarchical structure. Because decisions are made at every level of the organization, we can classify project management decisions into three categories—strategic decisions, operational decisions, or tactical decisions.
Strategic decisions are broad in scope, affect the entire organization, and usually have long-term consequences. By “broad in scope,” we mean that strategic decisions can be high-level thematic decisions or choices that will drive other decisions. Organizational objectives, for example, reside at the strategic level. An example of a strategic decision is the identification and description of the unique features of the business that will make it competitive. Choosing those features, that is, deciding upon which features will make the business competitive, is a decision that is on a high level and thus demands no specific action explicitly. But it does drive other decisions that must be made to implement the organization’s strategic business plan.
Operational decisions are less broad in scope, affect middle management, and are also usually long-term decisions. Choosing product objectives resides at the operational level. An example of an operational decision is choosing the materials that are required to design and develop product components.
Tactical decisions are narrow in scope, are short-term, and are driven by strategic and operational decisions. Choosing project objectives resides at the tactical level. An example of a tactical decision is choosing among various alternatives how a project can best be managed. Strategic, operational, and tactical decisions are interrelated, and decision makers exchange information with other decision makers as shown in Figure 2-2. Strategic decisions are made first and help to define operational decisions. Both strategic and operational decisions then affect or drive the tactical decisions that are made. Tactical decisions are made more frequently and routinely than either strategic or operational decisions.
FIGURE 2-2: Relationship between Decisions
Generic Project Management Decisions
We now turn our attention to some of the specific decisions that project managers have to make. The example we use is decisions we would need to make if we started our own company—a company called Powell and Buede’s Bakery, which will produce nutritional almond cookies. In Table 2-2, column 1 presents the decisions that must be made (specific to cookie production), column 2 presents the actual decisions that were made, and column 3 presents the stage in the project management life cycle in which the decision was made. (See the section “The Project Management Life Cycle Guides Decision-Making” later in this chapter.) Some decisions are strategic in nature, while others are operational and tactical. The decisions shown are appropriate for just about any type of project.
TABLE 2-2: Generic Project Management Decisions
The Importance of Project Management Decisions
Making managerial decisions is one of the most important functions a project manager must perform. The primary reason for the importance of this function is that the competitive advantage of an organization often depends on project success. Project managers must keep decision quality high while locating limited project resources and performing other highly visible tasks.
The natural tendency is for project managers to place strict emphasis on the management of a project instead of focusing on the type, nature, and impact of the decisions made in the project management process. In some cases, a decision-making process is altogether absent. Because project management decisions usually affect many people and are made in a dynamic and uncertain environment that involves cost, time, and performance trade-offs, making the best decision is critical to successful project management (Mazda 1998). (It should be noted that this book does not address decision-making styles, such as authoritative or participatory styles. The authors think that each project manager should use the style that’s most comfortable.)
Decision analysis is a process that assists in determining whether a decision is good or bad. Not analyzing the effect of a decision is definitely not good business. Even when decision analysis is conducted, because risk and uncertainty are present, an exact outcome can never be known ahead of time. What we do know is that when proper and improper decisions are made, several things occur, respectively.
When proper decisions are made, three things are certain (Kerzner 2006):
Functional units understand their total responsibilities toward achieving project needs.
Problems resulting from scheduling and allocation of critical resources are known beforehand.
Problems that might jeopardize successful project completion are identified early in the process, so that effective corrective action can be taken and replanning can occur to prevent or resolve problems.
When improper decisions are made, three things are certain (Kerzner 2006):
Company and/or project policies, procedures, and directives are continually revised and/or established.
Organizational responsibility is continually shifting and unnecessary restructuring may occur.
Staff requires skill development and new knowledge.
It is logical that poor-quality decisions have a greater probability of schedule delays, exceeded budgets, poor product quality, a lack of proper management skills, inadequate risk analysis, and improper validation methods. The list goes on.
Project Management Decisions Contribute to Project Success
Project management decisions focus directly on the project, the product, and the organization. The Dell computer, Microsoft Office software, the Internet, the Unmanned Aerial Vehicle (the U.S. Predator aircraft), and the Abrams tank are all very good examples of recent projects that have succeeded. The success of the projects was not necessarily judged on how well the projects met cost and schedule objectives but on how well the projects achieved the long-term business goals for which they were initiated—how much value they delivered to their organizations or customers. In each example, the focus was on the project, the product, and the organization, but the primary focus was anchored to the business results.
In traditional project management, project success depends on satisfying the three constraints—time, budget, and specifications (product performance). The focus in traditional project management is on the project efficiency. In some cases, the success of a project is still evaluated solely on project efficiency—how well it meets cost, schedule, and specifications (product performance).
A judgment of project success should not be based only on how well it satisfies the three constraints; a judgment of project success should be based on how well the project delivers long-term value to the organization and to customers. We understand that in some cases a project can be successful even though it fails to meet the time, budget, and performance objectives. In business organizations, projects are not generated to meet cost, schedule, and product performance but to achieve the long-term business goals for which they are initiated, so there needs to be some flexibility when assessing the success of projects—even when using the three fundamental objectives of all projects with which this book began.
Project managers must focus on more than just meeting time goals, budget goals, and product specifications (project efficiency). They must also focus on other dimensions of project management that are necessary to produce success: (1) customer impact, (2) impact on the team, (3) business results, and (4) preparation for the future. Customer impact deals with improving the customer’s life or business. Team impact decisions focus on team learning and team growth. Business results target commercial success. Preparation for the future addresses the long-range benefits of the project.
Some dimensions, such as project efficiency, can be assessed in the very short term, while preparation for the future can be assessed only much later. Project management decisions thus have two objectives: short-term and long-term. Short-term success is achieved by or defined as meeting cost, schedule, and product performance objectives. Long-term success is defined as achieving long-term business goals—delivering value to the organization and the customer. As already stated, although a project might not satisfy the three constraints, it can still be considered a success. Consider the following cases (Shenhar and Dvir 2007).
• Case 1 When the first generation of the Ford Taurus was introduced in 1986, it quickly became the best-selling car in America and one of the most successful cars in Ford’s history. Its revolutionary design and exceptional quality created a new standard in the U.S. automobile industry, and customers simply loved the car. Yet when the development project was completed, its project manager was demoted because the project was completed three months later than scheduled.
• Case 2 The first Windows software launched by Microsoft suffered enormous delays, with continuous redirection of resources and people. But Windows turned out to be one of Microsoft’s most profitable products and an enormous source of revenue.
• Case 3 Before introducing its big hit, the Macintosh, in 1984, Apple Computer completely failed with its predecessor, the Lisa computer. Apple’s managers acknowledged later that without the lessons learned and technologies developed on the Lisa project, the Mac’s success would not have been possible—calling into question whether Lisa was indeed a complete failure.
In each of these cases, the project was eventually considered a success based on the value delivered to the organization and to the customer— long-term success. Evaluated against traditional—short-term—means, each project would have been considered a failure. Shenhar and Dvir have made the following observation (2007):
Meeting time and budget goals is only a small part of the picture. Adhering to a project plan tells us nothing about achieving the long-term business goals for which the project was initiated. Most projects are part of the strategic management of their organizations, and they should be assessed based on their contribution to overall business results, and not only on their ability to meet time, budget or performance goals. An organization must therefore set project goals in advance to reflect its expectation, both in the short term and in the long term.
What is important to keep in mind is that although a project may fail to meet time and budget goals, it can be judged successful based on product and organizational success. We now consider another case (Shenhar and Dvir 2007).
CASE STUDY
The Sydney Opera House
One of the world’s greatest tourist attractions is the Sydney Opera House, an architectural wonder visited every year by millions of travelers. The original project plan, as envisioned by the New South Wales government in the 1950s, included an estimated budget of about seven million Australian dollars and a schedule of five years. But getting there was tough. The construction project experienced enormous difficulties—extensive delays, bitter conflicts, and painful budget overruns. Sixteen years passed before the opera house opened its doors, and its final price tag was more than 100 million dollars. Judging it purely on time and budget and performance, you might conclude that the Sydney Opera House project was a textbook example of project failure. But no one really cares anymore how the project was managed, and almost everyone sees the Opera House as a success story. It provides continuous income and fame to the city of Sydney, and it remains one the most fascinating buildings in the world.
Aaron Shenhar and Dov Dvir, Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation (Boston: Harvard Business School Press, 2007): 21. Copyright © 2007 by Harard Business School Press. Reprinted with permission.
The next case study presents a detailed overview of a project that eventually succeeded—but not until it first failed. Both the project and the product successes are noted. Some of the decisions mentioned earlier (see the bold questions in the case study) are considered in the decision-making process. The case study presents the implementation of the Prospective Student Information System at the University of Oklahoma and includes all phases of the project life cycle, which is described in Chapter 3. The problem is defined, stakeholder analysis is conducted, alternatives are generated, a system solution is selected, and the system solution is implemented. This case depicts the integration of a number of concepts addressed in this book and brings to the reader’s attention a number of challenging issues that might be encountered in the implementation of a product or system solution.
Several failures within the project were noted before the overall project was considered a success. First, the system did not meet user needs. Second, the budget did not adequately support the project requirements. Third, there was a requirement that people who used the system contribute some of their own resources. Fourth, the system’s interaction with various stakeholders (e.g., students, faculty) was not well defined. Fifth, there was no way to modify the system after flaws were found. These failures can be easily traced back to a lack of good project management. A review of the case reveals the key decisions that contributed to project success—but only after time and valuable resources had been wasted by poor decisions earlier.
Design and Implementation of the Prospective Student Information System
Dr. Bobbie L. Foote, Professor Emeritus, University of Oklahoma
The Project Beginning
(What is the problem?) In 1967 the University of Oklahoma decided to venture into the new computer technology to consider automating their student admissions system. The University at this time was making a commitment to utilize commercial computing power instead of continuing full-scale development of their own computer, the OSAGE, which was designed and built from conception by University faculty. They had realized that they did not have the resources to develop the myriad software applications necessary to run the University information needs based on the one-of-a-kind operating system for the OSAGE. The University had bought an IBM 650 computer by 1957 and after 1962 had purchased an IBM 1620 and had started developing the software and operating specialists to run a punch card operation.
(What skills are required?) A young professor in Industrial Engineering was selected to design and implement the new system. (Who are the project team members?) A team of administrators was formed to advise him. A bright young graduate student who was an employee of a local air-conditioning manufacturing firm and had an undergraduate degree in Industrial Engineering from the University of Oklahoma was hired to gather information and write demo software to show feasibility.
Gregory S. Parnell, Patrick Driscoll, and Dale L. Henderson, eds., Decision Making in Systems Engineering and Management (Hoboken, NJ: John Wiley & Sons, Inc., 2008): 420-422. Copyright © 2008 by John Wiley & Sons, Inc. Reprinted with permission.
(Who are the users?) In the early planning stages, a standard Industrial Engineering analysis was performed. A survey was sent out to determine potential users. (What is the source and method for determining requirements?) These users were interviewed as to what information they wanted. This led to a listing of actions and decisions that they needed to make. A standard IE flowchart was developed to look at timing.
This was an admissions system. So the first day of enrollment in the summer or fall served as one of the drop-dead time goals. To be admitted, the student had to supply high school transcripts, a copy of a medical exam, records of immunizations, religious preferences, housing preferences, and their interest in various academic programs. There were deadlines for these submissions. If a student failed to submit the required information, the University manually went through the file and noted omissions and sent out a letter with boxes marked to indicate the information shortage. Some students went through several cycles. Students who showed late interest were a problem as the University needed to expedite their record analysis and to communicate decisions quickly. Appeals had to be handled.
(What is the problem?) Another problem was the exponential growth of the applications as more and more people realized the value of a college education. This led to a big problem with applications for a scholarship as the donors and other supervisors had deadlines to make decisions. Scholarship applications required extra information such as letters of recommendation and student essays. This put a real burden on the manual system.
(What are use case studies?) As a part of the routine information gathering, histories of other processing applications were sought. It was at this point [that] an unpleasant realization occurred. Over 90 percent of the past projects had either failed or never even started. An investigation of these failures ensued.
At this point a series of meetings with upper-level managers, including the Vice President (later Provost) for Academics was initiated. A series of surveys was sent out to get information about these failures. The returns indicated a variety of reasons: The system did not meet their needs; low budget, hence a requirement that people who used the system kick in from their resources; awkward means of interacting with the system; inability to modify the systems after flaws were found.
(What are the product requirements?) During this time the student research assistant created a system to handle the requirements as understood. (What is the solution concept?) This system consisted of: a set of decisions required by each user, the time deadlines, and the information required by the decisions; a set of actions required that were to be automated such as letters of acceptance; letters asking for more information; letters reminding students of deadlines; and most importantly, a system flow diagram that pinpointed interactions among future users of the system. Student letters asking for information were separated into two groups: one that required a form answer and [one dealing with] more complex issues that required a personal answer. (What are the feasibility criteria?) This list was reviewed by University software developers and feasibility was assessed. IBM had an interest and donated time to help assess feasibility.
(What are owner and user requirements?) The above study highlighted the amount of cooperation required from University functions and their clerical personnel to use the system successfully. Everyone realized that a training package had to be developed before the system could be activated.
The Implementation Plan
The chairman of the IE department and the study manager had a series of meetings to address the problem of implementation. (What are implementation requirements?) The need for training was determined to be an easy problem to design and manage. (What are training cost requirements?) The major problem was the financial issue and the perceived quality issues that plagued previous projects. A series of personal interviews with users and system designers revealed a further problem: the selective memory of users. After a new system was begun, users would frequently say that they had unmet needs that had been communicated to designers but ignored in the final product. Users also had little concept of the changes in operating protocol that would be needed.
(How will user requirements be managed?) The following solution emerged. If you wanted help, you had to pay, but the Provost would match the dollars from the managers’ budget from his own. (What is the test plan?) The final part of the implementation protocol was to circulate the plan to the managers (users) and then meet personally with them. The provost required one of two responses: the plan suits my need or it fails and here is what is missing. Time deadlines for responses were given. A new plan was devised and the same process was carried out. When no gaps were found by users, […] a final document [was] circulated which required the signature of the user. They either signed saying that the system met their needs or the system failed. If the system failed, they had to give reasons. Those users with problems met with the study manager and the Provost to discuss their problems. In front of the Provost, managers were candid and cooperative. After this meeting, every user who had not signed, signed. (Who is responsible for development and testing?) The head of the computer center took responsibility for developing and testing the software in time for implementation just after Christmas.
The Outcome
The resulting system was programmed and proved to be a rousing success. The offload on users and their clerical staff was huge. (What are the future requirements?) The growth of the University was enabled and further data processing projects grew rapidly. PSIP proved to be the basis of the complex information system that encompasses the University today.
Appendix A includes additional examples of project successes.
A Management Perspective on Failed Projects: Two Case Studies
We eat, sleep, and breathe decisions. Decision-making is what we do daily, whether in the conscious or unconscious realm. Our ability to make decisions is exercised in many ways—through trial and error, intuition, empiricism, and process methods. Often, decisions are categorized as small decisions and big decisions; small decisions receive less attention than big decisions. This concept might work when dealing with everyday decisions, but in managing projects a decision is a decision. Overlooking what might be a small decision can have as devastating an effect as overlooking a big decision and can cause a project to fail or fall short of achieving its objectives.
For example, delaying a project review might be considered a small decision, but the delay can have huge consequences for the project schedule, the project budget, and the technical specifications of the product being managed. In essence, all decisions are equally important. Nonetheless, there are clearly some decisions that require much more attention than others. One of the goals of this book is to motivate the reader to consider more decisions to be worthy of careful, conscious attention.
The reason for a project failure is always tied to a decision that is impaired, made too early, made too late, or not made at all. In many cases, the decision to retire a project is always better than allowing a project to fail. Retiring a project saves valuable resources that can be used elsewhere in the organization. Although the decision to retire or discontinue a project is never an easy one, the decision becomes much more complicated when the project begins to exceed both schedule and budget. We present two case studies to illustrate these points.
The first case study reviews a project that failed after five years and after investments totaling $26 million (Plas 2006). A number of key project decisions were not made. Those absent decisions contributed to the project failure.
The University of Wisconsin (UW) has been implementing a system-wide payroll and benefit software at its many campuses across the state. After five years and $26 million, UW decided to switch from a new development project by Lawson Software to Oracle/PeopleSoft, aligning with the state Department of Administration’s decision to implement an information system initiative with Oracle/PeopleSoft. The UW project’s implementation problems have been well-documented, including millions of dollars of cost overruns, a disbanded project management team, and the retirement of key decision makers (Plas 2006).
The main reason for failure was a lack of good project management. In an article about the project, UW project management consultant Diane Haubner faulted the entire planning process (Kleefeld 2005). That process included a number of project management decisions that were made poorly or should have been made but were not (Kleefeld 2005):
The use of a committee-made task list as opposed to development of an overall project plan and the naming of a project manager
People in charge of the project who knew a lot about software but not a whole lot about actual project management
Poorly planned testing of database systems
Lack of communication between testers and management.
The second case study is a review of a project that failed to consider the importance of fitting the right organization to the right project (Shenhar and Dvir 2007). As stated earlier, the reason for a project failure is always tied to a decision that is impaired, made too early, made too late, or not made at all. Throughout the case study, we highlight decisions that should have been made but were not.
The FCS Project
FCS was a third-generation fire control system developed by a well-known defense contractor in Israel. The main challenge for the FCS project was to improve the hit accuracy of weapons mounted on moving vehicles. Because the contractor was experienced in building components and subsystems for similar previous generations, its executives assumed that they had the capability to compete for an entire system. (What are the required skills?)
The major technical innovation in the FCS was a new stabilization technique, which promised to improve performance substantially. However, it would also require the use of technology that was totally new to the company, as well as an entirely different operational doctrine.
Nevertheless, company managers assumed that they could manage the development of this new system in the same way as their previous, less comprehensive projects. (What are the management requirements?) They also assumed they could use existing modules, with minor modifications, as building blocks for the new system. (What are new technology requirements?) In addition, they assumed that after they had developed, tested, and validated all the subsystems, it would be a straightforward matter to assemble them into a functioning integrated system. (What is the assembly process and methodology?) Based on these assumptions, they put together a team in the way they always had, and they set about the new project with the same general mind-set and methodology to which they were accustomed. (What is the best form of organizational design and what are the organizational components?)
Aaron Shenhar and Dov Dvir, Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation (Boston: Harvard Business School Press, 2007): 37-39. Copyright © 2007 by Harard Business School Press. Reprinted with permission.
However, most of the engineers working on the program had no experience with the crucial new stabilization technology. Furthermore, none of the team members had built entire systems, with responsibility for overall performance to meet the system’s end-user expectations. (What are the required experience levels?) On top of that, the whole project was new to the customer, and this meant that the ultimate performance objectives (and minimum requirements) were somewhat uncertain. (What is the method for requirements validation?) The plan was to start delivering initial units after 16 months and to begin full-scale production in three and a half years.
It soon became clear that the original project schedule was unrealistic. (What is the method for determining task durations?) The project plan was therefore rewritten—twice. Still, the project steadily fell behind. After the first year, the company initiated emergency procedures and started to funnel additional resources to the program. Yet it took two full years for company managers to realize that the whole program needed to address two major problems, which lay outside the scope of the original plan altogether. By this time the crisis was full blown.
The first problem was that developing the stabilization technology would require much more time, because the new units needed additional design cycles to accommodate greater technological uncertainty.
The second problem was more profound: A complex system does not simply function as a collection of subsystems. The program needed an extensive period of system integration, together with the development of a new combat doctrine. Those activities were not part of the original project plan. (Define the organization for validating the project plan.)
A drastic change in project management style was needed. After the intervention of top management, new systems engineering and integration groups were added to the team. In addition, the company mobilized specific hand-picked experts, including external consultants, to help the team in its efforts. And top management involvement became much more extensive, with daily briefings and almost instant reporting of new problems and solutions. (When are the required project reviews?) This change resulted in a breakthrough, and it led, after 38 months, to the delivery of the first fully functioning system. Production started after five years, with a final delay of 21 months and cost overruns of almost twice the original budget.
As noted, the project team finally got its act together, but not until valuable time and resources were wasted. This case clearly reveals what happens when the right decisions are not made. It is critically important that project managers be aware of what managerial decisions need to be made in order to produce project success.
The Solution—Good-Quality Decisions
As noted in the case studies just presented, most project problems are managerial, not technical. When technical errors do cause projects to fail, it is usually management that failed to make the right decisions. Managerial decisions are critical to successful project management and therefore must be managed in a way that produces desired results. Unfortunately, great management does not necessarily lead to successful projects. Many projects under well-experienced management and management teams often end in failure or fall short of achieving managerial and product objectives.
The current trend is project failures continuing at an alarming rate. Why do projects continue to fail? Mismanagement and the decisions that management makes are the answer to this question. The success of a project essentially hinges on the quality of the decisions made. When decisions are of poor quality or are dysfunctional, the result is often a failed or impaired project; however, when decisions are of good quality, projects stand a far greater chance of being successful and contributing to organizational goals. The goal of this book is to assist the project manager in the task of identifying those decisions that will enable project, product, and organizational success.
This chapter introduced the nature of project management decisions. First, we presented an overview of project management decisions. We then presented a set of project management decisions using project life-cycle terminology. Because decisions can mean life or death for an organization, we stated why making project management decisions are an important responsibility. Decisions are made at every level within project management organizations. Although this text focuses on decisions at the project or tactical level, we defined two additional levels—strategic and operational. In addition, we showed the results of proper and improper project management decisions. The next topic addressed long-term and short-term decisions. We ended the chapter by highlighting decisions that contributed to project success and those decisions that contribute to project failure.
The following specific points were made in this chapter:
Project management decisions include decisions that (1) relate to defining processes, activities, and events that have to be carried out to attain the objectives specified for the project, product, and organization; (2) reflect the overall management and discipline of the project, and (3) define the necessary resources for product development and resources for operation.
During management, project management decisions are used as the control parameter of the integrity of the development process and the quality of the product.
Making managerial decisions is one of the most important functions a project manager must perform, because the competitive advantage of an organization often depends on project success.
Project management decisions fall into three categories—strategic decisions, operational decisions, or tactical decisions.
The reason for a project failure is always tied to a decision that is impaired, made too early, made too late, or not made at all.
Managerial decisions tend to focus on at least five dimensions: (1) project efficiency, (2) impact on the customer, (3) impact on the team, (4) business results, and (5) preparation for the future.
Many projects under experienced management and management teams often end in failure or fall short of achieving managerial and product objectives because the ideas and decisions that worked well the last time did not work so well this time.
In Chapter 3, we present the project management life cycle as a mechanism that guides and controls decision-making. We also provide examples of decisions unique to each life-cycle stage.