CHAPTER 5

Project Management Decisions

We have already established the fact that success is the primary objective in project management and decisions are the “yellow brick road” that leads to success. In other words, decisions provide a framework for project managers to guide and control events during product development. Unfortunately, the sequence of decisions and associated choices available to the development team at the beginning of development has a nearly uncountable number of paths.

Krishnan and Ulrich’s (2001) concept of a decision framework refers to the conceptualization of how product development is executed. Krishnan and Ulrich were able to identify about 30 major decisions made within organizations during the development of physical goods at the project level. They found that although different organizations make different choices and might use different methods, all of them make decisions about a collection of issues such as the product concept, architecture, configuration, procurement arrangements, distribution arrangements, and project schedule. Their view of product development is comparable to a deliberate business process involving hundreds of decisions, which has been termed the decision perspective.

The decision perspective is a synthesis of four common perspectives (marketing, organizations, engineering design, and operations management) that cut across the project life cycle; it includes decisions for the product system, the principal organization, and the development or management system that manages product development. This perspective does not focus on how decisions are made; it focuses on what the decisions are and is comprehensive.

In this chapter, we refer to the hundreds of decisions required to successfully manage projects. The decisions apply to uncertain, complex, and changing projects that are affected by the dynamics of the environment, technology, or markets. Such decisions are intended to handle the uncertainty, complexity, and flexibility inherent in project management.

This chapter presents the following sections:

A Project Management Decision Structure

Decisions for Project Management

Product (Operational) System Decisions

Development (Project Management Organization) System Decisions.

A Project Management Decision Structure

A project management decision perspective enables effective decision-making—determining the quality of the outcome in accordance with the choices, information, and preferences of the project manager in the presence of uncertainties and known/unknown risks. The decision perspective guides the construction of a model for all decisions made that permits use of the same kind of checking, testing, and problem elimination activities that systems engineering and software engineering use.

Because the project manager is the person responsible for managing the project and making decisions that support the outcome of the project, if the project manager does not make decisions, the decisions might not be made at all. True project management requires an active manager, not a reactive one.

Four activities are used to manage the schedule, cost, and product performance of the product or system being managed:

Planning

Organizing

Directing

Monitoring

The first activity and the major responsibility or task of the project manager within the decision perspective is planning—the beginning stage. The planning activity encompasses creating the project plan and creating a plan for handling special problems. Clearly, a great deal of emphasis must be placed on planning because the decisions made about planning will have a direct impact on decisions made in subsequent activities performed by the project manager. Planning requires that project managers plan hundreds of decisions that support the project management process. Planning must take place only when the project manager has a complete view of the entire project and a full understanding of the total project life cycle.

The second activity is organizing the decisions. The project manager must decide how to organize the project and must allocate resources to tasks. In the directing activity, the project manager oversees the day-today execution of the project or directs the execution of the decisions. In the monitoring activity, the project manager ensures that the actual progress of the project keeps pace with the estimated progress and determines whether the project should be terminated.

Besides the four activities (e.g., planning and organizing) in the decision perspective, four elements are considered and described in more detail below:

Decision levels—the management level at which the decision is made

Decision types—the part of the development process impacted by the decision (such as needs analysis and test planning)

Decision order—the order in which a group of related decisions should be made

Interdependency—the effects of one decision on one or more other decisions.

Decision Levels

A decision level is the level of management at which specific decisions are made. Most organizations function according to three levels of management: upper, middle, and lower. We refer to the upper level as the level at which strategic decisions are made, the middle level as the level at which operational decisions are made, and the lower level as the level at which tactical decisions are made. The level at which decisions are made was described in Chapter 2 and will be revisited briefly now.

Strategic decisions are decisions that affect the entire organization relative to the management of projects. These decisions are generally administrative in nature. Operational decisions are decisions about resource use. These decisions have an impact on tactical decisions and support strategic decisions. Tactical decisions are day-to-day decisions that directly affect a project and the product or system managed. Each level deals with a unique set of decisions. The program manager makes decisions at the strategic level. The project manager makes decisions at the operational level. Selected leaders of the project team make decisions at the tactical level.

