Devops for Growth

A group of experts exchange views, and each individually gives estimates and assumptions to a facilitator who reviews the data and issues a summary report.

The group members discuss and review the summary report individually, and give updated forecasts to the facilitator, who again reviews the material and issues a second report. This process continues until all participants reach a consensus.

Let's put these ideas to use in the context of software projects. By following six steps, you can identify risks and take measures either to prevent the occurrence of problems or minimize their impact.

For each of these steps, keep in mind the cognitive skews that might affect your perception. Being aware of how your thinking might be biased will take you a long way toward compensating for any illusions.

Step 1: Identify all possible risks. One rational approach to risk identification is to take the outside view: Ask people who have worked on similar projects what surprises they encountered.

Another method for minimizing cognitive bias in risk identification is to think about risks by category. For example, software project areas of concern might include project management, budget, and technical categories:

• Project management risks include problems caused by miscommunicating requirements, or problems resulting from poor planning.

• Budget risks include overspending due to delays, or financial hits due to unexpected licensing costs.

• Technical risks include bugs in third-party software, or hardware bugs.

For each category, sit down with team members and discuss potential problems that might occur in each area. This approach will help you to structure the process of risk identification.

Step 2: Assess the probability of each risk. Few activities are more prone to skews than assigning probabilities of occurrence of future events. Again, one of the best ways of minimizing bias is to seek advice from people who have an outside view on the project. Try to find out how often certain problems arose in similar projects.

Step 3: Assess the potential impact of each risk. Start out by thinking about how the problem might affect your project: How will the problem change your schedule? What impact will it have on your budget? How might it affect the quality of the software you produce?

When you know each area of impact and its relative importance, you can get a good idea of the overall impact the risk might have on your project. Now assign a value to that impact—in dollar amounts, if possible.

Step 4: Based on the combination of probability and impact, prioritize your risks. You might simply multiply the values for probability and impact to get an expected cost. The risks with the highest expected costs are your highest priorities.

Step 5: For each high-priority risk, think about how you can prevent it from occurring.Assess the cost of prevention and weigh it against the expected cost should the risk occur. Is it worthwhile to take measures to prevent the potential problem, or should you just live with the risk?

Step 6: For risks you can't (or won't) prevent, think about how to minimize the damage should that problem arise. Based on the cost of preventing certain risks, you may decide not to take preemptive measures in those areas. You also might encounter unforeseen risks that couldn't be prevented. In both cases, think of what you can do to spot the problem, should it occur, and then minimize the damage.

Including: time track, request management, customized reports (based to iReport), customized KPIs, dashboard gadgets, knowledge base, risk management, costs and budget management, agile board, resource capacity, surveys, SVN integration, and Gantt chart. The tool also includes: extendable agents (email notification, audit agents, etc), meta fields and custom forms.