Decisions are classified as structured, semi structured, and unstructured. Unstructured decisions Are those in which the decision maker must provide judgment, evaluation, and insight to solve the problem. Each of these decisions is novel, important, and non routine, and there is no well-understood or agreed-on procedure for making them. Senior executives face many unstructured decision situations, such as establishing the firms five- or ten-year goals or deciding new markets to enter. Answering the question Should we enter a new market? would require access to news, government reports, and industry views as well as high-level summaries of firm performance. However, the answer would also require senior managers to use their own best judgment and poll other managers for their opinions.

Structured decisionsBy contrast, are repetitive and routine, and they involve a definite procedure for handling them so that they do not have to be treated each time as if they were new. Middle management faces more structured decision scenarios but their decisions may include unstructured components. A typical middle-level management decision might be Why is the reported order fulfillment report showing a decline over the past six months at a distribution center in Minneapolis?

Semi structuredMany decisions have elements of both types of decisions and are known as Semi structured, where only part of the problem has a clear-cut answer provided by an accepted procedure. In general, structured decisions are more prevalent at lower organizational levels, whereas unstructured problems are more common at higher levels of the firm. But before arriving at an answer, this middle manager will have to interview employees and gather more unstructured information from external sources about local economic conditions or sales trends.

The Decision-Making ProcessMaking a decision is a multistep process. Simon (1960) described four different stages in decision making: intelligence, design, choice, and implementation.

Intelligence consists of discovering, identifying, and understanding the problems occurring in the organization why a problem exists, where, and what effects it is having on the firm. Design involves identifying and exploring various solutions to the problem. Choice consists of choosing among solution alternatives. Implementation involves making the chosen alternative work and continuing to monitor how well the solution is working.What happens if the solution you have chosen doesnt work , the above figure shows that you can return to an earlier stage in the decision-making process and repeat it if necessary.

Managerial Roles in DMManagers play key roles in organizations. Their responsibilities range from making decisions, to writing reports, to attending meetings, the five classical functions of managers as planning, organizing, coordinating, deciding, and controlling.These managerial roles fell into three categories: interpersonal, informational, and decisional.

Interpersonal Roles. Managers act as figureheads for the organization when they represent their companies to the outside world and perform symbolic duties, such as giving out employee awards, in their interpersonal role. Managers act as leaders, attempting to motivate, counsel, and support subordinates. Managers also act as liaisons between various organizational levels; within each of these levels, they serve as liaisons among the members of the management team. Managers provide time and favors, which they expect to be returned. Informational Roles. In their informational role, managers act as the nerve centers of their organizations, receiving the most concrete, up-to-date information and redistributing it to those who need to be aware of it. Managers are therefore information disseminators and spokespersons for their organizations. Decisional Roles.Managers make decisions. In their decisional role, they act as entrepreneurs by initiating new kinds of activities; they handle disturbances arising in the organization; they allocate resources to staff members who need them; and they negotiate conflicts and mediate between conflicting groups.SummaryThe different levels in an organization (strategic, management, operational) have different decision making requirements. Decisions can be structured, semi structured, or unstructured, with structured decisions clustering at the operational level of the organization and unstructured decisions at the strategic level. Decision making can be performed by individuals or groups and includes employees as well as operational, middle, and senior managers. There are four stages in decision making: intelligence, design, choice, and implementation. Systems to support decision making do not always produce better manager and employee decisions that improve firm performance because of problems with information quality, management filters, and organizational culture.

RA in ITG provides new tools for managers to carry out both their traditional and newer roles, enabling them to monitor, plan, and forecast with more precision and speed than ever before and to respond more rapidly to the changing business environment. RA in ITG have been most helpful to managers by providing support for their roles in disseminating information, providing liaisons between organizational levels, and allocating resources. However, RA in ITG is less successful at supporting unstructured decisions. Where RA in ITG is useful, information quality, management filters, and organizational culture can degrade decision-making.

Variable gotten Scope, time, cost, quality, and risk.

Software Engineering: Software Project ManagementRisk management, where managers identify what might go wrong and plan what they might do about it, is a key project management responsibility. Project managers have to assess the risks that may affect a project, monitor these risks, and take action when problems arise.You can think of a risk as something that youd prefer not to have happen. Risks may threaten the project, the software that is being developed, or the organization. Project risks Risks that affect the project schedule or resources. An example of a project risk is the loss of an experienced designer. Finding a replacement designer with appropriate skills and experience may take a long time and, consequently, the software design will take longer to complete. Product risksRisks that affect the quality or performance of the software being developed. An example of a product risk is the failure of a purchased component to perform as expected. This may affect the overall performance of the system so that it is slower than expected. Business risks Risks that affect the organization developing or procuring the software. For example, a competitor introducing a new product is a business risk. The introduction of a competitive product may mean that the assumptions made about sales of existing software products may be unduly optimistic.