Decision Types

A decision type is a category of similar decisions—or a topic category. An efficient way to organize or group decisions is by type. When this occurs, the decision-making process is made simpler. A primary advantage is that, after grouping, decisions can be arranged in the order in which they need to occur. Topic categories, as stated, describe the various types of decisions and tell what the decision is about. Examples of topic categories, which will be introduced later in this chapter, include (1) needs analysis, (2) life-cycle requirements, (3) management structure, (4) product system design, and (5) test planning. Table 5-1 provides an overview of the topics and subtopics addressed here. The two rows of column headings are the topics. The subtopics are the entries in each for the four main columns.

TABLE 5-1: Decision Topics and Subtopics

Topic categories are developed at each level and are intended to make the decision-making process more efficient. The topic is the label for the category and describes the types of decisions that must be made. The decisions presented in this chapter target the project organization and the product or service being managed.

Decision Order

Decision order refers to the sequence in which decisions are made. The design of an automobile, aircraft, or computer involves hundreds of decisions. The decision-making task is rendered significantly more difficult when many design tasks and decisions are interdependent. However, this can work to the advantage of a project manager because analyzing complex relationships among design decisions facilitates better organization of the design tasks, improves coordination among the designers, and facilitates faster and better product development (Eppinger et al. 1990). Future decisions typically depend on the outcome of earlier decisions. In managing projects, this is also true. Making decisions randomly will likely bring disaster to any project. Decisions must be planned, as far as possible, in an order that prevents schedule delays, cost overruns, or failure to attain product performance objectives. More important, early decisions cannot be put off until later; later decisions should not usually be made before their time.

Figure 5-1 shows a sequence of decisions. Although this is the natural order in which decisions are made, not all decisions are sequential. Decision-making can also occur concurrently, meaning that many decisions can be made simultaneously with other decisions.

FIGURE 5-1: Sequential Decisions

Problem definition and project definition decisions are examples of decisions that should be made early in the project management process. Problem definition is the determination of what problem really needs to be solved by the product or system. Project definition is the determination of what product is going to be developed and how the project is going to be organized to enable this development. Both of these should occur early because these decisions provide information and data for a majority of later decisions. If these decisions are not made, made poorly, or made too late, the biggest mistakes made in a project are likely to occur—mistakes that have rippling effects throughout the project. The decision to select stakeholders should also be identified as early as possible because stakeholders are used to assist in all phases of product or system development. As stated earlier, stakeholders assist in defining the need, clarifying requirements and specifications, and testing. Project managers should be selected after the project requirements are defined but before other team members are selected. The project organization should be defined after product and system requirements have been defined.

In most cases, all decisions that need to get made will eventually be made. The problem is that we do not make the right decisions as expeditiously as we ought, or we make decisions too early that are best left for later. The decision to terminate a project typically comes too late—after valuable resources have already been wasted. When untimely decisions are made, projects stand a greater risk of failure—product development fails, and there are missed organizational objectives.

Interdependency

Decisions are interdependent and must be planned using a comprehensive view of the project. For this to occur, the project manager must be able to envision all phases of the project simultaneously when planning the project. Interdependency among decisions occurs when structured, social, or economic determinants of one decision influence other decisions. Most decisions evidence important elements of interdependence with other decisions. Most decisions are linked to other decisions.

For example, a decision on project organization is likely to be made jointly with a decision about project location. The realization that decisions are interdependent typically leads to a significantly narrowed set of realistic decision options. This is particularly advantageous because some options will make little sense when combined. More important, when decisions are linked, the project manager must plan ahead by effectively coordinating current and future decisions.

Whether a decision maker is making several interdependent decisions serially or concurrently, the project manager needs to consider later decisions when making early decisions.

Decisions for Project Management

