10 Ways to Fail with IT Management

Some IT management problems are so easy to solve that it might make you wonder why you didn’t come up with the solution yourself. I’ve been in the IT consulting and training industry for over 30 years and some of the ‘mistakes’ keep just coming back. It’s time to solve them once and for all. So, let me share with you my take on the top 10 ‘mistakes’ by IT management so we can focus on other things!

1. Assuming Governance of IT Is Only Related to Risk and Compliance

Good governance means delivering value – that’s why enterprises exist and it’s what we expect from governments. It’s a shame that very often the terms “GRC” and “Compliance” have made people think that governance is a negative topic. IT governance is primarily about getting stakeholder value from IT investments – balancing benefits with risks. Isn’t that what everyone is striving for?

2. Not Appointing the Right Stakeholders to IT Steering Committees

Too often business executives are disconnected from IT. What happens next is that the CIO and technicians are making all the decisions. If business users want value from IT they need to get involved and take ownership of decision making. IT strategy and executive committees should be chaired by a business executive. Ideally, a board member should be involved and he/she should have business stakeholders represented.

3. Assuming IT Is Only for The “IT Function”

We live in an age where IT is part of everything we do, at work as well as in our personal lives. Using and managing IT effectively affects everyone. Roleplayers are converging with business and IT, working together at all levels. In the past, “IT skills” were about how to build the technology. But we are fast moving towards “IT skills” that cover how to acquire and apply IT effectively much more than covering the technology itself. Most “IT best practices” are not actually IT practices at all!

4. Reacting Only to Audit Findings

Approaching audits as a nuisance and a grudge can only lead to wasted time and negative attitudes. Audits can be a very valuable tool for independently identifying issues and driving improvement. Management though must help drive change and help plan and support audits. Auditors need to add value by identifying root causes, explaining the business impact and communicating effectively to top management.

5. Failing to Appoint a Senior Business Executive to Drive the Management of Information Security

Heard the term “information security” recently? It’s a major concern for many organizations but often surrounded by hype, mystique, and confusing language. Just hiring a security expert and assuming that is enough is a management cop-out. The only way to take the right security decisions is to drive the investment of adequate security from a business risk perspective with a balance between people, process, and technology. This requires a senior business executive role who will ask the right questions and demand the right justifications.

6. Defining SLAs in Technical Delivery Terms

If a service is not aligned with the customer’s requirements, the service provider will fail to satisfy the customer. An SLA should define the service in a way that enables the customer to agree and confirm that what is being offered is acceptable. Too often an IT SLA is defined by the provider in technical output terms often to limit the provider’s risks than to demonstrate benefits to the customer. The SLA should be defined and measured by what the customer expects to receive as an outcome in the customer’s language.

7. Defining Business Changes As “IT Projects” after the IT Solution

There is no such thing any more as an IT project and we should stop using that term.

Period.

Calling the project by the IT system results in a technology focus rather than business ownership and a business change focus. Every IT project is a business project and an “IT-enabled business change”. Everything you do, you do for a business purpose (yes, also pure technology upgrades are done for a business purpose). The future is more about driving business change than about building IT systems (which now can be acquired or rented).

8. Not Appointing a Business Owner / Sponsor to Be Accountable for IT Enabled Business Changes

Investing in IT initiatives means investing in IT as an enabler for business improvement. This requires careful preparation of business cases, the realization of business benefits, and the execution of a full scope of business and technical changes. The key driver is always a business goal and the desired business outcome. It’s therefore self-evident that every investment requires a business owner/sponsor to be accountable for delivering the desired outcomes and benefits at an acceptable cost.

9. Defining Requirements as a Solution Description

Over many years I still find it hard to find an “IT Requirement Specification” that truly describes the business requirement. Usually, it describes the proposed IT functionality. This is one of the key reasons for IT project failure since the starting point is already an assumed and possibly incorrect assumption regarding what is needed. Requirements should define desired outcomes and benefits in detail with any relevant constraints and will become the basis for acceptance of any solution.

10. Failing to Use a Business Case to Monitor Desired Outcomes and Benefits

I think everyone probably agrees that more than 90% of IT investments are justified by an inadequate business case. Of the very few good business cases, a fraction is used as living documents to monitor the likelihood of claimed benefits being delivered. It is when the project has delivered the solution that real monitoring begins. However, that is usually when the team disbands everything. The business case must be monitored until such time as the claimed benefits have been delivered or it is accepted that no more can be achieved. Failing to do this is a common cause of project failure.

Update: Over 40 countries participated in a survey that ITpreneurs ran after Gary Hardy’s webinar on the “Top 10 IT Management Mistakes”. Read the report and find out how COBIT can help in preventing these mistakes.

Read The Report

Gary Hardy
Gary Hardy is the architect of the ITpreneurs IT governance training portfolio and one of the originators of the COBIT framework. He’s been a lead developer of all the COBIT versions, including COBIT 5. He also has the distinction of being the lead author of all the versions of the COBIT Implementation Guide. His core business activities include consulting, training, and running his own company, ITwinners in South Africa. Recognized globally as a thought leader and implementation expert with over 30 years’ experience, Gary has guided numerous public and private enterprises in implementing IT performance improvements and governance and management practices. He’s also an expert advisor to one of the world’s largest and most significant COBIT-based IT governance improvement programs.