Who owns the risk buffer?

Photo of a giraffe

Let’s assume I am the manager of a software project with an estimated effort of 100 man-days. We estimate the risk that the project will truly need 200 man-days with 10%. Thus, the risk buffer for my project is 10% of 100 man-days, i.e. 10 man-days. Accordingly, the contract says: (110 man-days × daily rate) × (1+margin) × (1+tax) = price. Now the sixty-four-thousand-dollar question: Do I have to pilot my project to the 100-man-days-mark or can I pilot it to the 110-man-days-mark before I need to escalate apparent overruns to my steering committee?

Let’s assume I am not the only project manager with the only project in my company. There are 10 of us and everyone has a project with an estimated effort of 100 man-days at an estimated risk of 10% for an overrun of 100%. Let’s assume for a moment that all these numbers are accurate. Thus, the risk buffers of all projects nicely sum up to 100 man-days; and the expectation is that one out of the ten projects will in deed need 200 man-days. So, how much of the total risk buffer is left for the other nine projects? Right: zero, nothing, niente, nada. The other way around: If nine of the projects eat up ‘their’ share of 100 man-days from the total risk buffer – how much is left for the tenth project that really gets into serious trouble? Yes, only 10% of the effort that it actually needs is left in the pot.

The consequence is that I must pilot my project to the 100-man-days-mark and the risk buffer belongs to the (multi-project-) steering committee. I am not yet a great project manager if I manage to stay beyond the 110-man-days mark, I am only a great project manager if I stay beyond the 100-man-days mark. See it like that: The 10 man-days are not mine, they are a ‘fee’ I have to pay even before the start of the project for the company’s internal project insurance.

It is the steering committee’s duty to govern the fair and wise distribution of the 100 man-days from the overall risk buffer to the project(s) in need. If they invest too much into the wrong project (hey, every project manager asks for more!) or if the overall risk buffer is too small, well … – that is what we call economic risk. (That, but only that! Not having a systematic risk buffer management is only stupid.) Of course, the estimations could have been too conservative as well, leaving more profit to the company. If this happens by accident – good for your margin! If it is a systematic error, your company systematically offers too expensive. Don’t expect to earn something with the risk! Banks and institutional insurances don’t do either. They earn with their margin. So for the sake of transparency and capacity to act you should rather increase your planned margin if you can afford to do that. The ideal balance of the overall risk buffer after the 10 projects is zero. But as I said – that’s the steering committee’s duty.

Hint: You only need to read the reminder of this article, if you disagree with the initial pricing example.

You ask why I added a margin to the risk buffer in the offer in the above example. It’s not the customer’s fault that we’re not better at estimating effort or design-to-cost. This is internal cost! – you may interject and you are not alone. This is a point that I discussed surprisingly often. Let me explain what makes me think that this is the best way to handle it:

Let’s assume the above projects all have a duration of exactly one year. Let’s further assume our company has a total capacity of exactly 1,100 man-days per year. The third assumption is that the target margin for the whole company is 7% overall – risk or not. So if the man-day is at 500€ production cost rate (all-in), the company is supposed to earn (1100 man-days × 500€ per man-day) × 7% = 38,500€. Obviously, there are two approaches to assemble these 38,500€:

  1. Each of the 1,100 man-days adds to the company’s margin and thus each of the man-days earns its own 7% (i.e. 1,100 × 500€ × 7%), or
  2. the cost of the internal project insurance is regarded as internal cost and only the man-days actually sold to the customer are supposed to earn the total amount of 38,500€. In this case you would have to
    1. increase the daily rate – your total internal costs are higher after all (i.e. your daily rate is now at 500€ × 1,100 ÷ 1,000 = 550€), or
    2. you need to increase the target margin per man-day sold (i.e. you margin per man-day is at 7% × 1,100 ÷ 1,000 = 7,7%)

Besides being more complicated and thus more error-prone in Excel-driven companies, option b) has two disadvantages:

  1. You do not know (or estimate) the sum of the risk you will add-up during the acquisition of the projects during the year. If only win projects over the year that add-up more risk than you have estimated, your daily rate or planned margin is to low. E.g. if you add up 200 man-days of risk buffer over the year, your daily rate ought to be 611.11€ resp. your planned margin ought to be 8,56% in the project you just won. But you only have 550€ resp. 7,7% as you calculated with a wrong assumption and you can’t adapt. So even if everything runs smoothly (as planned) within the project, you’ll lose money.
  2. Regarding the insurance cost as internal cost (i.e. option b.) is unfair for projects (and thus their customers) with lower risks. A customer who pays you ‘time&material’ (i.e. no risk) might be cross-subsidizing the complicated fixed-price project of another customer in this case. This sends a wrong signal to the complete system and will lead to projects with even more risk on the long run.

For this reason, the above formula is the most reasonable effort-bases pricing model.

This article was updated on February 3, 2019
Dr. Tom Gelhausen

Dr. Tom Gelhausen

Tom earned his doctoral degree from the KIT (Karlsruher Institut für Technologie) for his work natural language requirements analysis and UML model generation. He worked as developer, Java trainer, software engineering lecturer, systems engineer, release manager, as Scrum Product Owner, and as Scrum Master, he sat in project steering committees, experimented with insourcing, outsourcing, near-shoring, and far-shoring, wrote offers and rated offers, did controlling and multi-project management, built up a DevOps unit, worked in IT-recruiting and coached employees, and did lots of other things that happen all around the software production process. Hi biggest motivator is getting the software production process run smoothly, satisfying customers and employees likewise – agile and sustainable.