John Linwood, the BBC’s former CTO who was sacked by the corporation following its decision to scrap its £100m Digital Media Initiative (DMI), recently won his claim for unfair dismissal.
The tribunal delivered its unanimous verdict that Linwood’s claim was “well founded and succeeds” although it did also state that he had contributed “to the extent of 15%” to his own dismissal. It should be noted though that this 15% was primarily related to Linwood’s responsibilities as a senior manager and member of the initiative’s steering group as opposed to his role as the organization’s technology leader.
The 66-page document that explains the tribunal’s ruling makes it clear that Linwood was in effect selected as the person that would be held responsible for the project failure – with the BBC still reeling from a number of high profile incidents and scandals, senior management needed someone to carry the can. E-mail correspondence between BBC executives shows how Linwood was identified as the person who would be blamed and how they then attempted to gather evidence to support this decision.
The main objective of the DMI was to create a digital production system linked to the BBC’s archives and hence eliminate the need to use tapes. This would allow BBC staff to access historical footage from their desktops instead of transporting tapes to and from the corporation’s physical archives. Clearly technology was a key component of the project but as with any major initiative there would also have been some fairly significant people and process changes required to realize the project’s objectives.
But not surprisingly when the organization needed a scapegoat the technology guy became the obvious choice. And so what had started out as a transformation of the way the BBC works with video footage quickly became a failed technology project. This is not a new story, however. IT functions and CIOs have regularly carried the can for project failures, whether they were to blame or not. Although in many cases it does not result in the CIO being dismissed it will inevitably damage their reputation within the organization, cause them to be side lined or bypassed, and limit their opportunities for progression.
In his claim Linwood cited changing specifications and unclear vision and leadership as being some of the primary factors for the problems encountered by the DMI. Again, this is not a new story. Changing requirements, and a lack of vision and leadership from the rest of the business are commonplace in many change projects. As is the failure to understand and implement the people and process changes needed to realize the benefits of a technology investment.
I have previously told a board who had given me approval for a multi-million pound IT investment I would rather not spend the money if the rest of the business did not fully understand and commit to the wider people and process changes necessary to realize the benefits of the new technology. Laying new technology over old processes, methods, roles and attitudes is never a good idea; it will always lead to problems, resistance and eventually a perception of a failed technology project.
Too many (non-IT) executives just do not appear to understand that new technology alone cannot transform a business. How many times do users arrive for training on a new system and complain that they do not know why they are there, do not understand why a new system is needed and with limited or no knowledge of the people and process changes that are also going to be needed? And who is it that has to deal with these complaints? Usually it is the IT department or the technology partner providing the system. So the lack of leadership from the rest of the business and the lack of wider business change activity becomes an IT issue. When the new system goes live and meets resistance from the staff who have not been prepared for the changes, it becomes an IT issue. And, when the rest of the business realizes that it has not specified its requirements correctly or that the new processes do not work in practice and hence system changes are necessary, it becomes an IT issue.
As the project descends into a cycle of requests for change, operational issues, budget overspends, low staff morale and claims and counter-claims between executives and partners, what started as a major business change initiative very quickly becomes a high profile IT failure. It does not always happen that way of course. Some organizations understand what it really takes to effect change; they understand that technology is only ever one component of a change initiative.
But sometimes the IT function does fail; it does not have the right skills or controls, selects the wrong vendors, underestimates the complexity or time required to build a new solution or underestimates the costs. And in these cases the CIO should take their share of the responsibility. But too often though they end up having to shoulder the blame for failings elsewhere in the business.
People and process change is difficult; it requires specific skills, resources and time in the same way as technology changes do. It cannot be done in addition to the day job, and neither can it be done as part of the system training.
The move to digital brings even more technology-enabled change. Successful digital businesses create digitally enabled products and services and they also transform the organization to create entirely new business models and ways of working. Digital is about reinventing the organization, looking at the business from the customers’ perspective and building an operating model, capabilities, processes and systems that are driven by customer needs. Organizations that struggle to implement change in the old world are going to find life in the digital world even harder. And that could mean more CIOs find themselves carrying the can for failed digital initiatives in the same way as the BBC made Linwood its scapegoat.
So what can CIOs do to avoid becoming the next Linwood? They can educate their colleagues about the importance of the people and process changes, they can help identify those changes and they can even employ specialists in those areas to support other business functions as they implement the changes. But they cannot take responsibility for changes in other functions; ownership for each change has to be clearly identified, documented and understood. CIOs should also regularly report on any people and process issues that are impacting the technology changes. And, at the first sign that the project may be failing, they should alert the steering group and wider executive team.
John Linwood was unfairly treated by the BBC; he was singled out to take the blame for an organizational failure. A business project enabled by technology went wrong so the technology leader was blamed. If other CIOs want to avoid being the next Linwood then they need to ensure their colleagues identify, understand and own the wider changes that are needed to make any business change initiative succeed.
via CIO: could you be the next Linwood? – The CIO Leader.
CIO: the scapegoat?
