Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


How to think about IT

A framework for understanding the changing management needs of IT-enabled business capabilities through their life-cycles (and avoiding big mistakes).

Mark Foden

on 4 March 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of How to think about IT

Future Benefit
How to think about IT
This axis shows Future Benefit. It is the magnitude of the unrealised strategic potential of a capability as felt by those involved with it.
Unrealised Potential
Current Benefit
We believe that a more effective focus on business capabilities, rather than on IT, can help us all keep out of the IT poo (of which there seems to be a rather lot nowadays).
To provide a framework for understanding the changing management needs of IT-enabled business capabilities through their life-cycles (and avoiding big mistakes).
Aim of this presentation
And, of course, we have a model...
The model describes four possible states that a business capability can be in:

These are based on the balance of current and unrealised potential future business benefit of the capability...

...and their names represent the management behaviours associated with each state.

Each occupies one of the four boxes in the model.

The rest of this presentation explains the features of these states and highlights stuff to watch out for.
This axis of the grid here shows Current Benefit: the actual strategic benefit being delivered by a capability as felt by those involved with it.

The 'felt' bit is important.
We will look at each state in order. Starting at the beginning...
We're done. There is loads more to say, but you have probably had enough.
How to think about IT
Actually,this is about how to think about buiness capability
And encouragingly (as most of our work is with UK Government) this man seems to think so too...
We call it the
To avoid doubt: this is not about project management or software development methods, but we hope that the ideas in this presentation will help you make better choices about those methods.
Experiment > Explore > Exploit > Exhaust
4ex Model
But, if you are gasping for more...
Click the Right arrow
With thanks to John Ward whose excellent ideas this model is based on and to MDB for the "4ex" name (and all manner of other inspiration)
Tricky concept here: as a capability matures, its future benefit becomes understood and begins delivering serious Current Benefit, it will fall on this axis.
Someone has an idea to create or improve a business capability. The idea will have loads of potential Future Benefit but it won't have any Current Benefit (cos it's still an idea). So it doesn't yet qualify for the first box...
Remember, the big words in blue, like "Experiment", represent a set of behaviours related to the management of a business capability.
"Yeah, very nice, but what do you do with it?"
Identify the main IT-enabled business capabilities your are developing at the moment.

Assess the maturity of the capabilities and plot them on the four boxes.

Create a communal word cloud to describe the behaviours associated with each capability.

Compare the results with the model.

What does this tell you?
Think about an IT development you know that went wrong.

Try to plot it's life-cycle on the model.

(Did it travel the Road of Doom?)

What does this tell you?
Identify the business capability the project is supporting

Where is it now in the model?

What is planned next?

What does this tell you?
Audit your IT projects
Peer into the past
Review your plans for a new project
This is Experiment. We have moved right on the grid. Stuff is happening and the new ideas are showing some value.
...Technology Demonstrators. They demonstrate technology not business benefit. No way do they count in Experiment. They are still ideas; no matter how shiny or promising.
But watch out for...
...Pilots. Sadly it's fall-off-log easy to get Explore wrong: "We did a pilot, didn't we?".

A pilot (or a trial) that is part of a big design up front implementation is, by our definition, not Explore. When a big design is done first and a pilot set up as validation, learning is constrained. Explore means genuinely exploring: learning about the jungle, hacking paths through thick vegetation, crossing torrents (waterfalls?), wearing pith helmets, wrestling with crocs and all that stuff. It is not about completing pilot milestones.
But watch out for...
This will be familiar from an IT perspective, but it is not at all a place for traditional-style waterfall capability delivery to carry on as before. Because Explore has preceeded: Exploit will start in a different place. Customers will know what they want (in fact they will already have most of it, although it might be a bit flakey) and there will be an eager and supportive community of users and developers involved. Big IT delivery will be easier and a whole lot less risky.
...the Road of Doom: the road that leads directly from Experiment to Exploit. If you only read one frame in this presentation, make it this one.

Even if you have done a proper bang up job of Experiment, do not let yourself believe that you can go straight to Exploit (and subsequent Knighthood) without passing Explore. It mostly doesn't work.

Disturbingly, it's easy to find folks ready to provide you luxury coaches with very nice drivers, co-drivers, conductors, navigators, mechanics and heavens knows who else, to take you on this road. For a fare.

So, give yourself a good talking-to, tell yourself there is a better way and read the bit about Explore again.
But watch out for...
Exhaust is about extracting every last ounce of benefit from a capability (and being bold about shutting it down when the cost of supporting it exceeds the benefit it delivers).
You could get loads of folks involved with the capability to email in 10 words each, paste all of them into http://wordle.net to create a communal word cloud and see what the result tells you.
This is Explore. We have moved further right on the grid: Current Benefit up even more; potential for the future growing.
Explore is when promising capabilities that have proved themselves in Experiment are grown.

Explore is the important bit.

Where the gold is.
Explore is gradual
Explore is when people learn, together, how capabilities might be made to work differently in practice and how customers might be encouraged to behave differently. Incrementally, they adapt the technology to capture that learning. Then...

...they learn a bit more.
They learn also how to help people learn about the new capability and the technology that supports it. In later stages, when the capability is to be used by many more people, this will be vital.
At the same time, they get substantial benefit from the new capability as they grow it. Which is nice.
But... emergent capabilities are going to be a bit flakey. Using them for real is risky. And this risk must be managed. By the people involved. Eyeball to eyeball. Day by day.
Although we said that this model wasn't about project or development methodologies - if ever there was a place for Agile methods, this is it...
"Think big, start small, move fast"
Explore is when people come together...

...customers, users, developers, managers of users, managers of developers, managers of mangers, procurers, policy dudes, legal folk, commercial people. Anybody who has an interest.

It's about collaboration.
This is Exploit. We have moved down the grid. Current Benefit is strong and growing but unrealised future benefit is decreasing, because it is being ...er realised.
Exploit is about capturing for the long-term, the innovation and learning developed in Explore and then getting long term value out of it. It is where all the heavy-lifting goes on to put in place effective, reliable, supportable capabilites at a reasonable cost.
This is Exhaust. We have moved left on the grid: Current Benefit is waning (although perhaps very slowly). The capability is a commodity and no longer makes a strategic contribution.
Experiments should deliver business benefit quickly; if they don't, they should be binned or re-energised.
It's quite possible that there will be no new technology involved at this stage. Better to start with exercising the new process with existing tools (white boards, spreadsheets, whatever).
Experiment is about establishing the potential of a capability by demonstrating some Current Benefit and thereby creating enthusiasm for future potential.

No enthusiasm: no success.
Experiment is when the roots of the community that will sustain the new capability through its growth to maturity are put down.
Mostly, Experiment is about people... innovating.
Full transcript