Information technology groups tend to be quite persistent.
The excuse is “preserving knowledge”. Preserving hard-won knowledge of the business area served by the team. Preserving hard-won knowledge of the guts of the systems built by the team.
If you need either, you’re doing it all wrong most of the time.
Let’s take the second case first: knowledge of the system. Yes, I know you have ruthlessly modified your packaged software to meet the needs of the business over the years.
The question is: should you have?
Unless the code in question provides a value-generating, bottom line-visible differentiation of this enterprise from its competitors, what’s that mod doing there?
Was it because at the time no one in IT had the strength of character to tell the business that, when the answer is an imported best practice in the form of a software package, they change, the code doesn’t?
After all, if the package was unmodified, the enterprise wouldn’t have had to pay for the original modifications — wouldn’t be paying for the maintenance team year after year — won’t have to pay for the retrofitting of that suite of changes when the package is updated next time — and, oh yes, would be getting value for money out of the 22 per cent being paid for “maintenance” under the software licence by being able to easily move with the vendor when fixes and new function are delivered in new releases.
That’s an awful lot of money off the bottom line for years simply because no one was ruthless enough to say “no, you take the change” and make it stick. (Not to add ten years’ worth of depreciation expense coming off earnings per share, or taking the write down to fix this mess now.)
Maintaining code-level knowledge for home-grown code that differentiates the business and thus allows premiums to accrue — revenue others can’t capture, price premiums, etc. — makes sense. For everything else, it’s a commodity world, and that means the business changes to adopt the practice the package implements.
Now, back to the first excuse: knowledge of the business.
Can we be honest for a moment? The only people who truly know the business are the people in that part of the business. Senior management doesn’t, and all the Sarbanes-Oxley Acts and pretentions otherwise through restriction in delegating authority won’t change that. Other parts of the business don’t (they have quite enough trouble keeping on top of their own issues, thank you very much). Why should IT think that, by magic, they do?
IT people are not customer-facing when the part of the business involved is. IT people are not plant-floor sensitive, when the part of the business is. Good heavens, IT people can’t really enter into the financial mindset even when the head of IT reports to the CFO (mostly because they aren’t trained as CAs, CPAs or CGAs, nor do they work with the numbers daily so that errors become obvious and patterns of what needs to do are ingrained).
If “preserving knowledge” was so all-fired important, you’d never see a consulting firm win a systems integration contract. They’d have no preserved position to work from, and so would lose against in-house staff every single time.
Is that how the last twenty years have unfolded? Thought not.
Likewise, does your managed service provider, your co-location provider, or your telecommunications provider lock people into place for years so that they can “preserve their knowledge of your environment”? Or do they come and go, flex in and out, restructure at will without telling you, and still, somehow, your data centre and networking needs get met?
Don’t turn around and say infrastructure is different. It’s precisely the same problem, when you’ve got an enterprise architecture that can be summed up as “the answer is a package, what was your question?”.
Pre-configured service offerings, and pre-configured software, are one and the same thing. They’re items where you can mix and match parts and tweak check boxes and parameters to do something where knowledge preservation isn’t a big issue any longer.
So that leaves the last bit — the project backlog — as the remaining justification for permanent IT teams aligned with the business.
But that, in turn, leads to the myth that “we’re working” on unfunded projects, or projects not approved for release this year, simply because the team is underemployed.
IT organizations would be far better off if they did three things:
- First, spend time on differentiation, and be ruthless about implementing packages in unmodified form. This forces the architectural conversation with the business into issues of strategy and tactical advantage, with the resulting myth-busting a plus for all concerned.
- Second, if the project isn’t approved to go, stop working on it. Instead, build a team that can explore ideas (pre-project). This reduces the commitment level while allowing issues to be dealt with early (like finding out you have two parts of the business that disagree about what a supplier or customer is), and keeps solution selection to the end of the pre-project period where it belongs.
- Third, acquire the necessary consultative skills to be able to gear up your knowledge when and as needed, bringing true skill in IT and its marketplace when you do. That’s how the SI firms do it, that’s how the outsourcers do it, that’s how the offshore teams do it, and that’s how you ought to do it to add value to the enterprise you work for.
Let’s be clear: if your project portfolio is filled with a lot of things to which commitments have been made but won’t see the light of day for years, your asset portfolio is filled with immobilized code that can’t be easily upgraded, and your headcount is filled with people who are stuck in place because of the need to preserve what they know, you are in trouble, both as an IT group and as an enterprise.
There’s only going to be one solution. The hard work of fixing what exists. Start by getting rid of the myths on the people side: it’ll make the rest of the puzzle more obvious to all concerned.