Improving IT Performance
Copyright Alistair Davidson, 2003. All rights reserved.
Draft 1. November 2003

Executive Summary
==============
Most companies do a pretty bad job of managing IT projects. And most software projects don’t actually deliver on expectations. So what do you do? It’s hard to avoid software and you can’t delegate everything to outsourcers.

Let me suggest that there are ten important steps in improving the value you get out of information technology.

1. Hire the best people you can find and overpay them. Get rid of bad IT people quickly.
2. Get rid of old projects faster.
3. Do fewer projects.
4. Pick projects with synergy. Pick people with synergy.
5. Don’t accept conventional wisdom. Seek extraordinary value.
6. Focus on iterating.
7. Measure outcomes and people frequently.
8. Don’t let budget cutbacks prevent experimentation. Encourage and permit small failures.
9. Classify projects and manage the different categories differently.
10. Manage the mix of in-house capabilities and outsourcing.


Hire the best people. Get rid of bad IT people quickly.
======================================
If there is one piece of advice about information technology that is critical, this first rule is it. Good people are passionate, knowledgeable, annoying and they get things done. One good person is worth ten bad people.

These kind of people are few and far between. Overpay them. Train them. Send them to conferences and you will be rewarded many times over. If you can’t afford to pay them right, get rid of other people.

Bad IT people subtract value from the good people, so you are better off with a few good people than a large team of people with mixed skills.

Get rid of old projects faster
====================
If you don’t get rid of old projects quickly, then you end up with an expanding and expensive IT budget. You get distracted by having to maintain the old code and projects. Be ruthless.
Do fewer projects.
Most software ends badly. Do what you do well. If in doubt, don’t do it. If you have to do it and you don’t have the resources, buy something off the shelf. If you are programming, license something already done.
Pick projects with synergy. Pick people with synergy.
Most organizations have lots of projects. Yet, they don’t look for synergy between projects. If a project can solve several problems at the same time, it is generally a good project.

In the same way, the composition of project teams is key. Good projects managers and good teams are rare. If you find them, keep them. Don’t break them up. Don’t lose them.

Don’t accept conventional wisdom. Seek extraordinary value.
===========================================
Conventional IT practices tend to focus on the technology side of IT. Today, information management is such a pervasive issue that projects should be selected on their business outcomes. They should be optimized for their business outcomes and impact upon the organization’s strategy and performance.

But there is a key assumption here often lost on managers. There is an extraordinary difference between good projects and average projects. In my experience, the difference is at least an order of magnitude (10X or more) in outcomes. But if you don’t seek such outcomes, you will not get them.

Focus on iterating.
=============
Information technology is inherently risky. The larger the project the riskier it is. The more novel the project, the riskier it is. So, phase the project. Don’t overpromise what you are going to deliver. Deliver small. Then expand. Learn what customer or users need. They don’t know what they want, can’t tell you, are probably wrong if they do tell you, so be cautious. Assume iteration is always required.

Measure outcomes and people frequently.
==============================
Long projects are risky. Frequent evidence of performance is critical. The only way of delivering on time is to select staff, technologies and suppliers that will allow you to keep in touch with the progress of the project. Any project that has long lags between work and measurement is likely doomed to failure. In software development, architectural strategies should be selected that force frequent demonstration of success.

If you hear that you have to wait until the pieces can be brought together at the end of the project, you are in trouble already.

Don’t let budget cutbacks prevent experimentation. Encourage and permit small failures.
==============================================================
Software is about learning and improving. There are two elements to learning. The first is learning about a technology and what is necessary to make it work. The second is about learning what customers and users do. Small experiments are often exceptionally valuable.

Technology expertise and user knowledge don’t emerge in a vacuum. You need to manage how you are going to gain and document such knowledge.

Classify projects and manage the different categories differently.
==============================================
Not all IT projects are the same. While we can argue about different types of classification schemes, some that I use include:

1. Experiments.
2. Platform development.
3. Application development.

Platform development is always risky. A platform development project often requires dealing with a new technology (i.e. the platform on which you will building applications), so using outside expertise to educate your internal staff is often critical here.

Another scheme I use is

1. Strategically critical
2. Strategically important
3. Maintenance
4. Compulsory due to regulatory requirements.

The resources put into each vary and each group of projects should be prioritized differently. Mixing them together in your prioritization will often end up causing bad business outcomes.

But it’s also important to look at synergy between the categories. Current Sarbanes-Oxley requirements can also help improve the management of the company if done well. You can turn compliance activities into a source of performance improvement if you are smart.

Manage the mix of in-house capabilities and outsourcing.
========================================
I once interviewed customers who had been implementing information warehouses and asked them the question: “Having implemented your first information warehouse, how much do you think you would save if you were starting from scratch and knew what you now know about the process of information warehouse development?”

In most cases, the answer was that they believed they could save 50%. What this means is that using knowledgeable suppliers with large and risky projects is critical. You can pay them their margin and still benefit with lower costs.

The challenge of course, is knowledge transfer. It’s critical to formally manage the knowledge transfer and not becoming dependent upon the external supplier unless you are proposing a strategic partnering arrangement with the external supplier.

=================================================================================
Alistair Davidson is the author of two books (Davidson, Gellman and Chung, Riding the Tiger and Turn Around! A free ebook available at www.eclicktick.com) on best practices in information management. He has developed numerous projects, developed first of breed technologies, helped turn a financial institution into a best of breed information technology organization, has turnaround failed IT projects and software companies. He has an MBA from Harvard and has been the CEO of five companies and has extensive CTO/CIO experience. He can be reached at www.eclicktick.com or emailed at Alistair@eclicktick.com

For more articles on outsourcing and IT strategy, visit www.eclicktick.com