Pricing risks when developing a project's budget

Question

During the initiation and planning a project how much do we add to the project's budget in order to take into account discovered risks? And how much should we raise the price of the project for a customer?

Let's say we are talking about a custom software development company, and the project is a fixed-price project.

I'd like to know a concrete, systematic approach that can be used as part of a project management methodology in a company. The goal is to minimize the number of unsuccessful or low-profit projects.

Answer 1

You can calculate the expected monetary value (probability x financial impact) for those risks you identify in advance of proposal submission and add that to the price. The issue with this approach is that you are only calculating for those risks you identify in advance and you also need a critical mass of identified risks for EMV to work statistically. Also, you leave out what is known as aleatory risks, which is simply random fluctuations with work. You need to account for both epistemic (specific known risks) and aleatory risks.

In addition to doing an EMV exercise, you can also model your cost and schedule using a Monte Carlo approach and planning your tasks with both best case, most likely case, and worst case time and budget values. Run the model and you will capture the overall probabilistic outcome for both values. Then you can price your project, and plan your schedule, using a higher P value, i.e., P70, P80, P90, in order to cover your risks if you are rather risk averse for whatever reason. You will have in your price both the EMV you calculated and contingency in the P value to cover aleatory threats.

To think about P value using an easy example, think about your commute from your home to the airport. It is likely, since you have done this commute many times, you know the probabilistic range to drive to the airport. For me, best case is 40 minutes, most likely is one hour, and worst case two plus hours. You can visualize what the curve looks like. If I need to be on time at the airport, I might plan to leave 1.2 hours in advance or even 1.5. If I did not care if I was late, then I could choose a more risky value and leave 50 minutes before I wanted to be there.

Answer 2

You need to calculate risk exposure for each of the identified risks then compute a work buffer to cover them. This is part of the Risk Analysis and Management practice.

Since this is a fixed price contract, you need to do an upfront estimation of your work, most likely directly in time units. You also need to sit down and think about what risks may potentially throw off your project of schedule. Then for each risk you think about the probability of it occurring, and how much time this risk will add to your project if it does happen. Multiplying these two gives you a risk exposure that you can then use to build a work buffer.

Now, of course, these probabilities and estimated impact are just that, estimates. Just because there are some steps to follow and some way to compute things, doesn't mean that you will be covered from all risks. You might forget about some risks, you might wrongly estimate the probability of them happening, or their impact. So at the end of the day, it depends also on other factors: what the risk tolerance for your business is, how similar projects behaved in the past, what size the work buffer you end up with is, what it's written in the contract, etc.

EDIT: based on your question in the comment about the fixed end-date, note that there is always a risk that you estimated the work incorrectly. An estimate is an approximation, not a certainty. So you might need to include some buffers for the actual items of work themselves.

For example, it's best to use a 3 point estimate (optimistic, most likely, pessimistic) and then compute the probabilities of completing the project in some duration or another by considering the variance of the activities (see for example this document How to Apply Three-Point Estimating (Program Evaluation and Review Technique - PERT). Once you fix the time constraint with an agreed end-date, you will have to negotiate on the scope or cost constraints, and you always have uncertainty and risk when it comes to estimating scope.

Answer 3

It's a commercial decision based on your past experience, your business objectives and judgement about what the customer will pay. In my opinion fixed price is a poor idea for a one-off software development project because in many cases it can go badly for both vendor and purchaser. If the customer asks for a fixed price then I would want to quote both fixed and T&M pricing options. On short term projects (say 6 months) I have seen fixed price command a 40% premium over the equivalent day-rate price. When the customer sees both prices together maybe they will go for the cheaper and safer option.

Make sure you also negotiate a rate for excluded costs as part of the contract - i.e. the rate they pay if/when they want something outside the agreed scope.