An outline of the process of risk management involves several stages: Risk identification You should identify possible project, product, and business risks. Risk analysis You should assess the likelihood and consequences of these risks. Risk planning You should make plans to address the risk, either by avoiding it or minimizing its effects on the project. Risk monitoring You should regularly assess the risk and your plans for risk mitigation and revise these when you learn more about the risk.

Risk IdentificationRisk identification is the first stage of the risk management process. It is concerned with identifying the risks that could pose a major threat to the software engineering process, the software being developed, or the development organization. Risk identification may be a team process where a team get together to brainstorm possible risks. Alternatively, the project manager may simply use his or her experience to identify the most probable or critical risks. As a starting point for risk identification, a checklist of different types of risk may be used. There are at least six types of risk that may be included in a risk checklist:

Technology risksRisks that derive from the software or hardware technologies that are used to develop the system. People risks Risks that are associated with the people in the development team. Organizational risks Risks that derive from the organizational environment where the software is being developed. Tools risksRisks that derive from the software tools and other support software used to develop the system. Requirements risks Risks that derive from changes to the customer requirements and the process of managing the requirements change. Estimation risksRisks that derive from the management estimates of the resources required to build the system.

When you have finished the risk identification process, you should have a long list of risks that could occur and which could affect the product, the process, and the business. You then need to prune this list to a manageable size. If you have too many risks, it is practically impossible to keep track of all of them.

Risk AnalysisDuring the risk analysis process, you have to consider each identified risk and make a judgment about the probability and seriousness of that risk. There is no easy way to do this. You have to rely on your own judgment and experience of previous projects and the problems that arose in them. It is not possible to make precise, numeric assessment of the probability and seriousness of each risk. Rather, you should assign the risk to one of a number of bands:

1. The probability of the risk might be assessed as very low (_ 10%), low (1025%), moderate (2550%), high (5075%), or very high (_ 75%).2. The effects of the risk might be assessed as catastrophic (threaten the survival of the project), serious (would cause major delays), tolerable (delays are within allowed contingency), or insignificant.Once the risks have been analyzed and ranked, you should assess which of these risks are most significant. Your judgment must depend on a combination of the probability of the risk arising and the effects of that risk. In general, catastrophic risks should always be considered, as should all serious risks that have more than a moderate probability of occurrence.

Risk PlanningThe risk planning process considers each of the key risks that have been identified, and develops strategies to manage these risks. For each of the risks, you have to think of actions that you might take to minimize the disruption to the project if the problem identified in the risk occurs. You also should think about information that you might need to collect while monitoring the project so that problems can be anticipated.

Again, there is no simple process that can be followed for contingency planning. It relies on the judgment and experience of the project manager.1. Avoidance strategies: following these strategies means that the probability that the risk will arise will be reduced. An example of a risk avoidance strategy is the strategy for dealing with defective components shown in the table above2. Minimization strategies: following these strategies means that the impact of the risk will be reduced. An example of a risk minimization strategy is the strategy for staff illness as shown above3. Contingency plans: following these strategies means that you are prepared for the worst and have a strategy in place to deal with it. An example of a contingency strategy is the strategy for organizational financial problems as shown above.

Risk MonitoringRisk monitoring is the process of checking that your assumptions about the product, process, and business risks have not changed. You should regularly assess each of the identified risks to decide whether or not that risk is becoming more or less probable. You should also think about whether or not the effects of the risk have changed. To do this, you have to look at other factors, such as the number of requirements change requests, which give you clues about the risk probability and its effects. These factors are obviously dependent on the types of risk. The above table gives some examples of factors that may be helpful in assessing these risk types. You should monitor risks regularly at all stages in a project. At every management review, you should consider and discuss each of the key risks separately. You should decide if the risk is more or less likely to arise and if the seriousness and consequences of the risk have changed.