Decision-making, the basis for the design—the creation of requirements, architecture, and blueprints—and qualification—testing to verify that a product meets its requirement and to validate that it is the right product—of both the product and the development system during the product development process, uses decisions. Examples of key decisions for project management include those dealing with (1) the organizational structure for doing engineering, (2) the time sequence of skills and resources on hand, (3) the architecture selection, which affects the ability to handle the product’s cost, schedule, and performance when design changes have to be made, (4) new technology used in the design, and (5) the validation tools or mechanisms to be employed.

Making good decisions for both the product and the development system is in essence a self-evident approach to designing (Suh 2001). In project management, the project manager should be concerned with both the product and development system when developing products and when seeking to meet organizational objectives.

Product (Operational) System Decisions

The product system, the product to be released to customers (users), contains elements and features related to satisfying stakeholder needs. These needs are defined in documents such as a mission statement and concept of operations. Later, requirements documents such as the originating requirements document, system requirements document, and various specifications documents are developed.

The performance, cost, and schedule of the product are affected by decisions that influence physical, functional, and interface elements of the product. Decisions for the product system support (1) definition and design, (2) integration and qualification, and (3) life-cycle planning. The types of product system decisions are introduced and discussed in the following sections; however, all decisions are presented in Appendix B.

Definition and Design Decisions

Needs analysis includes problem definition and problem validation—the beginning activities of the product development process. These activities are foundational to the initiation of the project management process and to the successful execution of the design and qualification of both the product and development systems (project management organizations). Problem definition and problem validation represent a definition of stake-holder needs, the mission requirement, and the context of the need, and they also validate the need according to stakeholder input. These activities are critical because as the need or the problem comes into focus, the functionality that the user expects in the product system flows down to the component level of the product system.

A clear definition of the need initiates product system analysis and concept design, which include concept definition, concept evaluation, and concept validation. This activity includes making decisions related to defining the technology and its feasibility, and for selecting and validating suitable concepts for product system development that meet stakeholder needs. Here, it is important that information about the stakeholder needs converges with information about technical capabilities. As all of this information is collected and processed, items related to performance and cost will roll into the stakeholder requirements. This activity helps to establish top-level product system functions, which are the primary prerequisite for the establishment of performance requirements.

Product system, product subsystem and component requirements and design includes requirements definition, design definition, test definition, and validation definition. The requirements definition activity includes making decisions that relate to defining detailed operational requirements that support product design and development. Requirements evolve during the requirements definition activity as information is gained through continual stakeholder interaction; however, during test definition and validation definition, requirements can be added, refined, constrained, or even deleted based on the output.

Test planning includes testing and evaluation planning for the product system, product subsystem, and component levels. An early decision related to this activity is how to prove that the system will meet its key performance targets and perform its intended functions. This is one of many decisions that should be made early because it affects the design of the product system. Another decision that should be made during this activity is how the pieces are going to physically fit together. This decision will also affect the design of the product system and the work to be performed by the development system (project management organization). Initial planning for product system integration and verification, and validation activities, begins in the test planning decision activity for execution during the actual decision activity.

Integration and Qualification Decisions

The product system, product subsystem, and component test includes integration, verification, and product system validation activities. Product system integration and verification results as the product system is assembled from the component level up to the system level and undergoes verification that the product system has been built correctly, according to requirements and specifications. This activity includes those decisions related to proving that the system has been built correctly.

System validation occurs when all requirements have been verified and the product system has been validated as meeting its objective (Jackson 1997). The product system validation activity includes those decisions related to proving that the right system has been built.

Life-Cycle Planning Decisions

Important life-cycle planning decisions include requirements and architecture; stakeholder roles in determining life-cycle requirements; manufacturing; and operation, support, maintenance, and upgrades.

