Lighting up dark corners

Specialists have an important role lighting up the dark corners that management can not see.

There is a lot of truth in the phrase "You can not manage what you can not measure". You need to be able to discern good outcomes from bad.

Also, you can not measure what you can not define. You need to know where one thing ends and the next thing starts. You need a mental model to know what it is that is good, and what it is that is bad.

But in a self-referencing twist, how you define the world largely depends on how you manage it. Your approach to management imposes a structure on the world, which dictates how you define and measure it, which then impacts how you manage it.

To manage as best we can, we use structures that match the main needs of the work. In IT we tend to structure the world into development activities split by project, and service delivery activities split by role.

Whatever structure you use, though, there are always limits to what you can manage. Even the best managers have blind spots.

Often we use specialists to fill in the gaps that the main structure does not cover. For example, if most of the work is organised as projects, we will have specialists looking at different technical areas.

We generally think of specialists as supporting the main structure, for example providing technical expertise to projects. But a major value of specialists, and one that we should value, is that they take a different viewpoint from that of the main management structure and can see things that management can not.

Often this leads to conflict. In its mildest forms, specialists are seen as a bit over-zealous, for example a database administrator going on about database standards. In its more severe forms, specialists are seen as undermining management. When I worked as an enterprise architect, I would raise comments on projects' fit to the overall architecture, but these were incomprehensible to the dominant project management structure which only thought in terms of project delivery, and I was seen as unhelpful and working against management.

Whether you are working as a manager or a specialist you need to navigate this. One way is to superimpose an additional structure over the work to support a common viewpoint. This shared structure has to be very simple. You will not be able to get a common viewpoint if you use a consolidated work plan, or an enterprise architecture, or a set of ITIL processes.

I use a simple structure of "systems", where a system is a business application, and the software, hardware and human processes that support it. I embellish this with "qualities" that represent the valuable things we have to achieve. Most different IT viewpoints can be mapped to this structure, and it can be used to explain the issues that different viewpoints encounter.

Whatever simplified structure you use, it will always be thought of as inferior and less relevant than detailed management and specialist structures. But it is not there to replace other structures. It is there to provide a forum to combine multiple viewpoints, and let specialists light up the dark corners that management can not see.

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

From PCs to online services

How should IT management respond to the shift from PC applications to online services?

IT is a very plastic, mouldable entity, with little inherent structure. Different components can be configured and reused in many different ways. To avoid this turning into unmanageable mush, you have to impose some structure on it.

At the risk of gross oversimplification, we tend to impose different management structures on server-based IT and PC-based IT.

For server-based IT, we impose structure by splitting IT into distinct systems or applications. We assign business owners, IT representatives and support teams. We may have common elements, such as enterprise architecture and shared infrastructure, but we map how individual systems or applications fit within them. We adopt standards to help us manage systems and to help them interoperate. The mindset is one a controlled, joined-up capability to support joined-up business processes.

For PC-based IT, we tend to take a different approach. PC systems have often been single user, and PC management has less requirement to support joined-up business processes. Because of the technical challenges of the PC environment, management and support of PC-based applications is often left with a specialist PC support team, who work relatively independently of the architecture and infrastructure used to manage server-based systems. The mindset is one of ensuring all the applications function smoothly on the PC, rather than supporting joined-up business processes.

IT, however, is changing. IT capability is increasingly delivered as online services, whether these are applications delivered using a Software-as-a-Service (SaaS) model, or capabilities built on top of social sites such as Facebook. Increasingly, the PC is just a browser to access online services. There are more and more non-PC mobile devices, such as smart phones and tablets. Users' identity and focus is moving to online services, rather than the hard disks of their PCs.

How should you respond to this change?

Because online services are accessed through PCs, and because online services appear to be independent of other IT, there may be a temptation to manage new online services in a similar way to PCs. It may even be convenient to redeploy PC support staff for this, if other aspects of PC support diminish and the PC becomes little more than a "super browser". This approach would focus on ensuring that access to online services works smoothly.

However, the disciplines and approaches typically used for server-based IT are very relevant to online services, even if you are not yourself responsible for running the servers. Online services supporting core business processes need the same level of governance and joined-up thinking that we currently apply to in-house server-based systems. They need owners, representatives and support. They need to fit within the enterprise architecture. They need standards, especially if you need them to interoperate with each other or with your internal systems.

The PC support mindset, with its laudable and necessary focus on smooth running functionality, may not be the right basis to support the move to online services, however obvious and convenient this may be. The traditions and working practices of server-based IT may be a more appropriate starting point.

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

Embracing steady state: how

Last week I suggested that we need to break down the big distinction between projects and steady state management, and that we should manage more as steady state. This week I describe how.



Most organisations have moved on from managing technical capability, to using projects to deliver changes as quickly as possible.

In reality, though, most organisations have matured even further. Most work in most projects involves replacing functionality, not delivering new functionality. Our management approach has not kept up, and we are still managing a dash for growth. To maximise the value from our investments in IT, we now need to change our management approach.

We need to present IT differently. During the dash for growth, there was a lot of opportunity for totally new IT. It was appropriate to use relatively simple and even emotive arguments such as "information is the life blood of the organisation" to argue for IT.

Now that IT is more mature, and the general case for IT has been made, we need much more precise discussions about optimising the use of IT, to separate truly valuable use from gratuitous use. We need more rigorous analyses of the business value of information, and the ongoing costs of using, running and maintaining IT. We may need to dampen the enthusiasms of our business colleagues for systems that can not deliver value. A down-to-earth view of IT, as a capability to automate the storage, transformation and communication of information, can help us understand value more precisely.

