Development buffers and risk factors

Question

How do you plan on risks when working on the project detailed plan? I assume you add to the plan vacation days for each resource (even though they may not have requested leave at this point), you plan sick leave days, time for meetings attendance and most probably 6.5 or 7 hours effective working time per day.

Do you also add in buffer time for development in case the effort required is underestimated by the developers? If yes, isn't that too risky in a sense that it may delay the project deadline unnecessarily?

Answer 1

How do you plan on risks when working on the project detailed plan? I assume you add to the plan vacation days for each resource (even though they may not have requested leave at this point), you plan sick leave days, time for meetings attendance and most probably 6.5 or 7 hours effective working time per day.

My first advice would be to clearly separate questions of available capacity (such as the number of working days per month / year) and risk / opportunity (events of probabilistic nature, which may or may not occur). The subject to risk management is only the second.

Do you also add in buffer time for development in case the effort required is underestimated by the developers?

With regards to risks (and do not forget the opportunities!) you can use different approaches.

For "large" risks that have a significant probability or impact you may want to develop your approach individually.

Not always your approach is going to be to add buffer time. Approaches that you will want to consider are:

• Mitigation - this will typically result in additional scope of work aimed to reduce the risk probability of impact. Mitigation will leave a residual risk that you will have to deal with separately.
• Avoidance - this will typically result in replanning your project in such a way that the risk is not relevant anymore, e.g. if there is a certain risk associated with a subcontractor, you may decide to select another or to bring the work in-house.
• Transfer - this will typically result in having another party to be responsible for the risk, e.g. buying an insurance.
• Acceptance - add a buffer time and/or budget (active) or do not do anything and deal with the risk if it occurs (passive).

In order to plan your actions you may decide to perform a quantitative analysis of your risk to understand better the probability or impact. This will in order give you a better understanding on how to build your buffer. On the other hand analysis also costs time and money, so you will want to leave it for cases where it makes a difference, otherwise limiting yourself to qualitative analysis ("red", "yellow", "green" or something of the sort).

With small risks you may want to deal in bulk to save yourself efforts of analyzing each and every one of them. For example, you can incorporate all your smaller risk impacts into one figure ("velocity") and just apply this as a multiplier for future efforts, while collecting past statistics to refine it.

Further suggested reading: PERT, Risk management in project management.

Answer 2

How do you plan on risks when working on the project detailed plan? I assume you add to the plan vacation days for each resource (even though they may not have requested leave at this point), you plan sick leave days, time for meetings attendance and most probably 6.5 or 7 hours effective working time per day.

After you look at your project plan you should always ask yourself: "What could possibly go wrong?. Some people avoid that question because they believe they could solve problems when they come up.

A good idea would be to involve your team in this discussion and maybe have a look at reviews of previous projects, so you can see what happened to those.

When you have a list of all possible risks you need to assess which ones to worry about. A good way to do this is to give them scores for "how likely?"(0 to 5) and "how serious?"(0 to 5). After that you need to multiply the numbers. If the multiplied score goes into double figures than it is a risk that should be concerned about.

Ffor that kind of a risk you need to have a plan. There are two types of plan you can have for reducing risks: you can either make it less likely to happen or less serious if it does happen.

What customers are interested in is "Which of the risks have you not been able to handle?" So, when you are showing your risk plan to a customer, it's important for them to understand that:

a. You've looked at risks

b. You're on top of risks

c. They're still exposed to risks

Do you also add in buffer time for development in case the effort required is underestimated by the developers? If yes, isn't that too risky in a sense that it may delay the project deadline unnecessarily?

Now this is a bit tricky. It has to do more with an estimate. Let's assume that you need to estimate how many weeks it would take to make a feature. Keep in mind 3 numbers: minimum amount, average (based on past experience) and maximum amount.

Let's assume you would have: minimum 20 weeks, average 30 weeks and maximum 60 weeks. Going halfway between the average and the worst estimate would be the best choice (30+60)/2= 45 weeks.

Most people start either with average or the average+10%. But adding 10% in most cases is just not enough. In our case we would have +3 weeks (30 +10%). 33 weeks would probably be not enough.

Answer 3

You have two types of risks you have to plan for within a project: 1) aleatory, 2) epistemic. Both types will impact your project, and your planning values, both favorably and unfavorably. The first type is un-mitigable as this is caused by random variables within a process or task. The second type you try to identify as much as possible and build into the schedule and into the baseline the tasks you need to perform to mitigate those identified risks.

When doing an estimate, you need to find the best case, worst case, and most likely case so you can understand the probabilistic distribution for that particular task at this time for this project. Both aleatory and epistemic risks live in that distribution. You can use a formula or simply choose a planning value within that range that represents the amount of risk you wish to take. And, yes, you can choose too pessimistically and unnecessarily delay a finish, or obligate too much money, than you need. But the opposite can be true, too.

Most of us are optimistically biased so I would suspect you will experience planning values that are mostly too optimistic. On top of this, if you are a seller of services, you have the threat of competition and that will further lower your planning values. So I would not worry too much about delaying delivery as that won't happen much, I suspect.

Answer 4

I've been working with estimations a lot lately, and to be honest it is extremely hard to know how long is enough.

Most of the techniques out there will be based on the experience. For example, if you execute same type of project with same processes over and over, you can expect to have less buffer, and considering that the people involved in the project will not change, tasks might even go faster. But our biggest problem was figuring out when each project was different from other. So we started scaling with few questions.

I got few ahead of the frequent ones we ask ourselves before giving our own estimated times:

1. Project Size - Our biggest mistake was only to categorize the projects into Small, Medium and Large, but this is part of the learning process. IN order to have a better idea about this, try to get details from people with experience. Usually Small projects already get 10% of buffer, Medium will get 15% and Large ones can get from 30% and above.
2. Complexity - This item will be by itself another buffer. An Easy project can have a buffer of 0 to 5%, while a Medium complex project can range from 5 to 15% and Hard complexity can scale up to 65%.
3. Unit of Measure - Out of experience, we found out it is easier to scale in Hours and THEN convert to $$$ but not otherwise, so choose wisely how you want to measure your project.
4. How many departments/companies/divisions are involved - Usually when we tried to have projects straight to other companies, this didn't impact the complexity of the project, but when we started having third parties involved, this caused to move a simple project to become a hard one.

These are not all the topics that you should consider, but some of them. Having these questions asked still helped us greatly to Improve our PM.

Also the company I work for, we are using ROM Estimation (which is hard to have a good method out there in the internet) that has a margin of 65% of re-adjustments. We also use PERT or Three Point Estimation in order to have a better definition LATER after Requirements are gathered. Use PERT when you have historical data or you can use other projects as a base, use Three-Point if it is a brand new project - Though they might have same type of parameters, Three-Point will have a larger margin of buffer.