Life cycle-focused design is responsive to customer needs as well as design, as is designing both the product system and the development system (project management organization), which supports development of an operational product. Life cycle-focused design is also responsive to life-cycle outcomes. Blanchard and Fabrycky (1998) propose that life cycle-focused design should consider operational outcomes expressed as producibility, reliability, training, maintainability, supportability, serviceability, refinement, and disposability. Specifically during product design, consideration should be given to a product’s production, which gives rise to a parallel life cycle for bringing a manufacturing capability into being. The product system, product subsystem, and component requirements and design activity not only help to design and develop the product but also help to develop the requirements for the manufacturing process that follows. Understanding other life-cycle system requirements early in the product development process contributes to attaining success in the engineering of the total product system.

Problem definition and project definition decisions are examples of decisions that should be made early in the project management process. As indicated, these decisions provide information and data for all other functions throughout the development process, and they facilitate an exchange of information between the product and development systems (project management organizations). Decisions made during problem definition, problem validation, concept definition, evaluation and validation, and program management planning are early decisions essential to initiating any project. These decisions represent the biggest mistakes if decisions are not made, made poorly, or made too late.

The decision to develop the test plan should be made prior to and not during the actual test activity. The test planning activity should actually begin as part of the advance system planning during concept definition, evaluation, and validation (Blanchard and Fabrycky 1998). There must be a way to evaluate the product system to ensure that requirements have been met; therefore, testing considerations are required at an early point in time.

Decisions associated with life-cycle planning should also begin during concept definition, evaluation, and validation, but they should be made no later than at the time of requirements definition, design definition, test definition, and validation definition. In essence, they should be made throughout the development process.

Development (Project Management Organization) System Decisions

The purpose of the development system (project management organization) is to provide the infrastructure necessary to design and qualify the product system. The project manager serves as the manager, but all elements of the development system are responsible for managing the processes and requirements that support product system development. The development system is foundational to all activities that support the product system and is divided into three areas: (1) management structure, (2) project management planning, and (3) development system construction. These three areas combined represent the resources, processes, and elements necessary for successful product system development. These areas are addressed in more detail in the sections that follow. The decisions for each of these areas are presented in Appendix B.

Decision-making in the area of the development system deals with planning conducted to design a product organization—its structure, in particular—and with organizing teams to facilitate communication and rapid decision-making. Development system construction describes the organizational structure, roles and responsibilities, team makeup, and necessary resources. The basis for team evaluation is also considered.

Management Structure

This section includes those decisions related to defining the management structure of the development system—project definition, stakeholder system, project manager construction, and team development.

Project Definition

The source of the initial information for the development system is the objectives for the project, which are defined by the project definition activity. Organizational objectives can also be considered in this activity. The project manager must understand the nature of the project in order to ensure that the objectives of the project can be met. The project will otherwise get off to a bad start. These goals often tie to organizational goals, as just stated. Ensuring that the right decisions are made can prevent starting a project badly. The nature of the project becomes the basis for all decisions that will follow. Unless the project is defined, it becomes a runaway train. User needs, combined with the project definition, provide critical information useful to the project manager and team, and ensure that project objectives are attained. Understanding the nature of the project also establishes the framework for carrying out the planning that is required. The problem definition activity of the product system also provides critical information useful in formulating the definition of the project.

Stakeholder System

The success of the project management process hinges on the identification of every stakeholder as early as possible because they hold critical information that is needed to begin the product development process. The stakeholder system provides the engineers and project managers with the best opportunity to provide a system that accomplishes the primary objectives set by the stakeholders. Upon identification of stakeholders and their roles, the stakeholders should be involved throughout the management process in order to produce the best operational product or system. In addition, stakeholder roles should be defined. The inclusion of stakeholders early in the design process focuses on the “user requirements” element of concurrent engineering and mitigates the risk of numerous user-generated design changes later in the development process.

Project Manager Construction

Project manager construction focuses on putting together an effective development team, beginning with identification of a project manager. Of all the decisions management makes in doing new product development, none can be more crucial to success than the choice of a project manager. The criteria for the project manager must be determined with respect to the requirements of designing and qualifying the product system. The project manager should be selected after the project requirements are defined but before other team members are selected. This component of the management structure defines the project manager criteria, role and authority, and required training.

