The next big thing has been cancelled

In the past, major shifts in IT architecture have hidden weak long-term management. With no prospect of a similar shift in the near future, it's time to tighten up our act.

When I started in IT, the hot technology was online transaction processing (OLTP). Businesses were moving from keyed data entry and batch processing to an exciting new online world. Batch systems were being rewritten to take advantage of new technologies like IBM's CICS.

OLTP went through a few generations. I spent a lot of time on fourth generation languages (4GLs). 4GLs were much more productive than COBOL, and we could build much richer, more usable systems. Many COBOL OLTP systems were rewritten in 4GLs.

Then along came PCs, and client/server. We used Visual Basic 3 and database gateways to replace those clunky character-based 4GL systems with new client/server systems.

PCs developed rapidly. 32-bit computing would get rid of memory addressing problems for ever. Application servers helped us replace the inefficient two-tier client/server architectures with 3-tier architectures. Early client/server systems were rewritten because of the benefits of the new architectures.

Then we discovered the Internet. We could reach customers and partners all over the world. We could centralise our systems again, back to our controlled data centres. We redeveloped our systems using exciting new technologies like CGI and PERL.

Web technologies matured, with a new generation of web application servers, new standards and new tools. We redeveloped in Java, and more recently, with frameworks like Struts. We used open source technologies like Linux. Those first generation web applications were so resource-intensive, so hard to manage, we just had to redevelop them.

Rapid technology change has forced us to redevelop every few years. It has both forced us and allowed us to take a short-term view of systems. Our main objective has been to deliver projects quickly and keep up with technology. Managing for the long term has been meaningless.

Will this continue?

The changes I have seen are the result of three big changes: online systems, PCs, and the Internet. Each of these has spawned a few generations of implementation technology.

In the future, there will continue to be significant technology improvements: processing, storage and networks will improve in performance and price, and technologies like virtualisation will increase flexibility.

For applications, however, I can not see a change anything as fundamental as online processing, PCs or the Internet. I can not see a "next big thing" that will force wholesale replacement.

This means we have to adjust our management. We can not assume there will be pressing technology drivers to replace systems. Management that focuses on big replacement projects, and does not consider the long-term management of systems, will seem as old-fashioned as the OLTP systems I worked on when I started.

We need to change our management. We need to excel at the swift execution of small incremental projects. We need to design our technology solutions to allow for piecemeal change, not wholesale change. We need to look after what we have better, with methods like system quality management.

We can't rely on the next big thing to hide weak management. The next big thing has been cancelled.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

What's so special about your project?

We have all seen projects and systems treated as special cases, but in many ways all projects and all systems need to be managed the same.

IT encourages us to move from the specific to the generic.

You can't get much more specific than individual people. Each one of us is a unique entity. Within the organisation we have different roles and responsibilities, and different contractual arrangements. But an IT response to this, in a personnel system, is to move from the specific to the general, and to treat everyone the same.

This generalisation lets us communicate meaningfully about people in the organisation, and to control the organisation's staffing. By treating people the same, we can automate the mundane parts of personnel management (like calculating payroll), and concentrate on the more specific, more unique, more valuable (or more challenging) parts. Although every person is a special case, a degree of generalisation enables us to work more effectively.

We are learning to apply generalisation to IT.

For example, individual projects have many differences in business drivers, technology, project approach and resourcing.

Sometimes we treat a project as a special case, but it is usually a mistake. My favourite is, "This project is strategic so it doesn't have a business case." I always reinterpret this as, "We have no idea how this project delivers value but we can't cancel it because it is politically motivated".

Mostly, though, we have learnt to generalise projects. We define projects, give them codes, assign responsibilities, and have standard processes for communicating, evaluating and controlling projects. Generalisation does not stop every project being special, but helps us manage the mundane parts of projects better and leaves us more time for the creative parts.

When we look at technology and systems, we are still in the dark ages of special cases:

• "These are legacy systems, we don't know much about them."
• "The Sun server has a different disaster recover policy."
• "We document Java in the code and don't have any system documentation."
• "The direct sales applications support team don't have the resources to maintain test suites."
• "We don't have database design standards, but the DBA looks at each case."

We would not tolerate this degree of specialness for managing projects, or even for managing people.

Because we manage each area of technology and each system as a special case, we can not discuss them meaningfully and control them. Our management effort is frittered away on day-to-day point issues. We never get to grips with value-adding activities such as setting direction and establishing control. We never engage our business colleagues meaningfully about technology and systems.

To rise above this sea of detail, we need to generalise our IT systems and our technology, to see them in many ways as the same. Every area of technology needs principles and standards that align with business objectives. Every system needs to fit those principles and standards, and to be supported by processes that maintain that fit for the long run. We need a common management framework across them, like system quality management, like we have a common management framework across projects. Although every technology and every system is special, it is not a special case.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Stop being so demanding!

