Modeling Risk (Part 2)

In part one we had a look at risk that comes to the project from the client, before it even starts.  This time we’ll look at risk that comes from the composition of the project and the project team.

I like to call this second category Structural Risk, because it has to do with how a project is structured: the parts that make it up.  Again, to take the positive angle – each point below is listed in its non-risk-adding, positive side:

• The team has worked together before. The team itself is a known quantity, with the individual talents and personalities of each team member known to the group.  This knowledge allows team members to guide the project to leverage the various strengths and avoid the weaknesses of the individuals on the team, working together to achieve the highest level of productivity.  Also hopefully people like and respect each other.
• The team knows the technology. It is a technology that the team has worked with before – they know how to work with it rather than wind up fighting it.  They are unlikely to be surprised by strange quirks of the tech stack that creep up at the most inopportune times.
• The team knows the client. The team has worked with this client before, and therefore knows the business problems that intersect their space.  This way they will be less likely to make poor assumptions about how things are supposed to work.  Functional specs are great, but they don’t take the place of actual domain knowledge on the part of the team.
• The team has a methodology for staying on track. Without getting into the comparative merits of individual development methodologies, the main point is that the team has a way to prioritize, track progress, and correct problems early on.  A team that can’t tell that it’s off-course can’t correct.
• The team can effectively communicate to management, and vice-versa. The cliche is that management understands different levels of priority for requirements, but sees all cost of implementation as equal.  Developers see different costs of implementation, but imagine all requirements to be equally important.  Neither is true, of course, and there needs to be an effective channel for technical and business stakeholders to properly communicate with each other.  A Tech Lead can be an effective method here.

Note that none of this discusses the individual experience or quality of the members of the team.  This is structural.  Process and management – all about getting people to speak with each other, and work well together.

Again 1 point for each “yes” answer for your team, just like in part one.

5 points: A. Your team knows each other, the client and the means to success like the back of their hand.  You’ve probably already made the mistakes you are going to make, so you can count on solid execution from people.

4 points: B. Still solid.  B is as good as a team can get with a new client (and at least in agency work new clients are frequent).  B is structurally still a good risk, but can occasionally throw up a surprise or two.

3 points: C. Medium risk.  At this level there is at least some degree of immaturity in the team – it may reflect new hires, or the creation of a new team where there wasn’t one before.  The team is still working out the kinks in their process.

2 points: D. This is an immature team.  There are enough unknowns going on at this level that the team can easily trip over itself, adding significant risk to a project.  Watch out.

1 and below: F. The team is not ready for this project.  The structural problems will create a significant negative impact on the project, probably leading to some level of failure.

To be concluded in part 3, where we’ll look at qualitative risk, and how to combine all the risk factors together into a single model.