To misquote Seamus Heaney horribly – “I think IT systems are generally speaking a preparation for disappointment”. But does it have to be this way? There is a significant body of research on why IT projects can fail and how they can be rescued, but there is far less insight into how to avoid the “disappointment”, especially at board level, of systems not delivering significant benefits over the long term. Large IT projects obviously can and do go in successfully, on time and on budget, but often they don’t deliver either the stated business case benefits or their strategic objectives. Having recently deep dived into the reasons for failure and organisational readiness required for both ERP and CRM it’s still quite depressing to read the case studies on “disappointments”. Whilst total IT project failure rates are generally less than 20%, “partial” project failures can come in well over 50% and this has not changed over the last twenty years.
Ignoring the fact that business cases can sometimes be essentially carefully crafted works of art when securing initial investment, the reasons for longer term disappointment and even ennui are more difficult to unpick. Failed IT projects can have a number of obvious elephants in the room that explain their collapse e.g. lack of executive sponsorship, woolly scope & vague requirements etc. but it’s harder to unpick why systems investments under achieve in the longer term. Expanding on the animal analogy, factors for explaining under achieving technology investments could be characterised by a room full of lots of very small angry animals that disappear when you put the lights on.
Some candidates for improvement could be: –
1. Applying the discipline of lessons learned and post project review continuously throughout the life of a system. Insight can be gained by using these techniques on a periodic basis. Project team responsibilities will of course have to be transferred to operational and technical owners of the system.
2. Focusing on benefits realisation in the long term. Business cases are often viewed as start-up documents rather than something which can define and drive benefits realisation in the longer term. Business cases should focus more on defining what success looks like say in three year’s time rather than a tick box exercise for getting projects through financial approval hurdles. Business cases need to obviously state clearly the measurement of both costs and benefits over time but additionally the specific actions, timelines and responsibilities for both owning the delivery of benefits and managing their strategic review.
3. Implement principles of business systems ownership as part of project close down. How the relative operational and management responsibilities are allocated to nurturing these key assets post implementation is vital. Business system ownership can often be overlooked in the latter phases of projects. Systems ownership responsibilities can be split into discrete activities, some wholly owned by the business, some wholly owned by technology, but many which are jointly actionable. Whilst the tech and business operational duties can be performed well the monitoring of success at a management level can sometimes be short changed.
4. Plan to manage data strategically. Data management is a discipline that is still seen by many as a dark art. It’s often under resourced, stripped down to “data standards and data cleansing” and can go ignored even in quite large organisations. Data quality in particular can be a bit like the first Mrs Rochester banging around in the attic. We know it’s there, its mad, its bad but we don’t quite know what to do with it. Upping the strategic understanding and principles of data management at senior IT management level is a first step.
5. Don’t forget the users! Engaging users, through for example formalised user groups, is a relatively easy way of securing user feedback. This type of activity can however slip off the radar once systems are 2-3 years old. An injection of management and operational attention can yield unexpected insights into longer term demand and produce a more strategic road map for enhancements. Also keeping user training materials up to date is an obvious if not mundane necessity. This can have however have a major impact on system integrity if its overlooked. Many original users of the system may have moved on and new starters can struggle with using systems if good guidance isn’t to hand for their induction. What started with a heavily trained and skilled user base can quickly over time dilute into many users stumbling around systems in the vain hope of pressing the right button. User guides were once hugely onerous to maintain but recorded user sessions are quite cheap and quick to do and can help users enormously.
Underpinning many of these challenges is the requirement for technology and business to work closely together, post project implementation, at both an operational, management and strategic level. There are obvious inter-dependencies and shared ownership of these issues and what’s striking to me is that many of these problems exist on the tricky and sometimes vague “borders” between technology and business operations. Without clear definition of roles and objectives the issues can inhabit a foggy hinterland that can go largely ignored. Technologists, understandably, can sometimes be reticent about straying into what they see as business responsibilities and vice versa with the business and of course it’s yet another set of things to do. Yet, without acknowledging the fact there might be a problem with data, system ownership, user engagement etc. technology investment may continue to disappoint. The application of the “marginal gains” approach to each of these areas might start to deliver some benefits. Additionally, piloting some focused activity based on the areas identified above might at least start to justify allocating resources to tackle these issues at the strategic level. Ignoring them could just ultimately lead to perpetual disappointment.