Part 1 – Introduction

How “IT” began

While the idea of an IT department feels quite modern, the actual idea is pretty old. Since the 60s and 70s, organisations have been using computers to do some of their back office tasks – accounting, payroll, transaction recording, stock control. The systems were big, complex, usually running on mainframes and they were generally considered support systems for the business. They required people to operate, upgrade and maintain them so rather than have these support functions in the business, just like we did for other support functions, an IT department was created as a cost centre to house them.

This pattern served us well for a long time. Right through into the 90s – the systems got more and more complex, they shifted off mainframes into data centres, and IT continued to manage them. They may even have managed your corporate website if you were really modern. But they still remained a support function. The “real work” of the business still happened elsewhere. IT could still be managed as a cost centre. 

Modern day “IT” dilemma

Fast forward 30 years (Yes, 30 years since the 90s… it scares me too) to where we are now and things are different. We still talk about “business” and “IT” but that’s no longer really the case. IT is no longer a support function. It is your primary channel for connecting with your market. Everything you do in your business now relies on IT to happen. IT no longer supports your business. IT is your business.

The structures that served us well for so long are now holding us back. Keeping IT and Business separate gives us a host of problems. For a start, there is the classic communications wall that grows up between the two. Business tells IT exactly what they want them to do, then IT builds exactly that. Regardless of whether it’s the right thing or not. Everything is specified upfront because it needs to go through the “IT process” – Business comes up with an idea and asks how much it will cost and how long it will take. IT, wary of giving an estimate because they have been beaten so many times in the past for poor estimates, demands a detailed, unchangeable spec. This leads to a detailed design to get funding approved and so on. In the meantime, the user’s needs are evolving and what ends up getting built is no longer relevant. There is no room for agility in this model. By the time the work hits a team, it has been fully documented and all the teams can do is split it into 2 weeks sprints to deliver.

“IT” takes on the shape of a village

We have all heard this story before, and a lot of organisations have tried to tackle it. – They bring IT and business together into Villages, or Release Trains or Tribes. This improves communication and gets rid of a lot of those problems. Job done then? Add some scaled agility and everything is fixed?

No. This doesn’t fix the underlying problem. What many organisations find is that although their Trains/Tribes work well, they still can’t get things to market effectively. They still end up with long drawn out processes to follow before the work gets to the delivery teams. Once the work is in the delivery teams it flows much better than before, but at an organisational level, nothing much changes. One large organisation managed to cut the time it took for their teams to deliver a feature in half. From 4 months to 2. That sounds great, but it saved them 2 months. Out of an 18 month process. It still took a full 14 months. More than a year, for a business idea to make it through the business case process to the delivery teams. All we have done is move the communication problem from the specification to the business case.

“IT” dilemma as an accounting problem

The real problem is that on the books, business and IT are still accounted separately. Business is a profit centre and IT is a cost centre. So for IT to do any work, they need to justify the cost while the rest of the organisation is keen to keep costs to a minimum to improve profits tried to minimise that cost. IT groups generally end up highly budget constrained with little or no discretionary spending. If someone comes to them with work that needs doing, they had better come with money as well, or bad luck. No matter how important, no money, no work.

Business teams often have more generous budgets and discretionary spend to cover investment in the business, but not if that investment goes to IT. That’s still a cost centre, and we have to justify every penny spent there. So the business needs to produce a business case to justify giving IT some money to do some work. Usually, that’s done project by project or through some other accounting mechanism like an annual business case. Either way, it’s slow and inflexible. If a business needs more work done, well, sorry, wait for the next budgeting cycle. If they need IT to add people to do more work, they can’t because they aren’t fully funded for the next year, so they can’t be hired and besides IT has a headcount freeze on at the moment to keep a lid on costs.

How “IT” has responded

On IT’s part, because they have to watch every penny and because they have been whipped for the last 50 years because of overspending due to poor requirements, they are reluctant to give any sort of estimate on anything other than a fully specified piece of work which ensures that a lot of design and specification work is done upfront at business case stage. And IT will push back strongly on any changes to that agreed scope because they know that any extension in duration will cost money, and they will be blamed for the overspend. Your features and epics will arrive at your newly minted agile delivery teams, having spent months in design already. With no room for negotiation if information changes, and no real ability for the teams to own and discover their own work. All they can do is slice up this pre-defined, unchangeable thing into 2-week sprints and deliver on schedule.

Moving away from “IT” to “Business Technology”

Establishing scaled agile practices under your existing structure won’t fix this. You need actual structural change. Take those technology functions (note that I said technology, not IT) that are vital for your business and give them directly to the business. Give the business direct control over the development teams that provide functions for their business. If a business area needs an app or a website or a CRM, give them the web/app/CRM teams to do that work with. Businesses should own and run its own technology.

When business, not IT owns technology, tech spending becomes an investment decision, not a cost decision. The business can choose to invest in technology to grow an area of their business. They are a profit centre. If investing more means a better return, then go for it.

If IT runs technology, that discussion becomes a cost discussion. Which means in practice a cost minimisation discussion. They are a cost centre. If they want to invest in something to grow the business they are constrained because the whole organisation is geared towards minimising their cost, not maximising their benefit.

Leave those actual support functions like accounting and payroll in the IT team and manage them as a cost centre. That’s where they belong. But the technology functions that are vital for your business belong in your business. How to best structure those new Business Technology teams? Let’s look at that next time.

Read Part 2: How to best structure your Business Technology teams