Planning for failure

I'm currently helping with the design of an international virtual learning platform network (a network of Moodles). The Group IT Project Manager has asked me for some estimates of how long I think particular tasks will take. And that set me thinking...

My assumption, of course, is that the people executing those tasks know what they are doing, won't fall ill, won't do it wrong, won't have a mishap, etc, etc. Every task you plan has what accountants call "a cost" (and that's not necessarily a financial cost). Before embarking your team on a particular task you have to weigh up the costs. It is an important exercise because sometimes the least obvious course of action is the one with the smallest cost.

We're obviously building in some contingency... but how much contingency? There are some rough rules-of-thumb that project managers use (true cost of a human resource roughly equals salary x 2, for instance). But what about when something happens to your project that you just haven't legislated for?

I was set thinking on this path on Friday last. We had our family evening planned when I had a phone call from home to say my wife was stranded at the local hardware store because she had lost her car key. This is an innocent mishap that then has a cost (financial: more wear and tear on my car; more fuel needed for my car to fetch the spare key, and practical: late back home means late supper; late supper means late feeding of now irritable family members which means... and so on).

Like my plans for Friday evening, project plans assume everything is going to according to that plan. But that's not always the case. We're in a period when the world ecomony is still parlously close to crashing around our ears and one of the reasons put forward is that economic models assume that people behave in rational, sensible ways... which, of course, they don't. It's called the "efficient-market hypothesis".

When I'm reporting my timescales for tasks in our Moodle project I'm working with what one might call an "efficient-project hypothesis". I guess what I mean by that is that not only do we assume that all the players work in the most effective way possible but also (and possibly more importantly) that any project will only be as successful as the information available at the time (in fact EMH comes in three flavors, weak, semi-strong and strong - essentially to do with the amount of information available).

If I assumed that everyone working on the project didn't know what to do and everything that could go wrong did go wrong then how long would the project take to complete?

Erm... if I did that would I still be in a job?

Gulp.

I am interesting to hear your thoughts.

Reflecting on Reflecting - PRINCE2 and issue logs

Of course there's nothing new under the sun, and whilst filling out an issues log this morning (for a PRINCE2-supported project I'm currently working on) I was taken to writing this short post on reflective learning.

I don't know how much you are aware of PRINCE2 but if you are going to be working on a UK/Westminster government contract then it is pretty much expected that you will follow the PRINCE2 method. If you're interested then take a look at the UK's Office of Government Commerce (OGC) website, here.

One aspect of the method I'm particularly keen on is the issues log. Anyone involved in the project can add an issue to the log. These are the curve ball problems from colleagues - can often come at you from nowhere and bring a project to a dead stop until they are resolved.

Issue logs are simple affairs, often just a spreadsheet with columns for description, target resolution date, &tc. The column I'm most interested in (from an educational point of view) is the oft-forgotten one at the end: Closure Comments.

Closure Comments is the project manager's opportunity to reflect - hopefully sensibly, coherently, and with a critical eye - on how that issue came to be missed, how it was resolved, and why, if necessary, the target date for resolution was missed.

It's the part of the job of project management I find the most interesting and challenging: having to justify to everyone - including myself - the decisions I make.

But it's a very powerful teaching technique I also apply to teaching math (if you've Googled me then you'll realise I wear lots of hats - hence the name of this blog). For instance, I could ask: "why did you factor a quadratic that way?" or "tell me at each step of adding two fractions together what you are doing and why you are doing it".

Have you tried this technique in your teaching? What have been your experiences?