This chapter is from the book
This chapter is from the book
This chapter is from the book
1.2 Context
A decision involves passing judgment on an issue under consideration. It is commonly understood to be the act of reaching a conclusion or of making up one's mind. All software projects involve making decisions. Even the act of not making a decision is a decision. For example, if a software project manager chooses to ignore a project member's request for more resources, the manager is making a decision not to act and must deal with the consequences of this noncommittal decision. Increasing a software professional's responsibility increases the number of decisions that the professional must make. This book will explore decisions made by different software project stakeholders and will shed light on how these decisions can be made.
The importance of managing the way in which project decisions are made is evident by the numerous publications that discuss decision making, particularly in the context of managing projects, of managing project risks, and more specifically of managing projects involving product development. The following references are just a few select examples of current publications in these areas. For more about decision making as an integral part of project management, see Cleland and Ireland (2007), McManus (2004), Pollack-Johnson and Liberatore (2006), and Verine and Trumper (2007). For more about the relationship between decision making and risk, see Chapman and Ward (2002), Dillon and Tinsley (2008), Hussey and Hall (2007), and Warkentin et al. (2009). For product development project decisions, see Barry et al. (2006), Gutierrez et al. (2008), Krishnan and Ulrich (2001), Messerschmitt (2004), and Schmidt et al. (2001) With the rise of global development, there is also an increasing interest in the effect of cultural, geographical, and time differences on how decisions are made within organizations and projects. For a current discussion of these issues, see Bourgault et al. (2008), Brett (2001), Espinosa et al. (2007), Mojtahedi et al. (2008), Shore (2008), and Wang and Liu (2007).
In general, software professionals do not understand how to systematically make decisions that result in software projects that are considered to be successful by the project stakeholders. One main problem is that decision makers for software projects often do not state or analyze the inputs and outputs of their decision processes specifically with respect to the needs and expectations of the stakeholders. They may recall that a solution was successful for a particular problem, but then they are surprised when the solution is not successful in solving a similar problem in which the stakeholders have different expectations. This book focuses on the viewpoints of different software project stakeholders to help you refine your decision-making processes so that the resulting solutions are more likely to satisfy stakeholder needs and values.
In general, software project stakeholders make decisions to satisfy their expectations regarding the scope of the project deliverables, the time for the project (schedule), the quality of the project deliverables or product, and the cost (budget). Figure 1-1 shows a model of the expectations that stakeholders have for software projects and the project deliverables.
)
Figure 1-1 Stakeholder expectation model
The model shows that the dimensions of stakeholder expectation (scope, time, quality, and cost) are related. Stakeholders trade different values for scope, time, quality, and cost when establishing the requirements for a software project. Prioritizing their expectations can help stakeholders to make trade-offs more easily and effectively. Different software project stakeholders make different decisions to support their interests. They have different inputs feeding their decision process and different expectations about the outcomes of their decisions. For instance, stakeholders have different levels of tolerance for the risks associated with the decisions that they make.
Consider an example of how software stakeholders make decisions based upon their expectations with respect to scope, time, quality, and cost. Suppose a customer decides upon an acceptable budget for a specified work product, schedule, and quality. Likewise, the solution provider establishes a definition of quality to satisfy both the customer's expectations for the work product as well as the product standards set by the solution provider (who has a reputation in the market to maintain). The solution provider then determines an amount to charge that factors in the cost of developing the work product to satisfy the customer's expectations regarding scope, time, and quality.
But what happens if the customer's acceptable cost is lower than the amount that the solution provider wants to charge? This case would generate another set of decisions. Will the customer and solution provider agree to negotiate the amount to be charged? Will the stakeholders consider alternative scopes, schedules, levels of quality, and budgets? Or will the stakeholders decide that they are unwilling to negotiate an amount to be charged that is agreeable to both of them?
The customer may decide to pursue other solution providers and find that the costs posed by these solution providers are significantly higher than the amount asked by the first solution provider. The customer may then discover that the first solution provider in the meantime has taken on other projects and will not be available to perform the work until a future time that is not acceptable to the customer. What will the customer do now? Did something go wrong in the customer's decision-making process?
This customer–solution provider scenario highlights the interconnected or causal nature of decision making: One good or poor decision frequently leads to another good or poor decision. As the scenario described, a mismatch between the customer's acceptable cost and the solution provider's desired price may result in a cascade of successive decisions that eventually may leave the customer with the choice of selecting a solution provider who would charge a higher amount or abandoning the desired work to be done.
Therefore, it is important that stakeholders understand the factors that affect their decisions as well as the potential consequences of their decisions. Project delays and failures are usually related to a series of poor decisions. When asked how a project becomes a year late, Frederick Brooks answered, "One day at a time" (Brooks 1995, 160). We suggest that a more revealing answer is "One decision at a time."
One way to solve the problem of interconnected decisions is to disconnect them as much as possible, but this solution is not always applicable. For instance, a mismatch between customer and solution provider expectations is common. The issue is how to manage the stakeholder decisions to resolve the mismatch in a way that leads to the best possible outcome. The stakeholders need a systematic way to make software engineering decisions that are likely to lead to successful results. They also need a management strategy to monitor and correct less than optimal decisions before further harm is done to a project.
The purpose of this book is to help you refine your decision-making processes and decision management strategies. We examine the decision-making process with respect to the decision evaluation model presented in the next section. The model is a visualization of factors that are used to make decisions in software development and software project management. The model also provides decision makers with a systematic way to analyze the inputs and outputs of the decision-making process. The book shows how software project stakeholders use their expectations regarding scope, time, quality, and cost as inputs to making project decisions in case scenarios.
The model emphasizes that every decision incurs some amount of assumed risk and that the solution may not succeed in solving the stated problem. It is important for decision makers to understand the risk assumed when making a decision because it may be unacceptable to the project stakeholders. Assumed risk may accumulate over time to a level that is unhealthy for software projects. The objective is to recognize decision situations that need to be carefully managed because (1) the risk assumed in making these decisions is high or (2) the cost associated with unsuccessful outcomes to these decisions is high. The case study analyses in the book show how the model can be applied to make less risky decisions for critical software project management and engineering scenarios. In particular, the case study analyses show how stating the inputs and outputs of the decision model in terms of the stakeholder expectations helps reduce the risks assumed by alternative solutions.
The next section and the remaining chapters in the book will answer questions such as the following within the context of software projects:
- What do decision makers know when making decisions?
- Do decision makers use a process when making decisions?
- Are all decisions of equal value?
- Are software project decisions different from those for other projects? If so, how?
- What does it mean to manage decisions?
- Why is it important to manage decisions?