Big Risk–Big Reward

I’ve spent a lot of the last few days sitting in on Seed exit interviews. These are actually great fun, although they are also very hard work. They are part of the assessment process for our MEng students. Essentially we get them to write a case for the marks that they think they deserve, and then they come to see us and try to justify them. For more details of the kind of things we are about, take a look at this blog post from Tom.

Anyhoo, the meetings take around an hour each and they can get pretty intense. Students put very strong arguments that they should get 5 out of 5 for a particular category, and we have been known to revise their scores up as well as down. One of the assessment categories has to do with planning. This is always an interesting issue. I made a point of heading straight for the Risk Assessments that we get the development teams to produce for their projects. These are supposed to set out the major risks to a successful outcome of the project.

Managing risk is a very good plan in a project, most of the projects that fail do so because of a failure to identify and track the things that could go wrong. But sometimes folks didn’t seem to quite get the whole story. Most of the Risk Assessments covered things like data loss, changes to personnel and the like, but some missed out the most important risk of all.

“What if we can’t get it to work?”

It is not unknown for a project in real life (and our projects are as close to real life as we can get them) to fail on this one. The system can have a beautifully crafted user interface, a carefully targeted audience and snappy marketing but if it doesn’t work, all this comes to naught. If you ever, ever, get into a development project you should make it your business to put this in the Risk Assessment and then track it. Maybe the Risk can be removed really quickly, once you’ve built a working prototype. Maybe it’s a slow burner, when you have to do a bunch of work and wait on other people before you find out whether it is a workable proposition.

I make this point as often as I can, and I often get the response “Well, Duh! The project is all about making this thing work, why would you add this as a risk?”. That’s true, but I know about projects, and people, and that defect in human nature that tends to push tricky things away into the distance where you don’t have to think about them too hard. Much easier to design that pretty user interface than work on that nasty interrupt handler code, or whatever.

With experience you learn to identify the “stoppers” in a project; the things that, if you can’t make them work, render the project a failure. These go onto the Risks and are tracked regularly to make sure that nothing in the project is built on sand. By the end of the meetings I think that the students we saw had taken this point on board, which I think is a one of the many really useful outcome from this part of the course.