Applied Software Project ManagementRisk PlanA risk plan is a list of all risks that threaten the project, along with a plan to mitigate some or all of those risks. Some people say that uncertainty is the enemy of planning. If there were no uncertainty, then every project plan would be accurate and every project would go off without a hitch. Unfortunately, real life intervenes, usually at the most inconvenient times. The risk plan is an insurance policy against uncertainty. Each of the risks in the plan must be assessed by the project manager and the team. Risk assessment is an important part of planning a software project because it allows the project manager to predict potential problems that will threaten the project and take steps to mitigate those problems. Adding a risk plan to a software project plan is an effective way to keep the project from being derailed by surprises or emergencies. Many people are thrown off by the word assessment its a word that is usually associated with finances or accounting, not with project management. But in this case, its appropriate. A good project manager will assess the risk of her projects in much the same way that a good stock trader will assess the risk of his portfolio. In both cases, potential problems should be identified, and the relative probability and impact of each risk should be estimated. Certain risks will be much more likely to occur and, if they do occur, they might cause much more damage than others. In those cases, steps should be taken to hedge the project (or portfolio) against the risk; this is usually referred to as mitigation when it is done in the context of project planning.Risk planning for most projects can be done in one meeting, usually in less than two hours. The meeting is led by the project manager. The table contains a script for creating the risk plan.

Brainstorm potential risksRisks should be as specific as possible. Its true that The project might be delayed or We will go out of business are risks; however, they are far too vague to do anything about. When a vague risk comes up, the project manager should prod the team into making it more specific. What are the possible sources of the project delay? How have past projects been delayed? For example, if the last project was late because a major stakeholder quit and was replaced by someone who disagreed with his predecessors vision, the team should write that down as a risk. The assumptions documented in the vision and scope document and identified in a Delphi session are another good source of potential risks. The team should go through them and evaluate each assumption for potential risks as part of the risk brainstorming session.

Estimate the impact of each riskOnce the team has generated a final set of risks, they have enough information to estimate two things: a rough estimate of the probability that the risk will occur, and the potential impact of that risk on the project if it does eventually materialize. The risks must then be prioritized in two ways: in order of probability, and in order of impact. Both the probability and impact are measured using a relative scale by assigning each a number between 1 and 5.These numbers are arbitrary; they simply are used to compare the probability or impact of one risk with another, and do not carry any specific meaning. The numbers for probability and impact are assigned to each risk; a priority can then be calculated by multiplying these numbers together. It is equally effective to assign a percentage as a probability (i.e., a risk is 80% likely to occur) and a real duration for impact (i.e., it will cost 32 man-hours if the risk occurs). However, many teams have trouble estimating these numbers, and find it easier to just assign an arbitrary value for comparison.Many people have difficulty prioritizing, but there is a simple technique that makes it much easier. While its difficult to rank all of the risks in the list at once, it is usually not hard to pick out the one thats most likely to occur. Assign that one a probability of 5. Then select the one thats least likely to occur and assign that one a probability of 1. With those chosen, its much easier to rank the others relative to them. It might help to find another 5 and another 1, or if those dont exist, find a 4 and a 2. The rest of the probabilities should start to fall in place. Once thats done, the same can be done for the impact. After the probability and impact of each risk have been estimated, the team can calculate the priority of each risk by multiplying its probability by its impact. This ensures that the highest priority is assigned to those risks that have both a high probability and impact, followed by either high-probability risks with a low impact or low-probability risks with a high impact. This is generally the order in which a good project manager will want to try to deal with them: it allows the most serious risks to rise to the top of the list.Make a mitigation planAll of this risk brainstorming and estimation is only useful if it leads to the team taking actions to avoid the most pressing risks. The remainder of the risk planning meeting should be dedicated to identifying these actions. The project manager should start with the highest-priority risk, working with the team to decide on any actions that should be taken.After that, the team should move down the list of risks, until they decide that the priority of each of the remaining risks is low enough that no action would be required. The team can take any or all of these actions to mitigate a risk: Alter the project plan: The project schedule can be adjusted to help reduce the risk. Riskier tasks can be moved earlier in the project, or given more time. This will give the team an early warning or a time cushion in case the risks materialize. The project manager can also hold an additional estimation session to break down the riskiest tasks into subtasks. More detailed planning will help reduce the risk. Add additional tasks: There are certain actions that can be added to the schedule to help avoid risks. For example, if there is a high probability that a critical team member will leave the organization, cross-training tasks can be assigned to other people. This will increase total effort in the project, but it will be worth it if the team member leaves. Plan for risks: For risks with a high impact that do not need specific tasks or project plan changes, the project manager should have the team spend a few minutes identifying the steps that should be taken in case the risk does occur. These do not need to be added to the project schedule, but they should be written down and added to the risk plan. This way, if the risk does occur, nobody will panic. Problems that have a large impact on the project can be demoralizing to the team and may throw the project into chaos. Simply having pre planned the steps needed to fix the problem is highly reassuring; it keeps the team feeling like they are on track. Once the mitigation steps are identified, all of these risks and actions should be documented in a risk plan. The easiest way to do that is to create a simple spreadsheet with five columns: Risk (one to three sentences that describe each risk), Probability (the estimated probability from 1 to 5), Impact (the estimated impact from 1 to 5), Priority (Probability Impact), and Action (the specific actions that will be taken to mitigate the risk, or None if the risk is deemed a low enough priority to ignore). The figure below shows a sample risk plan.

