We have known for a while that there is no such thing as an ‘IT project’. We have known that there are business change projects that involve IT, and that one reason for failure is to treat change projects as IT projects because more than half of the success of even the techiest of projects is around people and process change, not the technology.
We have known that a good CIO really understands the business they are supporting. Broadbent and Kitzis noted in their book, The New CIO Leader, that the two people in an organization that have the broadest understanding of all elements of the business, both front-of-house and back office, are the CEO and the CIO. And yet it seems these two people simply do not speak the same language.
I lead a program of work looking to support digital readiness for organizations and staff in the English National Health Service. Following the publication of a report into the impact of technology on the healthcare workforce by Professor Eric Topol, we have concluded that we simply have no alternative but to create a digitally ready workforce in our National Health Service. One of the key aspects we have been focusing on is the creation of a culture of permissive experimentation as a key component of organizational adaptability, through board development. Time and again our CEOs are saying that digital is a risk, not an opportunity, and one they do not understand. Their response to this lack of understanding is to hire a CIO who, it turns out, cannot speak the same language.
I completed a postgraduate diploma course in Digital Leadership recently through the NHS Digital Academy. As part of the coursework, we were all asked to undertake a ‘pitch to the board’ challenge where we were to make a case for £50 million of investment for a region-wide care record. As I watched myself and my peers prepare and present I recognized the pressure, I felt under. It was familiar.
I saw the colossal investment I was asking my (fictitious) organization to invest. I saw us, as a group try and think through every eventuality, everything that potentially could go wrong, every uncertainty. I saw myself think through my case through someone else’s eyes, someone naïve to the world of digital. Together we prepared arguments, plans within plans (“and this is what we will say if they ask us *that*!”).
It was only whilst we were in the presentation itself that I realized what we were doing. We were contributing to this language barrier.
I saw myself prepare a case to get to one outcome—approval to spend. I saw the big difficulty being the agreement to start the project, not the intensely difficult outcome we were trying to bring about. I prepared arguments to get the board to commit the cash; I did not prepare to help bring about a bigger understanding and a sense of ownership.
During the presentation, I had a sudden realization. In trying to alleviate concerns about tech limitations, return on investment, partner motivation, and governance, in preparing to demonstrate that we, the tech team, understood, and had plans to mitigate all the risks, we systematically disinvested a team of very capable executives from any sort of stake in a £50 million enterprise. Our subtext was clear—“this is an IT project, do not worry your pretty little heads about it. We have got this.”
This is what I learned: It is not my job to get the business case approved. It is my job to partner with the business, at the highest level, to explore, write, and co-own a business case. It is my job to ensure the unknowns are described. It is my job to help point out the biggest shortfalls, from the position of experience. It is my job to help the business achieve its end goals best.