Educause 2009 - Learning from failure ...

I've always thought that failure was under-rated and that the best way of improving things was to pay attention to when things went wrong and learn from the mistake. The trouble is you have to do it carefully, otherwise everyone starts getting anxious and muttering about blame cultures. So, I was quite excited when I saw a session at Educause entitled "Houston, we have a problem - Leading through Failure"

The presentation was from a group of senior manager's from different HEI's who all felt that learning from failure was very useful and worth talking about - they described it as 'rich learning'

The session started with a short video from Honda http://dreams.honda.com/videos/failure-the-secret-to-success/ talking about the culture within Honda of encouraging failure and risk taking in order to achieve extraordinary success - it's worth watching.

Each presenter talked about a separate example from of where failure was a really useful learning experience for them.

The first presenter talked about a failure caused primarily by not understanding the context of a project. His advice, to check every so often that you are taking a macro view of the situation. Risk looks a lot smaller and a lot less risky the further you are from the situtaiton. A risk embedded within a single project looks huge to someone in the project team, but is insignificant and possible well worth taking from the view of the VC. It is certainly true that within some of our projects, especially the big strategic ones, we do not always step back often enough to look at things from our customers perspective - and as a result we get caught by surprise with demands for things that we think we are already delivering. Note to self: when it goes wrong, spend more time looking at what has gone wrong and why and learn from it.

A speaker from the University of Hawaii talked about a huge project to put in place a new campus student information system and then the vendor left the project at a critical stage. The positive consequences of the failure was the way in which everyone else, spurred by panic initially, pulled together into a team in a way that would not have happened otherwise and the project plan acted as the stable 'skeleton' around which they could motivate and pull resources together, with more trust and better communication, and they succeded. Fail to plan and you plan to fail, as someone later quipped.

A university librarian talked about a project to tackle running out of space for books. DiscusTo him it was obvious - we have to get rid of the old stock that we no longer use. This was not obvious to everyone. Discussions with stakeholders made it clear that to some the obvious solution was 'let's build a new bigger building'. Key lesson - different minds make different decisions - make sure that everyone understands what the decision actually is. His experience was that although spectacular failures are often the best learning experiences - spectacular failures are often not as spectacular as you might think. One vocal critic can make the failure seem huge and create a lot of fear, but actually they are just one voice and other quieter voices may have a very differrent view.

The next speaker talked about the role of assumptions. This was a portal implementation. Everything was looking good, there was a plan, there was time, it all looked on track. But, after roll out new faculty staff couldn't log on, and there were a lot of them. The HR process for provisioning new accounts was not working in the way that the project had assumed it had. Although assurances had been given they had been given by individuals who did not have the positional authority to follow them through. The lesson learned - watch the assumptions, and watch whose making them and based on what information.

The next story was a 'tale of woe' about a Graduate Admission Application Form that was going to be redesigned and made into an on-line form. There was a perception amongst Faculty that IT were not going to be able to do a good job as they did not provide Faculty with the support and help that they wanted on a day to day basis. So they decided to do it themselves (sound familiar?). As you would expect there were data integration issues, not enough testing, when they asked for help from IT, as you can imagine, tempers flared. Faculty admissions staff thought that IT are being unhelpful and IT thought that Faculty admissions staff are being unreasonable. This went on for two years. It is now up and running but the legacy is a lot of hard feelings. So what are the lessons from the failure? It started because of a perception that IT was inadequate and it was exacerbated by an attitude of do first and ask later, total lack of communication and egos. You have to really look out for the warning signs that communication is not happening, or is happening but is not going well - body language in meetings? failure to return calls and answer emails? lack of any face to face discussions?

I asked the question I started this note with, about how do you manage to create a culture where people are willing to investigate and understand what went wrong in order to learn without seeing it becoming, or being perceived as, a blame culture. Responses from the presenters included ensuring that you are up front about the fact that things have gone wrong and make it clear that we need to get past the 'finger-pointing' and on to the more productive discussion around how do we learn from it. Also as a leader making it clear that if it all goes wrong you will take the wrap and if it all goes well the team will take the credit - something which I completely agree with. But you need ot make sure you don't just say it but follow through if an when it happens.

Another questioner pointed out that continual honest communication is key to all of it and a common thread across the presentations.

I thought it was one of the best sessions at the conference - and it is great to see people talking about the things that didn't work well. Usually the conference sessions are all about the success stories and the best practice case studies - but it's the failures that we learn most from. On Monday, back at the ranch, we have the first meeting of our new, reconstituted, IT governance group and having some honest conversations about why the previous governance group failed will be a very positive initial step towards increasing the chances of success second time round.