5 Points to be Careful About in Risk Management for Software Projects


Risk management is the process of thinking out corrective actions before a problem occurs, while it’s still an abstraction. The opposite of risk management is crisis management, trying to figure out what to do about the problem after it happens.


If you want to understand risk management then I strongly advise you to read Waltzing With Bears: Managing Risk on Software Projects, written by Tom DeMarco and Timothy Lister.

Waltzing With Bears: Managing Risk on Software Projects   points out 5 main risk points that require caution.


  1. Inherent schedule flaws
  2. Requirement inflation
  3. Employee turnover
  4. Specification breakdown
  5. Poor productivity


●      Inherent schedule flaws

When the project is expected to be complete? This is one of the most challenging questions to answer. If you respond to that question according to customer’s calendar, (suppress) then you’re likely going to fail.

Seasonal deadlines are very popular in Turkey. For example, during the winter season, customers tend to request that we complete the project by spring.

In the book there is helpful dialogue that shows how ineffective attempts to rush the IT team can be:

The major stakeholder was a marketing manager named Hans, who had proposed the project and gotten it funded. Hans was angry when my client’s team came up with a 4Q97 schedule. He had been hoping for March 31, 1997. He denounced her estimate at a public meeting as not aggressive enough, and he followed up (unfortunately for him) with the statement: “I can prove to you that beyond March, every month that this product is not ready to ship will cost this company one-hundred-ten-thousand dollars in lost profit.”

I queried him on his assertion. “Hans, would that same figure apply to delivery before March thirty-first, as well? If we delivered by the end of February, for example, would that give us an additional hundred-ten-thousand dollars of profit, beyond the revenue stream that you have projected?”


“Yes,” he said. “Definitely.”


“And an end-of-January delivery?” I pressed on. “Would that make us yet another one-hundred-ten-thousand-dollar profit?”


“Yes,” he said.


“If we could put the product in your hands today”— that was February 1996, when the project had just been funded—” would you be collecting that additional hundred-ten-thousand dollars per month for the rest of the year?”


“Yes,” he said, a bit less sure of himself now.


“Well then, Hans, you obviously started this project much too late. If you’d kicked it off eighteen months ago, we could be shipping now, and all those months of hundred-ten-thousand-dollars’ extra profit . . .” I let him figure out the implications.


The Kanban method is a great way to overcome inherent schedule flaw risk. With the Kanban method you can use Little’s Law, Lead time distribution and Monte Carlo simulations easily. Estimations must be based on data. The Kanban method is a scientific way to manage your projects.

●      Requirement inflation


According to the Pareto principle the rule is 80% – 20% (Unlike the $ sign, we always put the % after the number). What does it mean? It means only 20% part of the software is usable for the customer, other 80% is wasted.


We can use Lean startup principles in order to mitigate this risk. Focusing on MVP (Minimum Viable Product) can eliminate requirement inflation.

●      Employee turnover



We cannot remove this risk . Even the world’s biggest tech companies (like Google, Microsoft, Facebook etc..) are facing this risk. In order to mitigate that risk we have to be very careful about knowledge transfer.


Wunderlist’s CTO has a rule about on this: he says you can select any technologies but the company has two rules:

  1. At least 2 people have to know that technology in the company
  2. Methods should be very very small ( ~ max 20 lines of code in one method)

To help prevent lost knowledge during handover sessions, I use the following tactics:

  • Record the handover sessions
  • Create a knowledge base in the company
  • Sync knowledge


●      Specification breakdown

This is the most fatal risk. If this risk becomes realized then your project is over. Using Agile methodologies is a good countermeasure for prevention of that problem. Mostly if you are using Waterfall methodologies then this risk might become reality.


One real example: We have a financial solution that was written in Microsoft .NET technologies but the bank servers are all Linux based servers and they cannot be changed. What we did was re-write the project in Java.

●      Poor productivity

Poor productivity is the most dangerous risk. We cannot easily address poor productivity. We can use Agile methodologies in order to tackle poor productivity but the root cause of the Poor productivity’s reasons might be in the deeper level.


The Kanban method is the most Agile way to solve poor productivity problems. Beyond that, Kanban is a good way to start implementing Lean transformation. In order to solve root cause you need to transform (lean way) your organizations.


If you cannot measure it you can now manage it. In the Kanban method the most important metrics is Lead time. What is Lead time?




Let’s say you go to coffee shop and order a cup of coffee. If your coffee comes late you become miserable. We must shorten order time. The customer wants her coffee ASAP! Shortly we must look to the issues from a customer’s point of view.


In the software world the process is similar. The customer wants to use the software ASAP! So, we must shorten Lead time and deliver the software ASAP! The Lean startup approach must be applied so that according to MVP (Minimum Viable Product) approach we must complete the part of the software and deliver it to the customer ASAP!


Lead time is the most critical part in software world. As we all know, requirements are changing so fast. 24 hours is very long time in the software world. In that way, the Kanban method can help us to focus better on the customer’s needs.




Altuğ Bilgin Altıntaş

Bir Cevap Yazın