Over the years I’ve heard stories from peers and read them online about the very ordinary experiences they had as IT workers. I’ve even experienced it myself. A common theme is that the IT department is only performing a maintenance function, often called Business as Usual (BAU), operations or break-fix work. Being in that position can be very dangerous.
IT is perhaps one of the few industries where we are capable of performing a maintenance function and a business improvement function. When performing the maintenance function, we’re simply making the Widget Machine tick over. It’s not any different to the sort of other maintenance work done, such as replacing broken light bulbs. However, we’re also capable of making the Widget Machine run better and faster, or make new kinds of Widgets that the business can sell to a new market.
What I’ve observed is that often the BAU-only existence of an IT department can be a chicken or egg situation – was it caused by the sort of outcomes you get from this model, or did the model cause these outcomes? No matter the original root cause, it tends to create a quagmire of problems that can’t be easily resolved without major will by management. Some of the issues and results of a BAU IT department I’ve seen include:
- Groundhog Day Incidents – These are incidents that happen again and again and again. The same thing breaks and has to be fixed. The causes of this can be varied, from chronic under-staffing/mis-staffing to a lack of a good problem management/continuous improvement function. The result is the customer rolling their eyes when you turn up to fix that issue for the 5th time that week
- Increased Risk & Technical Debt – Many organisations will initiate the refresh or replacement of a system via a project. The BAU-only IT department never gets to attend to those, meaning systems are literally flogged until they drop dead, often well past any warranty or support period.
- Stagnation in Strategic or Value Adding Initiatives – These pieces of work are the big projects that align with business goals and the strategic plan. They help the business make money in better or new ways, improve processes and the like. Most if not all of them are delivered via project teams. These big pieces of work are the ones that really let IT show its value to a business. When you don’t do them, there’s not much value to show
- Bad Blood – In every case I’ve worked in an environment such as this, the relationship between IT and the business has been of various levels of toxicity. From this business side, this can take rather overt forms such as staff openly talking badly of IT and “starve the beast” style budgets. Less subtle forms include relegating the IT team to the worst seating in the building. In these situations, you can almost hear senior management saying to each other “We pay all this money for IT, what do we get?”
These issues don’t just create themselves, there’s always causes. Some of the causes or contributors to this problem that I’ve seen are:
- Complacent IT staff – If you wanted to do the most basic separation of IT staff, there’s ones who are curious and those who are incurious. The curious ones are the ones that might say “Hey I was thinking we could do this process a better way”. The incurious are content to beat their head against the same spot on the wall. They offer up no desire or drive to improve the customer’s experience or their own.
- Staffing – This can either be an issue of under-staffing (not enough) or mis-staffing (not the right type or depth of experience). In smaller organisations, the first is common because the team is quite small and doesn’t load balance well in situations (if you have 4 people in your team and 1 is sick, suddenly 25% of your capacity is gone). I’ve seen the first and second happen in companies that have grown rapidly – the under-staffing happens due to the focus on growing the business and the IT staff levels haven’t caught up to the needs, and the mis-staffing happens because the skill sets and processes that were appropriate for a 200-person company isn’t appropriate for a 2,000 or 20,000 person company. This certainly isn’t an issue specific to IT, I’ve seen it happen to HR and finance sections too. The under-staffing tends to cause the IT department to be on a knife’s edge of barely having the resources to deliver on their BAU workload, so project work is never given a second of thought.
- Budget – A very long time ago, I was told that a company should be spending roughly 3% of its revenue as its IT budget. In a report by Gartner from 2016, it showed that US Healthcare providers on average spent 4.1% of their revenue as IT budget. The North American average across all industries was 3.5%. In both cases, only 70% of this was assigned to the strategic category of “Run the business” which could reasonably assumed to be BAU functions. “Grow the business” and “Transform” the business accounted for the remaining 30%. The 3% model probably works if there is a certain amount of that funding going into non-BAU work, which tends to make IT work better if done correctly. Often chronic under-budgeting of the IT department results in the staffing issues, as well as leaving little money left for any tools or minor implementations that may improve things.
- IT Management – In some cases, IT management can play a contributing part in the state of things. In the case of one scenario I was told about, the IT manager ran his department on the premise of spending as little money as possible (regardless of the value of any outcomes). This was his metric for success. At a more micro level, another IT manager refused to allow the company’s domain names to be renewed because the process would be a full yearly cost (about $70) and he would prefer to save what would’ve amounted to a fraction of that cost at the expense of losing a single date to handle the renewals (and potentially increasing the risk of a domain renewal being “forgotten” about). In other cases, it may be the person in this role not being able to sell the case to senior management of the value of IT. Often making a good business case around an IT project or initiative can be hard because of a disconnect with the mission statement, values or strategic goals of the business.
- Organisational Management – Finally, it may be coming from the top. It could be a variety of reasons – they don’t see the value in IT, they’re happy with how things are, the relationship is so poor they won’t entertain the option, they’d rather put effort into another areas of the business and so on. What it means is if all the other factors on this list within our control are good, we’re still damned if this item isn’t good.
As the “do-ers” in the IT department, we’re constrained on what we can do to address those sort of problems. There can be some self reflection about whether we are overtly contributing to the problem (in some cases, the answer to this is yes). We can try to do some quick wins to improve efficiency and hopefully free up resources to start addressing projects. In one situation, I attempted to do this – I reviewed a 1 month snapshot of our work and concluded that around 30% of the tasks could either be removed outright or could be pushed back as a self-service task – these were things like resetting a password, unlocking accounts, setting a user’s email and printers up when they logged into a PC for the first time. In hindsight I presented the idea poorly, without making it clear that our 30% freed up resources could now move onto our massive projects backlog. So sometimes that approach works or doesn’t.
More often that not, the change or “fix” for this situation is things reaching breaking point, usually in the form of a major incident that forces the organisation to re-examine how IT is operating. Sometimes the outcome of that is improvement.