For a young industry with comparatively little history it is amazing how often the lessons of the past get repeated in ICT. It is almost as if many IT executives have a death wish. You see them embark and continue on journeys where all the evidence is that it will end in tears and acrimony. Yet somehow they seem to believe that for them things will turn out differently. This is despite the fact they know that if and when things turn to custard it will always be known as a failed IT project, not a business one.
From my thirty years in the ICT industry I can identify at least four examples of this phenomenon. My favourite example where IT departments set themselves up for failure is implementing any software product that has a .0 in the release number. Years and years of IT experience should tell anyone in this industry that the first release of any piece of software always has a bug. Why should your users have the frustrations of being the first to experience this bug, especially if you have paid for the software? You may well have users clamouring for some feature in the software but the grief you will encounter if the new release is unreliable will be much greater. The bugs will hit the users when they are dealing with clients and new sales opportunities. They may not thank you for it at the time but taking a conservative approach to software upgrades invariably means that your operational systems will be stable and the users can get on with their jobs unimpeded by any software glitches.
My other examples revolve around project management which I believe is probably the most critical requirement for the CIO role. The first of these is where the end users continually fail to turn up to the ICT project steering committee meetings. While the occasional nonattendance of key business executives is understandable their repeated absences is surely a sign that these personal have higher priorities on their agenda. Yet it is rare to find a CIO with the courage to then close down the project. Without the active involvement of impacted end users they must know it is unlikely the delivered systems will satisfactorily address their requirements. Furthermore, without this it is highly improbable that they will have any sense of ownership of the systems that get delivered. As such the CIOs will be setting themselves up for a failure that is likely to haunt them for many years to come as they end up supporting and modifying an unloved business system that no one embraces.
Despite this, it is common to find IT departments persevering with such projects. Somehow, I suspect, many CIOs seem to feel an obligation to carry on. They may think that given the money for the project has already been allocated and that there has been a significant investment of time on it this is what is expected of them. However, my observation from discussions with CEOs is that they would much prefer to have a CIO with the courage to stop such a project at such times than one who is willing to gamble ongoing resources for an outcome that is likely to be unsatisfactory.
In a similar vein another of the examples of where history repeats itself in the ICT industry is when CIOs persevere with a project after the key executive sponsor has left the organisation. All projects need a key executive sponsor if they are to succeed. This is the person who recognises the need for the work. This is the executive who convinces their peers to allocate money and people for the task. However, such executives usually have a personal commitment to the work that ensures they drive it towards the outcome they desire. Corporate history shows us that such commitment cannot be easily replicated by the person that replaces them. On the contrary, it is human nature to try and stamp your own mark on a new role you take on. This means, usually, you actively disown anything associated with your predecessor. At the very least CIOs should recognise that such a circumstance is a trigger to halt a project, at least until a new sponsor has accepted stewardship for the activity.
My final example of where CIOs fail to live and learn is in the area of change management. The empirical evidence from the track record of IT projects all points to the same conclusion. The bigger the project the more likely it is to fail. Nevertheless, there is a remarkable enthusiasm among many IT departments to bite off more change than they can chew. The Standish Group’s long-standing and continuing research highlights that the most successful IT projects take less than six months, involve less than six people and cost under $750,000. Why then do I keep reading about proposed multi-million dollar IT projects that are going to be delivered several years in to the future? Perhaps it’s just bravado. The growing popularity of Agile as a development methodology may well indicate that more and more IT departments are digesting the elephant of change in bite sized chunks. Yet I get the impression that the temptation to be a change hero for some CIOs is still far too strong.
A CEO once complained to me that the problem he experienced with CIOs was that they were too conciliatory to requests from the business. He said he would have much preferred an IT department that was much more willing to challenge any requests from end users rather than one who unwisely embarked on projects whose chances of success were slim. He argued that not only were money and time lost on such ventures but also there was an opportunity cost of missing out on other projects which could have been successful.
I know a common frustration for many CIOs is overcoming the poor perception of it held by many in the business. However, as the saying goes, “God helps those who help themselves” and that means CIOs need to be assertive about which projects they decide to support. If they don’t then they will end up finding out that the truth of another popular saying – “those that don’t learn the lessons of history end up repeating them”.
0 comments:
Post a Comment