This post is a continuation of Keys to Project Success - Part 6
Years ago I got a call from our CIO about a project to automate budgeting for our U.S. division. The company made consumer packaged goods, and so the budget was built up from below the SKU level, as different packaging, ingredients, and many other variables had to be taken into account to arrive at costs. The U.S. finance folks, like in so many other organisations, used spreadsheets to do the number crunching. But with so many different combinations (we literally had thousands of SKUs!), these spreadsheets collectively amounted to what I often refer to as, “Excel Hell”.
I did as much investigation into budgeting tools as I could in advance of the meeting that was to happen only a couple of days later, and with my admittedly slim dossier of information on the options I uncovered, the CIO and I boarded a plane to meet with the U.S. CFO and his team. The presentation went reasonably well, and with me exuding more confidence than I probably should have with the modest information I had, the CFO decided not only on one of the products I had presented, but also that I was the guy to head up the project. Oh boy!
I have to confess that even though I was flattered and exhilarated, I was also uneasy. I didn’t think I knew enough yet to move forward, and I hadn’t even seen a demo of this product let alone had any time to play with it; my ‘best option’ selection was based on reading-research only. The CFO had impressed upon us the tight timeline to complete the project, which didn’t leave much room for additional research. Right up front in that meeting, I admitted these things, and indicated that there was a non-trivial amount of risk in moving forward with this product. Nonetheless, the CFO was willing to accept that risk, my CIO said, “OK, you’re the boss,” and we were off!
Even in those days, I had a pretty keen sense of risk. I attribute a fair bit of that sense to my lifeguard training, where we are taught to recognise a potential accident before it happens, and then do what needs to be done to make sure it doesn’t happen. That’s what the swim tests with the lifeguard before letting toddlers go in the deep water are all about – make sure they can swim well enough and are comfortable enough so they don’t drown. So for this project, that uneasy feeling was all about the risk of the software not fulfilling our needs, spending a pile of money, and getting to a point where we have to throw in the towel. I didn’t know how likely that would be, but I had a pretty good idea of roughly the time and money we’d be throwing away, not to mention the impact on my career. There was risk here!
So what is ‘risk’, anyway? We talk about it a lot, but often without a good understanding of what it is we’re addressing. I’ve always used a definition of risk as being the product of (a) the likelihood / probability of an event (that hasn’t yet occurred) resulting in negative consequences, and (b) the size of those negative consequences. The two parts of the definition are important for managing risk, because both the likelihood and the consequences of the event need to be taken into consideration when deciding what (if anything) to do.
For example, suppose you have to run into a store quickly, and you need to park your car on the street. If you get ticketed, the fine will be $50, say. So now we know the consequence of the negative event (that you get ticketed). But if it’s in a neighbourhood where no one ever sees any parking enforcement personnel, the likelihood would appear to be next to zero. So the risk would seem low, and not much point in managing that risk. On the other hand, if when you park your car you see the parking enforcement officer writing a ticket three cars along, the likelihood that she’ll get to your car before you can get back is probably closer to 100%, and the risk much closer to $50. So, that $2 parking fee seems like a good risk management strategy, reducing the likelihood of getting a ticket to nil.
Managing risk on a project is an active, constant activity. Everyone on the team should be ‘risk aware’, looking for things that could go wrong. Make sure that your people know that if anything makes them feel uneasy or anxious about the project, that thing is probably a risk, and they should be identifying it. And scrum masters, team leads, and anyone else in a leadership role should have risk identification as a performance evaluation criterion. Deviations from plan (schedule, budget, resource assignment, etc.) are all indicators of risk events.
I like to have a ‘risk officer’ role on all my projects. That person becomes the gatherer of all the things that pose risk to the project, ensures they are all examined in terms of likelihood and consequence, and that, for those that are sufficiently likely with material-enough consequences, there is a risk-mitigation plan in place. That plan should reduce the likelihood of failure, the consequences of failure, or both. The risk officer is also accountable to actively track all risks, reassessing at regular intervals the catalogued likelihoods, consequences, and suitability of mitigation plans, and removing risk events from the list when they are no longer applicable (the event / circumstance has passed). This role should not be done by the project manager, as the two roles have two different mind sets – the project manager is striving for everything to go right, and the risk officer is looking for everything that could go wrong.
So how did my risky project go? Well, the failure event happened – the software wouldn’t do what we wanted. It became clear during a training course attended by three of my US finance colleagues and myself in San Francisco. So, likelihood of failure became 100%, and the consequences of failure were forfeiture of the money we’d spent to date of the software licences (we had to buy them to take the course), travel costs for the four of us, and our time. And, of course, my reputation.
But, being the decent risk manager I was at the time, as we were negotiating the purchase with the vendor, I had been up-front with them in terms of my reservations, and had some frank discussions about options should the software not do what we wanted. This particular vendor had another software tool for multi-dimensional modelling. It wasn’t sold as a budgeting tool, but from my discussions with the vendor, I had a pretty strong feeling it could do what we wanted it to do. I negotiated as part of the licence purchase not only a ‘money-back guarantee’ period, but also the ability to switch with no penalty the license to this other tool. I also got all the specs on the other tool and read through them all. And, the vendor was on alert that we might make the switch, and had people in San Francisco that could show us the other tool if we needed to see it while we were there. So, when the failure event happened, and my colleagues were a bit anxiety-stricken with how to proceed (the CFO was ready to just end the project and go back to Excel!), I put my contingency plan into motion, got my three colleagues to review the other tool with me in San Francisco, and with the realisation by all of us that it would do the trick, I convinced the CFO to make the switch and we kept going! My risk mitigation plan didn’t reduce the likelihood of the failure event, but sure did address the consequences, and the project continued and ended successfully.