Author: Graham Oakes

Graham Oakes

Graham Oakes helps people untangle complex technology, processes, relationships and governance. He helps them define business and technology strategy, and hence to set up and execute projects which will deliver that strategy.

Anarchy is governance too

The primary intent of governance is to increase focus, reduce waste and capture learning. That doesn't necessarily mean centralising everything.

Governance is sexy. All the stuff we used to manage - content, brands, projects, IT – now we govern it. And people who a few years ago had never heard the word, now talk about governance all the time.

However, drill into what they’re saying and it’s mostly about checks and controls. Governance, it seems, comes from a comprehensive list of policies and checklists, rigorously (and often centrally) enforced.

I think this is more likely to lead to bureaucracy than good governance.

1 comment

Six signs your project will fail

Project 'failure' is political. It’s about power. People with power get to define budgets and deadlines, to approve specifications, to assign teams. Thus they define the boundary between success and failure. Go outside the boundary, and your project fails.

The problem with politics is that it fuzzes our vision. We tend to see what we want to see rather than what’s really going on. That means we miss the early signs of failure.

And that, of course, increases the risk of catastrophic failure. If you spot the early warning signs, you have time to fix things before they become critical, before problems propagate. Miss those signs, and you sail blithely across the boundary of failure, never to return.

So it’d be nice to have some clear indicators that my project is heading into trouble. I can’t give you a magic formula, but here are some of the signs that make me nervous:

Big data gives you a nice hammer. Not every problem is a nail.

Big Data: the backlash begins

After a cycle of hype, reality sets in. Big Data isn’t going to save the world.

People are starting to state the obvious. Big Data in itself has little value. Unless you connect it to organisational goals, it’s just another tech solution looking for problems to solve.


Why can't we insure our digital projects?

Insurance premiums are a source of information: they tell us a lot about the real risk level attached to an activity.

What’s the difference between a project and a bungee jump?

They’re both a leap into the unknown. But at least you can get insurance for the bungee jump.


Why some projects should fail

There are two types of project failure. Failure due to inherent risk is OK: it's the other side of the risk/reward trade-off.  

Our real problem is all the unnecessary failure that surrounds our projects.


The rise of the temporary organisation

What's permanent? What's temporary? Perceptions of time frame the way we work together.

I was debating project and service management standards the other day. (Yep, I lead a sad life.)

To be honest, it wasn’t much of a debate. We all agreed on the big stuff – that projects and services overlap; that we all need to work together to deliver value; that people and skills matter more than standards and controls.  

A lot of motherhood and apple pie really. Boring.

Throughout the debate, I felt we were missing something. There was a big divergence in our underlying mindsets; we just weren’t getting at it. Afterwards, I realised this was due to the framing of the debate.


Why you need real options

Things were simple when I worked in the games industry. If the company’s owner liked an idea, he invested in it. One guy’s gut feel drove our entire investment strategy.

Back then, in the 90’s, a typical console game cost maybe £1m to develop. Our boss could afford to invest in several at once, giving himself a pretty decent chance that at least one of them would make money. And he only needed one or two successes to pay for a long tail of flops.

Nowadays, a high profile console game costs upwards of £20m to develop. Even large companies can only afford to carry a small number of failures of that size. Gut feel just doesn’t cut it any more.


Why you need to avoid governance vacuums

Say “governance” and blame never follows too far behind. Accountability, so far as I can tell, is a synonym for “who shall we sack?”

No wonder most people avoid discussing governance.

I’ve been facing it head-on recently. I’ve run several workshops on product development governance within a variety of organisations.  

In particular, we’ve been looking at some of the key decisions that people make during the course of product and systems development, and at how they allocate responsibility for those decisions.


How we buy technology

Organisations like to pretend that they're objective. It's not that simple.

Technology is tricky stuff. We respond emotionally to it. It changes the power balance between people, provoking political reactions. Vendors obfuscate about what their technology really does.

Most organisations recoil from this. They place a premium on “objective” decision-making, on measuring their options against some careful breakdown of functionality. By weighing each technology option against clear criteria, they reckon they’ll end up with the objectively “best” solution.


Big data: teams not technology

Big Data may be tough on our technology stacks, but the real challenges lie elsewhere.

Promises. Promises. Big Data sure makes a lot of them.

Increase the effectiveness of your sales (or political) campaigns by using behavioural data to divide customers into micro-segments.

Improve brand perception by monitoring the complex web of conversations across Twitter, Facebook and other channels and then engaging carefully with key influencers.  

Analyse internal processes to find opportunities to reduce costs and increase responsiveness.

Sounds great, but is it real? Are people actually doing such stuff, or is it all vendor hype?


Web teams: make it visible

When work is invisible, a spiral of death builds up. How can we break that cycle?

Apps. Websites. E-commerce platforms. We talk about these things all the time.  They’re having a very real impact on our world. Yet they’re all scarily intangible.  

Like icebergs, you see only the small percentage that’s on the surface. There’s a lot going on deeper down. Code, libraries, schema, configuration scripts, layer upon layer of infrastructure – all largely invisible.


Is 'best practice' really best?

Sometimes the best practice is simply to be flexible and adapt your response to the situation at hand.

Are you paralysed by 'best practice'?