Daily risk estimation for your team

Question

Assume that you leads team of 4 developers. How often would you estimate the risk of the project? What do you think about the daily estimation? Do you think that the daily updates of the potencial problems (based on the morning stand-up meetings with the team) released as a short summary e-mail is good idea? Maybe you would consider an another form of the risk-analysis document spread among your team?

Answer 1

As a developer, I don't like meeting every morning. I assume you still talk with the team during day, and every team member talks to each other too. If that's true everybody should be pretty aware of what is happening. Just ensure that if there are some major problems you get informed right away and do meeting once a week to make up with progress if somebody missed something.

This of course would be false if there are many people working on the project and one can't physically make up with the speed of produced code

Answer 2

daily estimation is certainly not a good idea, it doesn't add a lot of value. Sometimes not much changes in a day in S/W. Surely a weekly estimation is the minimum and also a must. I have observed that there is always a variance whenever a weekly plan is compared with the Weekly status. Also any delvierable that misses two weeks becomes a risk or atleast needs attention.

The reason I am against daily estimation is because i believe in giving freedom to the developers to plan and deliver. It depends on the kind of people you lead, though.

Answer 3

I've worked on small, medium and large sized projects and I can't say I've ever seen risk reviews done less than once per fortnight (every two weeks), In some cases they were performed once per month (personally twice a month would be my recommendation).

The key to risk management is to allow enough time to pass before you re-review project risk. This gives a project manager enough time to evaluate whether contingencies and migitation are valid and to allow the team time to decide whether risks are more or less likely (probability), and whether risk mitigation techniques have lessened the impact of any recorded risks.

You also need to allocate enough time for individuals who have been assigned ownership of one or more risks, to evaluate and report back on mitigation & contingencies. In other words, it's strength is through routine review - but enough time must pass for it to be useful.

Edit: Obviously this isn't the sort of task which should be constrained to a rigid schedule. If it becomes necessary, you could schedule risk reviews closer together to suit the needs of the project (i.e. if necessary, move to weekly reviews and then scale back during stabilization etc).

The important thing is not to let the work/tasks slip, or to stop reporting/raising new risks.

Edit(2): Sorry, I missed another aspect of the question. How to handle reporting/communicating the risk to the team (and other stakeholders perhaps?) -

At a basic level, I'd say that you need the ability to record risk items and to weigh them according to probability and estimated impact, and also to be able to assign them to various team members (ownership). Version control is critical here!

How you do this will vary depending on the nature of your team/project etc. There are plenty of ways to track the information (a spreadsheet, for example which can be emailed to external parties), a SharePoint List etc. Someone (usually a PM) must take ownership of the process so it doesn't get forgotten!

You might want to avoid email (IMHO) since it has a habit of not being stored or recorded correctly.

Answer 4

The daily stand up -- done right -- is a great way to reduce risk on your project because it increases the amount of communication between team members and helps you discover problems earlier. However, the stand-up can't take too long or it will itself become a threat -- people will avoid bringing up potential issues if they think that it will prolong the meeting. I'd not make a formal calculation of risk a part of the daily stand-up, but would use the results of the daily stand-up to trigger a re-analysis as significant new issues arise. You may also want to schedule a regular re-analysis with the frequency depending on the amount of risk you have and are willing to tolerate.

Answer 5

The initial risk analysis should be performed at the start of the project and then, determined by the complexity and overall risk level of the project, have a schedule in place. A daily risk analysis (formal) seems over doing it - if you need to meet daily about real/new risks then the project probably needs to be rethought (like analyzing every step you take on a hike...if you need to do that then maybe the hike shouldn't take place. I've found that using the same type of communication for reporting up and out (to the team) to be the most effective, it reduces the reworking of information. A simple spread sheet (google docs) with risk name, status, assigned to and mitigation plan is sufficient.

Answer 6

There are many kind of risks, some can be handled within your team, some cannot. Intra-team should be talked about in the daily (if you do one). However, don't let your meeting slip more than 10-15 minutes. If something require talking about it for more than a minute or two, it's worth having a separate meeting with only the concerned people. If something can be handled within the day, just remember to check on it the next morning. Otherwise, write it on a card, tag it on your board, this takes a few seconds.

Macro level risk, or those who cannot be handled by the team alone should be updated, at least weekly. Every week, I write a report to the client, risk is a major section of this report (and one the client like the most). The more open you play with you client, the better things will be if things get darker. Always accompany the mention of a risk with the actions currently undertaken to minimise this. ex: Low performance on computer with less than X MB of Ram. We are working on method Y and Z to improve performance but those are risky and bug prone. We recommend raising min. spec. to W GB of Ram

Answer 7

It seems obvious but remember to never make the same mistake twice: I've seen "risk" progress reports repeat the same (obviously flawed) mitigative actions that didn't work when the exact same risk materialized two weeks earlier. This puzzles me..

Keep it real. If you don't know how to mitigate the risk, keep it on the list anyway.