IT train-wrecks and how to avoid them
By Roland Maxwell
A couple of years ago, I was facilitating a workshop of corporate leaders for Russell Yardley’s The Resolution (an excellent resource for all things Boards and Governance, by the way - see https://www.theresolution.com.au). The workshop included former Labor MP Lindsay Tanner. He made the comment that there was one area in which there was absolute bi-partisanship, and that was IT stuff-ups. There was general laughter, nodding, and wry looks around the table. Government may well have a leading edge in this department, but not a monopoly. Many organisations have lost heavily because of failed IT projects, or are dragging a sea-anchor of inappropriate technology.
It starts with the CEO
Software choices are structural organisational choices. CEOs cannot claim that “IT is not their thing”, any more than we would accept CEOs who said they didn’t understand finances, or were uninterested in HR. All software involves embedded business processes, and will impartially enforce inefficiency and bad process as readily as productivity and good process.
It continues with other people
Good systems of work involve a judicious interaction between people and enabling technologies. Striking the right balance between human-mediated processes and technology-mediated processes is key. People are happier when they feel that their jobs are meaningful and productive. Design good jobs for people into your IT systems, and make sure that you have also respected your audiences (customers, supporters, donors etc), and valued their time and desire for good process.
Be clear on the focus of improvement
Any IT project is a process-improvement project, so be precise about what you are improving. If you are specific about the cost of the current situation, and the benefits intended to accrue from the project, it becomes much easier to see if it is worth the investment.
IT service providers are often adept at capitalising on organisations’ fears of being left behind, and on painting a rosy picture of the future state. Don’t be gulled by the marketing ’bow-wave’: look for measurable, nuts and bolts benefit to your organisation.
Specify outcomes, not features
Many organisations frame a Brief in terms of a feature list. This approach puts them at a disadvantage, as anything that wasn’t on the initial feature list can trigger a cost-variation. Some IT companies rely on being able to charge variations, understating the real costs of the project up-front, on the expectation of being able to justify additional payments once they are in the door. (IT suppliers are not alone in this.)
Focus on defining the destination for your organisation, and require the supplier to use their professional judgement to achieve it. By analogy, if you were employing a builder to renovate your bathroom, you wouldn’t expect to have to specify the quantity or type of copper pipe to get the shower working: that’s their job.
The role of Enterprise Architecture
Enterprise Architecture provides a framework by which to optimise the systems of work that are used to achieve your goals. A clear framework helps to avoid duplication, and makes it easier to make decisions that are consistent with prior decisions, and to respond to new opportunities.
What is Enterprise Architecture?
ISO/IEC 42010:2007 defines “architecture” as:
The fundamental organisation of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
Architectural vision
The aim of the architecture should be:
to shape a successful organisation
to provide a robust basis for ‘business as usual’, which makes it easy and enjoyable for customers and staff to be productive
to enable the organisation to be agile in its choices, with the ability to experiment without undue risk or expense
to offer a set of principles that make it easier to innovate wisely
to maximise the capacity of the organisation to achieve its mission.
Design with flexibility in mind
I became frustrated with the lack of terminology to describe the approach that I consider optimal, so (with some apologies) I have invented my own acronym, appropriating the old radio call-sign “WILCo”. According to me, WILCo is short for “Well-Integrated, Loosely-Coupled.
Well-integrated
When people use the system, it feels coherent and whole. By integrating the components, we:
create a coherent system of work
eliminate unnecessary variation
reduce manual processing i.e. if applications that acquire data can share them with other applications, this makes the system more efficient, and reduces opportunities for error
improve learnability of the system through processes that are as simple as possible to achieve the required business outcome.
Loosely-coupled
In a close-coupled system, major effort is needed to change any component. For example, a human body is a close-coupled system, in which the attempt to replace an organ is risky and complicated.
By contrast, a loosely-coupled system allows for components to be swapped in and out, without affecting the health of the rest of the system. This makes upgrading the system easier and less risky. For example, a bicycle is a loosely-coupled system in which the task of replacing essential system components, such as handlebars or pedals, is low risk and reasonably straight-forward.
Never buy the whole package
I will conclude with words of wisdom from my father: “Never buy the whole package”. He was referring to people’s uncritical attachment to ideas and ideologies. The same applies with IT systems. There is no package that will do the whole job. Just as you assemble a workplace team from a diversity of people, your IT systems will be assembled from diverse components. Be deeply suspicious of any supplier who claims their system can do the whole job. Credential any new system as carefully as if you were appointing a new member of staff. They must be productive, nice to work with, and worth paying them the wage.