Pointing the finger – blame and risks in digital project management

There are many aspects during a digital project that do not go according to plan; even if you had one. Project Management is about control but, particularly in digital projects, your clients and your team can often seem to conspire against the progress of the project. Your management, on the other hand, are meant to be there supporting you. If this isn’t the case, you’re in trouble. Are you in a company that has an attitude of ‘sacrificial accountability’?

It is common that if and when things go wrong, someone takes the blame and resigns from his/her post. I think that most people view this as acceptable when it is clear who has had the overall accountability during the time that the problems brewed and blew up. But looking for the sacrificial lamb is another thing entirely as John Linwood, ex BBC, found out. He was Chief Technology Officer for the BBC when the plug was pulled on a £100m Digital Media Initiative project. He took the BBC to a tribunal for firing him and won because they believed that the Senior Management were dodging the blame and placing it on Linwood.

John Gough in Avoiding Blame for Botched Projects, (undated 2014), summarises the Linwood story and points to internal company politics as a driver. We all know company politics and how it can invidiously dominate decision-making. How’s your company for this?

The risk of being sacked as the accountable one is real but companies are beginning to understand that they need to get on top of risks before they cause trouble. Enter the Digital Risk Officer. Have you heard of them or seen a job advert for one? You may well find you have to relate to them in your client companies. Apparently, these people will be hot news in 2015 according to Gartner research 2014 . Now this is in response to security issues and technology as companies realise that with the plethora of technology-driven channels of communication and the increasing use of them by the public at large, that the risks of service failures increase. It will be interesting to see if these officers are increasingly used as easy target sacrificial lambs by their companies when things go wrong! But if you meet them as part of the client-mix, you can be sure that they’ll make strong demands of you making your job more accountable too.

Now you’re in the mindset of blame, perhaps you need to become aware of a nasty blow coming from an unseen upper-cut! This has crept in from the side of a legal ruling about blame in a service contract. The original case was about pipes and little to do with digital project management. (See, The Best Practice Group, Your Service Provider’s Duty to Warn, by Alan Watton (23 January 2012) But as the ruling can be generalised to all service contracts, we need to take note. The judgement found that the contractor (expert) should have warned the client about the possible risks in the project because they as the experts were in the position to know the possible impact on the clients while the clients as non-experts – and the very reason for using the contractors – were not in the position to understand the impact.

The key concept is ‘a duty to warn’ about the risks pre-contract and during the life of the project and exists independently of written clauses. You have to account for what your advice does and does not cover. You have to be clear in writing about what your advice does not cover and what your proposed solution does not cover including any possible consequential impacts. Well, that’s a tall order in our uncertain digital world. You need to throw this concept to the legal bods who draw up your contracts as service providers. Now if you are too small to have a legal section, check if the templates you use for contracts cover this angle and raise any queries with your management.

You’ll probably do a lot of ‘warning’ without realising it. So, for example, if you recommend that your client should do some pilot testing with users to check the system out and assess its impact on the project objectives pointing out to them the pros and cons of this, then you are warning them of the possible negative effects/risks. If they take the decision not to do this, they accept responsibility and accountability. Likewise, you’ll probably be recommending various types of testing from stability to security, for example. You can indicate the pros and cons of all of them, so if the client chooses to ignore your advice - because of lack of budget maybe - then you have fulfilled the ‘duty of warning’ principle.
Blame is not a nice topic in any field. Better to be prepared though.