Software Engineering Risk Analysis and ManagementRisk analysis and management are a series of steps that help a software team to understand and manage uncertainty. A risk is a potential problem, it might happen, it might not. But, regardless of the outcome, its a really good idea to identify it, assess its probability of occurrence, estimate its impact, and establish a contingency plan should the problem actually occur. Uncertainty: the risk may or may not happen; that is, there are no 100% probable risks. Loss: if the risk becomes a reality, unwanted consequences or losses will occur.When risks are analyzed, it is important to quantify the level of uncertainty and the degree of loss associated with each risk. To accomplish this, different categories of risks are considered.

Project risks threaten the project plan. That is, if project risks become real, it is likely that project schedule will slip and that costs will increase. Project risks identify potential budgetary, schedule, personnel (staffing and organization), resource, customer, and requirements problems and their impact on a software project. Project complexity, size, and the degree of structural uncertainty were also defined as project (and estimation) risk factors.Technical risks threaten the quality and timeliness of the software to be produced. If a technical risk becomes a reality, implementation may become difficult or impossible. Technical risks identify potential design, implementation, interface, verification, and maintenance problems. In addition, specification ambiguity, technical uncertainty, technical obsolescence, and "leading-edge" technology are also risk factors. Technical risks occur because the problem is harder to solve than we thought it would be.

Business risks threaten the viability of the software to be built. Business risks often jeopardize the project or the product. Candidates for the top five business risks are (1) building an excellent product or system that no one really wants (market risk), (2) building a product that no longer fits into the overall business strategy for the company (strategic risk), (3) building a product that the sales force doesn't understand how to sell, (4) losing the support of senior management due to a change in focus or a change in people (management risk), and (5) losing budgetary or personnel commitment (budget risks). It is extremely important to note that simple categorization won't always work. Some risks are simply unpredictable in advance.

Risk identificationRisk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.). By identifying known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling them when necessary. There are two distinct types of risks for each of the categories that have been presented in above: generic risks and product-specific risks. Generic risks are a potential threat to every software project. Product-specific risks can be identified only by those with a clear understanding of the technology, the people, and the environment that is specific to the project at hand. To identify product-specific risks, the project plan and the software statement of scope are examined and an answer to the following question is developed: "What special characteristics of this product maythreaten our project plan?"One method for identifying risks is to create a risk item checklist. The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic subcategories: Product size: risks associated with the overall size of the software to be built or modified. Business impact: risks associated with constraints imposed by management or the marketplace. Customer characteristics: risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner. Process definition: risks associated with the degree to which the software process has been defined and is followed by the development organization. Development environment: risks associated with the availability and quality of the tools to be used to build the product. Technology to be built: risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system. Staff size and experience: risks associated with the overall technical and project experience of the software engineers who will do the work.

Risk Components and DriversThe project manager identifies the risk drivers that affect software risk components performance, cost, support, and schedule. In the context of this discussion, the risk components are defined in the following manner: Performance risk: the degree of uncertainty that the product will meet its requirements and be fit for its intended use. Cost risk: the degree of uncertainty that the project budget will be maintained. Support risk: the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance. Schedule risk: the degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time. The impact of each risk driver on the risk component is divided into one of four impact categories; negligible, marginal, critical, or catastrophic

Impact Assessment = (components performance, cost, support, schedule)*(negligible, marginal, critical, catastrophic)

Risk ProjectionRisk projection, also called risk estimation, attempts to rate each risk in two way the likelihood or probability that the risk is real and the consequences of the problems associated with the risk, should it occur. The project planner, along with other managers and technical staff, performs four risk projection activities: (1) establish a scale that reflects the perceived likelihood of a risk, (2) delineate the consequences of the risk, (3) estimate the impact of the risk on the project and the product, and (4) note the overall accuracy of the risk projection so that there will be no misunderstandings.

Developing a Risk Table: a risk table provides a project manager with a simple technique for risk projection. It contains the risk, category, impact and probability of the risk.