You can cut IT costs and still deliver IT change and services if you can stop IT itself being so demanding.

In a naive view of IT, business demands IT change. The IT organisation makes changes to systems and services, which deliver added value to the business.

We know that IT is not that simple. Most of the demand for IT does not come directly from business. It comes from the IT itself. Most of the demand for IT spend is the requirement to run and change existing IT systems, and replace them when they are no longer supportable. This "internal demand" is much greater than the "external demand" to support business change, and accounts for perhaps 80% of the typical IT budget.

One view of internal demand, perhaps the common view, is that it is inevitable. It can not be reduced. Our job in IT is just to meet internal demand at the lowest cost and risk.

We can take a different view. The management decisions we make dictate the level of internal demand. If we skimp on design, if we modify systems recklessly, if we let test suites and documentation get out-of-date, if we do not constantly upgrade to supported technologies, internal demand rises to frightening proportions. If we are disciplined about the long-term management of systems, and if we demonstrate to the business the value of preventative maintenance, we can cut internal demand.

A historical perspective helps us understand why we find it difficult to manage internal demand.

When IT started, IT change was difficult and expensive, and there was very little existing IT. It made sense to focus management effort on meeting external demand as efficiently as possible. Internal demand did not matter, because there was so little of it.

As technology developed, it was possible to do more and more with IT. Management focused on the dash for growth, to meet new demands as effectively as possible. Existing IT did not matter, as it was frequently swept away by bigger, better systems. Internal demand was not relevant.

But as IT matures, there are fewer truly new requirements. We have a vast amount of IT that must be run and maintained. Most projects focus on replacing old systems that have become unsupportable. Internal demand has taken over from external demand as the major determinant of IT cost and risk.

Our IT management focus has not shifted to match the maturing of IT. We are still obsessed with change, with projects, with meeting external demand. We think of costs and risks only in terms of project costs and risks. We do not focus on existing IT. We have no handle on internal demand.

We need to refocus IT. We shouldn't throw away what we have learnt about managing change, but we need to add to it a way of managing the IT we already have. We have to reduce the demands that existing IT makes on the IT budget.

This is what system quality management is all about. System quality management identifies and justifies changes that reduce internal demand. It stops IT being so demanding. It lets you cut costs while still delivering IT change and services.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

If project management never existed

If project management never existed, we would have to invent it. For the same reasons, we have to invent system quality management.

Imagine a world without project management. What would it be like? What difficulties would we face?

It would be impossible to make coherent changes. Different people would have a different idea of what was needed. However well-meaning, dedicated and capable the individuals were, their disjointed efforts would be wasted.

Without a project manager there would be nobody in charge, nobody to control the work, nobody to solve the problems. Nobody could define joined-up processes to deliver a coherent solution.

There would be no connection between the work and the broader business. To get buy-in and budget, random business managers would be subjected to random out-of-context questions like "Do you want a web application or a PC application?" or budget requests like "new servers". Business contact would be confusing and disjointed, and it would be impossible to drive out meaningful requirements and business case.

Thank goodness, then, for project management.

Project management lets us structure and organise the work. We can build up a body of information - plans, resources, estimates, actuals - and use this to guide decisions and as a basis for effective control.

Project management defines responsibilities. We know who is in charge. We can define processes, solve problems and control the work.

Project management lets us discuss the project meaningfully across the broader business. We can set objectives, define requirements and build a business case.

IT suffers from a problem as big as if project management never existed.

This problem is the long-term management of systems, and the long-term maintenance of their qualities, like system structure, resilience, documentation, technical viability, compliance, performance, usability, security, duplication, longevity, and so on. These qualities are the most important factor in the risks and cost of running, changing and replacing IT, which accounts for 80% of the typical IT budget. They have a massive impact on our ability to respond effectively to business change.

How do we manage these? Just like we would manage projects without project management.

We have no coherent approach to managing these qualities. It is left the the disjointed best efforts of individuals and unconnected teams, whose dedication is inevitably wasted without meaningful co-ordination.

Although there are pockets of narrow responsibility, overall there is no process. Overall, nobody is in charge, nobody controls the work, nobody solves the problems.

There is no business meaning. When we need to change things, we make random out-of-context budget requests to "improve documentation" or "upgrade servers", without connecting this to anything of meaning and value to the broader business.

We need system quality management like we need project management. We need coherent objectives. We need a body of information about systems and their qualities so we can make effective decisions and control the work. We need processes and responsibilities. We need to present system qualities in a way that is meaningful across the broader business, so that we understand business needs and can build the business case for the required work.

In most organisations, meaningful system quality management does not exist. We have to invent it.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

If project management never existed

