Understanding project risks in a self organized team

Risks and Issues for a project is often a matter of worry for a project manager in a team. When you start asking your team to self organize themselves, one of the challenges is to get each individual team member to start thinking of risks and issues for the project/team.

One of the things which helps during the start of a release is to run through the project plan
through a small group of people in the team, to make them understand what they are signing up for. So if your team has 6 pairs of developers it will be nice to run the plan though with 2 pairs of devs, a BA and a QA, and again repeating it for the remaining set of people. It does not matter whether they are freshers or experienced people, they start thinking about what can go wrong in the project. People start asking more questions on "Why the capacity is so much ?" , and "Why are we planning for these stories in Iteration 2 instead of 1 ? ". More importantly you sign up for a release/project plan as a team and not as a project manager/tech lead.


The team also needs to keep an eye on the risks and issues that they identified and constantly seek solutions to mitigate them. There might also be new risks poppng up. What a team can do in this case is to have a mini risks and issues wall near the team area. It can be an X-Y graph of Risks posted on Likelihood v/s Impact.





Even a white board with risks being updated will do , but what matters is that it resides in the team area. A developer taking a break or a stroll around the team area should look at it and wonder "What can we do to tackle that high risk item ?"