Assessing Risk ImpactThree factors affect the consequences that are likely if a risk does occur: its nature, its scope, and its timing. The nature of the risk indicates the problems that are likely if it occurs. For example, a poorly defined external interface to customer hardware (a technical risk) will preclude early design and testing and will likely lead to system integration problems late in a project. The scope of a risk combines the severity (just how serious is it?) with its overall distribution (how much of the project will be affected or how many customers are harmed?). Finally, the timing of a risk considers when and for how long the impact will be felt.The overall risk exposure, RE, is determined using the following relationshipRE = P x CWhere P is the probability of occurrence for a risk, and C is the cost to the project should the risk occur.The project team should revisit the risk table at regular intervals, re-evaluating each risk to determine when new circumstances cause its probability and impact to change. As a consequence of this activity, it may be necessary to add new risks to the table, remove some risks that are no longer relevant, and change the relative positions of still others.

Risk AssessmentAt this point in the risk management process, we have established a set of triplets of the form[ri, li, xi].Where ri is risk, li is the likelihood (probability) of the risk, and xi is the impact of the risk. During risk assessment, we further examine the accuracy of the estimates that were made during risk projection, attempt to rank the risks that have been uncovered, and begin thinking about ways to control and/or avert risks that are likely to occur.For assessment to be useful, a risk referent level must be defined. For most software projects, the risk components discussed earlier performance; cost, support, and schedule also represent risk referent levels. That is, there is a level for performance degradation, cost overrun, support difficulty, or schedule slippage (or any combination of the four) that will cause the project to be terminated.Therefore, during risk assessment, we perform the following steps:

1. Define the risk referent levels for the project.2. Attempt to develop a relationship between each (ri, li, xi) and each of the referent levels.3. Predict the set of referent points that define a region of termination, bounded by a curve or areas of uncertainty.4. Try to predict how compound combinations of risks will affect a referent level.

Risk RefinementDuring early stages of project planning, a risk may be stated quite generally. As time passes and more is learned about the project and the risk, it may be possible to refine the risk into a set of more detailed risks, each somewhat easier to mitigate, monitor, and manage.

Risk Mitigation, Monitoring & ManagementAll of the risk analysis activities presented to this point have a single goal to assist the project team in developing a strategy for dealing with risk. An effective strategy must consider three issues: risk avoidance risk monitoring risk management and contingency planningIf a software team adopts a proactive approach to risk, avoidance is always the best strategy. This is achieved by developing a plan for risk mitigation. For example, assume that high staff turnover is noted as a project risk, r1. Based on past history and management intuition, the likelihood, l1, of high turnover is estimated to be 0.70 (70 percent, rather high) and the impact, x1, is projected at level 2. That is, high turnover will have a critical impact on project cost and schedule.

To mitigate this risk, project management must develop a strategy for reducing turnover. Among the possible steps to be taken are;a. Meet with current staff to determine causes for turnover (e.g., poor working conditions, low pay, and competitive job market).b. Mitigate those causes that are under our control before the project starts.c. Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave.d. Organize project teams so that information about each development activity is widely dispersed.e. Define documentation standards and establish mechanisms to be sure that documents are developed in a timely manner.f. Conduct peer reviews of all work (so that more than one person is "up to speed).g. Assign a backup staff member for every critical technologist.

As the project proceeds, risk monitoring activities commence. The project manager monitors factors that may provide an indication of whether the risk is becoming more or less likely. In the case of high staff turnover, the following factors can be monitored:

General attitude of team members based on project pressures. The degree to which the team has jelled. Interpersonal relationships among team members. Potential problems with compensation and benefits. The availability of jobs within the company and outside it.

In addition to monitoring these factors, the project manager should monitor the effectiveness of risk mitigation steps. For example, a risk mitigation step noted here called for the definition of documentation standards and mechanisms to be sure that documents are developed in a timely manner. This is one mechanism for ensuring continuity, should a critical individual leave the project. The project manager should monitor documents carefully to ensure that each can stand on its own and that each imparts information that would be necessary if a newcomer were forced to join the software team somewhere in the middle of the project.

Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality. Continuing the example, the project is well underway and a number of people announce that they will be leaving. If the mitigation strategy has been followed, backup is available, information is documented, and knowledge has been dispersed across the team. In addition, the project manager may temporarily refocus resources (and readjust the project schedule) to those functions that are fully staffed, enabling newcomers who must be added to the team to get up to speed. Those individuals who are leaving are asked to stop all work and spend their last weeks in knowledge transfer mode. This might include video-based knowledge capture, the development of commentary documents, and/or meeting with other team members who will remain on the project.21