If project management never existed, we would have to invent it. For the same reasons, we have to invent system quality management.

Imagine a world without project management. What would it be like? What difficulties would we face?

It would be impossible to make coherent changes. Different people would have a different idea of what was needed. However well-meaning, dedicated and capable the individuals were, their disjointed efforts would be wasted.

Without a project manager there would be nobody in charge, nobody to control the work, nobody to solve the problems. Nobody could define joined-up processes to deliver a coherent solution.

There would be no connection between the work and the broader business. To get buy-in and budget, random business managers would be subjected to random out-of-context questions like "Do you want a web application or a PC application?" or budget requests like "new servers". Business contact would be confusing and disjointed, and it would be impossible to drive out meaningful requirements and business case.

Thank goodness, then, for project management.

Project management lets us structure and organise the work. We can build up a body of information - plans, resources, estimates, actuals - and use this to guide decisions and as a basis for effective control.

Project management defines responsibilities. We know who is in charge. We can define processes, solve problems and control the work.

Project management lets us discuss the project meaningfully across the broader business. We can set objectives, define requirements and build a business case.

IT suffers from a problem as big as if project management never existed.

This problem is the long-term management of systems, and the long-term maintenance of their qualities, like system structure, resilience, documentation, technical viability, compliance, performance, usability, security, duplication, longevity, and so on. These qualities are the most important factor in the risks and cost of running, changing and replacing IT, which accounts for 80% of the typical IT budget. They have a massive impact on our ability to respond effectively to business change.

How do we manage these? Just like we would manage projects without project management.

We have no coherent approach to managing these qualities. It is left the the disjointed best efforts of individuals and unconnected teams, whose dedication is inevitably wasted without meaningful co-ordination.

Although there are pockets of narrow responsibility, overall there is no process. Overall, nobody is in charge, nobody controls the work, nobody solves the problems.

There is no business meaning. When we need to change things, we make random out-of-context budget requests to "improve documentation" or "upgrade servers", without connecting this to anything of meaning and value to the broader business.

We need system quality management like we need project management. We need coherent objectives. We need a body of information about systems and their qualities so we can make effective decisions and control the work. We need processes and responsibilities. We need to present system qualities in a way that is meaningful across the broader business, so that we understand business needs and can build the business case for the required work.

In most organisations, meaningful system quality management does not exist. We have to invent it.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Cost reduction options

IT cost reduction methods fall into ten categories. Some have much more potential than others.

I have spent the past few years exploring IT cost reduction. Looking back, I see that I have fallen into the trap of presenting my views as "the solution", and not giving a fair account of other approaches.

To address this, I have been looking more broadly at IT cost reduction methods. Most methods fall into one of ten categories.

Five of the categories are supply side cost reduction, which reduce the cost of meeting IT demand.

• Negotiation. Better structuring and negotiation of supplier agreements and contracts.
• Outsourcing. Moving IT activity to other organisations who can provide it at a lower price.
• Consolidation. Meeting multiple demands with the same solution, such as using virtualisation to reduce the number of servers.
• Commoditisation. Moving to cheaper open source and commodity technology.
• Process improvement. Improving the efficiency of IT working practices by managing processes more effectively.

Five of the categories are demand side cost reduction, which reduce the demand for IT.

• Sharing. Combining demands into a single demand, for example getting agreement for different departments with similar needs to share a single system.
• Replacement delay. Run systems for longer before they are renovated or replaced.
• Business alignment. Direct IT spend to the systems and projects that support priority business areas, and cut spend from lower priority areas.
• Value focus. Reduce the perceived requirement for IT to only those requirements that directly add value to the required business change. See Cutting costs: where to start for some ideas.
• Size and complexity reduction. Proactively manage IT to be smaller and simpler, to reduce the demand for running, changing and replacing IT.

All these methods have some potential. To understand which are most valuable you need to consider:

• What does the method affect? Does it impact all of your IT activities and spend, or just some of them?
• What level of saving could you achieve?
• How hard is it to get the saving, and how long does it take?
• Have you exhausted the method, or are further savings possible?
• Are there other benefits to the method, such as improvements to control and improved agility?

The "easy" methods are negotiation, business alignment, value focus and some kinds of outsourcing. These can be implemented without a major impact.

The most valuable methods are process improvement and size and complexity reduction. These impact IT broadly, have a high level of saving, and have benefits of improved control and agility. They are also the hardest methods, with the greatest impact on IT.

Most organisations have already achieved many of the benefits of process improvement. They have effective project management processes and service delivery processes. Further improvements have diminishing returns.

For most organisations, the biggest opportunity is size and complexity reduction. My main interest is in methods that make this easier, such as system quality management. This is not the only solution to cost reduction, of course. But it is the one, in my opinion, with the most potential.

© Copyright 2008 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.