Combining projects and good management

We need to change how we view IT so that we can run projects without undermining long-term management.

IT's emphasis on projects is a source of immaturity. Projects are one-off and special, they cut across organisational boundaries, they deliver value by meeting broad organisational aims, and they are time critical. This is the opposite of mature IT, which is standard, has clear ownership, focussed purpose and is managed to be long-lived.

The conflict between projects and long-term management is one of the facts of life of IT. It would be stupid to get rid of projects, which are the best way of making step changes that take business forward. It would be naive to retreat into a technically-focussed role, and refuse to take a proper role in business projects.

How can we modify our approach to managing IT to better balance the need for projects and the need for reliable, well-governed and long-lived IT?

The key is to make IT more simply understandable to business. If we only talk about IT as a business enabler that supports business processes, this does little to help us (both inside and outside the IT department) grasp the management requirements on the IT itself. We need to communicate some of the management realities of IT, and show how this relates to business use.

We need to present IT not as business enablers or technical layers, but as a simple set of "systems". A system, by this definition, is a set of IT capability with clear purpose, boundary and owner. You can think of a system in terms of its responsibilities, which is what it does for its owner and which are always a subset of the owner's responsibilities.

This way of defining systems gives you something on to which you can map project requirements, and about which you can discuss qualities such as reliability and longevity. Instead of structuring IT work solely by project, each system can have its own development plan, built from the requirements from multiple business projects. Because systems are more clearly owned, business managers are more aware of the trade-off between urgent project requirements and long term good management. Because the responsibilities of systems are better known, and subset the responsibilities of their owners, it is easier to properly critique how a project alters the responsibilities of and value delivered by each system.

This approach alters the role of the project manager, taking them away from the role of technical task leader, to a proper role negotiating and co-ordinating multiple changes. This approach also values the role of business analysts, system analysts and architects who can creatively translate requirements into changes to existing business responsibilities and systems, which is much harder but also much more valuable than designing a new solution and only later thinking how it fits with what is already there.

Importantly, this approach emphasises that IT projects should nearly always be incremental. Too many of our methods and our IT culture sees our job as taking out the old and putting in the new. But as IT matures, we have to change this. We have to see IT projects as strengthening and building on what is already there, not knocking it down and starting again every time.

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

Projects are immature

IT's project culture is a major barrier to reliable and long-lived IT.

Although it is technologically sophisticated, corporate IT is immature in a number of ways.

• Reliability. IT system often break down, and need to be constantly patched and fixed.
• Ownership and governance. It is hard to get business managers to provide the guidance necessary for IT systems. The IT department is often left looking after unowned systems.
• Value. It is hard to value IT. Many IT systems run because we are scared to turn them off, rather than because we know how they deliver a return for the organisation. It is hard to justify work to maintain IT.
• Longevity. IT systems require replacement after a few years, largely because they have become unsupportable rather than because the business has changed.

We know how to improve IT maturity, for example:

• To improve reliability, we need good standards and operational procedures. We need to have a standard way of building, operating and supporting IT so that common problems are avoided, and when a problem does arise we get to the root cause and fix it quickly.
• To improve ownership and governance, we need to improve the alignment between IT and business. IT systems have to align to organisational responsibilities, so that they can be clearly owned, rather than unownable cross-functional systems that do not reflect anyone's responsibility.
• To improve value, we have to peel away the layers of confusion about the role of IT. Seeing IT as a vague corporate enabler does not help us understand IT's specific value. Seeing IT as the automation of the storage, processing and movement of information removes woolly thinking and pinpoints exactly what value is delivered from which IT systems.
• To improve longevity we need to design, select and build systems and components that are capable of lasting a long time. More importantly, we need to manage systems so that they do last, ensuring that every modification improves the manageability of the system, and proactively assessing and replacing components that become outdated.

There are many reasons why we do not do the things we could to improve maturity. How many of them are related to the strong project management culture in IT?

• Every project is a special one-off, and needs to break away from the approach and constraints of earlier solutions.
• Projects deliver value because they bring together cross-functional solutions.
• It is important to get buy-in to projects. Often it is hard to pinpoint the value of the project (or dangerous, if it involves staff reduction), and we have to use broad arguments about how the organisation in general will benefit from the project.
• Timeliness is everything in projects. To retain business support and budget for the project, we have to cut corners to meet deadlines, and carry out quick and dirty fixes to integrate the project with existing systems.

In many respects, the way we approach projects is the exact opposite of what we need to do to improve IT's maturity, and to tackle the persistent problems of reliability, governance, value and longevity.

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

Hitting things with bricks

Our IT is not as sophisticated as we think it is.

It might date me somewhat, but when I first got married, we drove a very old Hillman Imp.

Is your IT as modern as this car?

The Hillman Imp was fantastically unsophisticated by today's standards. No electronic engine management - it was all manual choke and distributor caps. No power steering. No air conditioning. It was horribly rusty and unreliable. But I have many fond memories of it.

One of my favourite memories was one of the many times it would not start in the morning. I phoned the breakdown service, and a man arrived shortly afterwards in his van. He jumped out, not even bothering to switch off his own engine. He picked half a brick up off the driveway, opened the back of our car (which is where the engine is), and hit the starter motor with the brick. This fixed the problem, and the repair man jumped back into his van and drove off. The whole repair took about 90 seconds. It was such a simple car, he could see what was wrong immediately, and needed nothing more than a well-aimed brick to fix it.

Of course, cars are very different now. I have been driving the same Nissan for ten years, which never gives me problems and does not have a spot of rust. Although in comparison to the old Imp, my Nissan is soul-less and boring, it is in a totally different league in terms of reliability.

I don't think my experiences are unusual. Over the past 25 years cars have somehow "grown up", and become an order of magnitude more reliable.

It would be wrong, though, to think of the Hillman Imp as an early car. The first cars were produced almost 90 years before our Imp was made. In its time, the Hillman Imp was a very innovative car, with many features not found in other vehicles of its class.

It would be wrong to think that there has been an increasing amount of innovation in the last quarter century. Although in absolute terms there are more incremental innovations, in relative terms the rate of automotive innovation in the early twentieth century was staggering.

It would be wrong to think that automobile innovation has stopped. There is still a huge amount of development, even towards self-driving cars.

What has this to do with IT?

Sometimes we are beguiled by the improvements we see in IT, and the rate of change, and the promise of the future, and forget that IT is still a young industry.

Although we can not draw direct parallels with the automobile industry, it provides a useful reminder that what we might think of as modern is still very unsophisticated. Most people's experience of any type of IT, whether it is PCs, or enterprise systems, or consumer gadgets, is that it is temperamental, and unreliable, and lasts only a few years before it becomes outdated and unusable. And when there are problems, our response is often to fix it with the IT equivalent of hitting it with half a brick, rather than solving the underlying problem. Somehow, IT has to grow up.

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