The main IT management focus needs to alter, too. When the emphasis was on growth, it made sense to structure much of IT management (and career structures) around projects.

Now that IT is more mature, we need to focus on the IT that we already have. We need to shift attention to the ongoing management of meaningful business systems, rather than overemphasise big changes. We need to move on from projects that implement new IT to incremental changes that continuously realign what we have to where business is going.

At a more detailed level, we need to design and develop systems to be long-lived and easy to evolve. We need to choose technology that can last a long time, and use it so that it can. We need to value standardisation more than productivity.

We need to design in a way that makes systems easy to work with. We need modular designs, but not so intricate that nobody other than their original developers can understand them. We need to adopt methods of connecting systems that emphasise ease of independent change, rather than development speed. We need to pay more attention to documentation and testing, because these are much more important when systems are long-lived.

Regular readers will recognise these themes: demand reduction, precise definition of IT value, system focus, incremental change, standards, simple design, decoupled integration, documentation, and testing. These are not as exciting as technology and projects, but they are what we need. We need to move on from our obsessions with yesterday's problems, and use these to tackle tomorrow's.

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

Embracing steady state

It is time to move away from the big distinction between steady state and projects.

Enterprise IT is split into two. On the one hand we have changes and projects. On the other, we have steady state, business as usual.

We split IT specialisms along these lines. Support, operations, system administration and security are generally managed as steady state activities. Analysis, design and programming are generally managed in projects.

In many respects it is a very reasonable split. It recognises the work required to keep things more-or-less as they are, and separates this from the work required to take leaps forward in capability.

It is a common pattern, too, even in nature. Evolutionary biology recognises the idea of a "punctuated equilibrium" - periods of more-or-less steady state punctuated occasionally by periods of more rapid change.

Despite its obvious appeal, I think the big distinction between steady state and projects is now becoming a barrier to cost-effective IT.

Years ago, many IT projects introduced fundamentally new ways of doing business, or gained benefit from fundamentally new technologies. A colleague of mine was very much involved in the initial adoption of IT in fashion catalogue shopping. This is a relatively complicated business model, in which women (it was nearly always women) acted as agents to sell clothes on credit to their friends and neighbours, then collected the money in instalments over the following weeks. It was a huge business, but relatively complicated, with suppliers, agents, credit agreements, home delivery, returns, catalogue production, and so forth.

The introduction of IT had massive impacts in clerical, financial and logistical support. As he described it, any afternoon you could dream up a project that would save a million pounds. Given the return on investment in new projects, the overriding requirement was to get new systems in quickly, and to keep them stable and functioning long enough to be replaced with a new system that would provide a similar huge return on investment. There was no point building longevity into systems - speed of development was everything.

If you look at a typical IT project now there is much less genuinely new capability. Small steps forward in business capability are hidden inside massive projects to replace existing systems that have become too hard to work with or which rely on out-of-date technology. Even though technology is cheaper and development faster, the return on investment is much lower because less new capability is being delivered.

The split between projects and steady state made a lot of sense years ago, and was an efficient way of gaining value from IT. As the incremental benefit of projects decreases, the split makes less sense. There is now more value in changing and improving systems incrementally, which requires changes to how we design, develop and manage systems. This would let us get away from massive change projects, which are now a less efficient way of getting value from IT.

I suspect the biggest barrier to this is that our perception of IT, the specialisms we have, our career paths and reward structures, are all linked to the strong distinction between steady state and projects. Our approach to management is stuck in an outdated "dash for growth" model. We need to embrace the steady state.

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

Core value

To explain value, you have to look deeper than features and benefits, and understand how your products add value to your customers in a way that distinguishes you from your competitors.

At Metrici, we typically work with partner organisations. This lets us reach more customers than we could by ourselves. It allows us to focus our efforts on our areas of expertise, which are materials, methods and software for automated consultancy tools. It gives partners innovative products to introduce to their customers.

With each partner, we have to begin from the start. We have to explain the proposition, explore how it can add value to the partner, and then develop with them appropriate solutions for their customers.

Going through this process recently, I have been struck again by a recurring problem. The problem is how to explain how the products bring new value to the partner's customers.

This is doubly hard for us. A lot of the benefits of our approach are benefits to the partner. It is much quicker and cheaper to develop consultancy tools using our methods and software than it is to program from scratch. But what are the unique selling points of those solutions to our partners' customers?

The solutions have a lot of good features. The partner organisation can add their content. The expert system we use brings an extra level of insight not available from other tools. We can organise materials and assessments, and automate analysis, to make the whole process very streamlined. We can tailor the solution for each customer. Everything is available on the web. These are all good, but they do not of themselves provide a compelling reason for the customer to use the product, or explain how we add value in ways that others do not.

After scratching at this for a while, I think I can now explain what our unique value is.

Most of the normal ways we try to improve IT involve looking at IT from the viewpoint of the things we are responsible for. We manage projects and teams. We optimise processes. We consolidate technology.

Our approach is different because it looks at IT from the viewpoint of whole systems, which cut across the layers of people, processes and technologies that we typically manage. Because we look at IT in a different way, we can spot opportunities that other methods can not see. And because the way that we analyse IT is more closely related to the structure of IT as perceived by its owners and users (who see services and systems, not layers of people, processes and technology), it is much easier for us to articulate the business case for changes and improvements.

I can now explain the core value of our products. They identify additional opportunities for increasing business, reducing risk and reducing cost. Like an onion, this is wrapped in layers of other benefits which make it easy to run the process, and easy for partners to provide services, but which can make it harder to understand the tangible, unique, value-adding benefits of the products.

Try this for yourself. Can you explain the core value of your products? If you are like me, you may find it harder than you think.

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