Team Development

Successful project management is only as good as the individuals and leaders who are managing the key functions (Kerzner 2006). The project manager uses individuals to manage the business, budget, and technical aspects of a project. Project team decisions focus initially on putting together the right team. The project manager focuses on the project objectives when determining the skills required to successfully complete the project.

Two key tasks in successful project management are designing a project team and organizing project teams in order to facilitate communication and rapid decision-making. Project team decisions focus on the organizational structure, roles and responsibilities, team makeup, and necessary resources (Powell 2002). Team evaluation should also be a part of project team decisions.

Project Management Planning

This section includes those decisions related to defining the project management planning of the development system—information definition and validation, resource definition and validation, and control structure definition and validation.

Project management planning, a critical aspect of product system design, deals with the interaction and understanding of management elements involved in project development to enhance success; it is the glue that holds the entire project together and is programmatic in nature (Forsberg, Mooz, and Cotterman 2000). So in order to achieve the appropriate level of interaction and understanding, the planning process must address information. What information is going to be created or obtained from outside sources, by whom, distributed to whom under what circumstances, stored where and by whom, and validated or assessed as to accuracy by whom?

Resources need to be a central aspect of project management planning. The availability of funding for product development is often the critical resource and drives all planning schedules and performance estimates. However, other resources can be critical; examples include numbers and skills of people; office space and equipment; hardware and software systems; engineering, manufacturing, and testing facilities; and data. We should point out that one of the most critical resources available to the project manager is time. The planning process must therefore address how the expected availability of these resources matches their desired availability. Processes need to be put in place to monitor how many of each of these resources are expected and are in fact available at specific points in time.

Finally we address the definition and validation of control structures. As was stated earlier in this book, project management planning includes 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. This activity manages the integrity of the product development process and the quality of the product while using decisions as the primary control structures.

Before leaving this topic of project management planning, an important excursion is worthwhile. One of the most important aspects during project management planning is risk management. Risk management identifies many areas of program cost, schedule, and technical risk associated with important project resources and gives the project manager the information with which to make educated decisions (control structures). The risk management process provides a means of early warning of problems, a means for plan changes, and a means of deciding the best course of action. More important, it can increase management and stakeholder confidence (Jackson 1997).

Development System Construction

This section includes those decisions related to defining the development system construction (e.g., project office) of the development system—organizational structure, role definition, makeup, resources, evaluation, validation, location, and training. The first element of development system construction is organizational structure, which addresses how the people who are part of the development system will be structured and how this will change over time. Role definition addresses the definition of the different kinds of positions that will exist in the project office and what the responsibilities and authorities will be for those positions. Makeup comprises a number of decisions relating to how the project office will be staffed over time by functional and skill levels.

Resources addresses the various types and constraints on monetary and infrastructure resources associated with the development system. Evaluation includes the bases, means of evaluation, and risks associated with the development system, not the project. Validation comprises the approaches to validating that the plan for the project office is adequate to the task. Location includes the physical layout of the project office, as well as the communication and technology assets associated with the project office. Training addresses the types and timing of training required for the people in the project office.

Stakeholders should be identified as early as possible because stakeholders are used to assist in all phases of development—to assist designers in defining the need, clarifying requirements and specifications—and in all phases of testing. This helps to ensure continual product validation because most critical product decisions will occur early in the project. If the customer is not involved before these decisions are made, momentum will make it unlikely that decisions can be reversed later as a result of customer input (Smith and Reinertsen 1998).

The project manager or team leader should be selected after the project requirements are defined but before other team members are selected (Forsberg et al. 2000).

The development system should be designed after the product system requirements have been established and understood. This is necessary because organizational teams must be tailored to the technical and acquisition phase that the program finds itself in. This leads to the decision of when team members should be added to the organizational team. Having more members than necessary at various points throughout the product development process results in unnecessary costs (Forsberg et al. 2000).