Centralisation is a power game. Treat it as a strategy for learning, and it might be more useful.
How does your web team work?
We’ve all experimented with various forms. When content management systems were new, devolved teams were all the rage. Give this wonderful tool to everyone in the company, and they’ll each edit their own little bit of the site.
What a wonderful site that was…
We play mind games with success. That's OK if you’re trying to avoid blame, but not if you're trying to avoid failure.
My American friends are still talking about HealthCare.gov. Why did no-one see failure coming? Why, when so many people on the project could see issues, did no-one act to improve things? Another high profile project failure enters the lexicon.
Great questions. Why don’t we discuss the issues that are so manifest on our projects?
Our projects would end better if we accepted the fundamental fuzziness in their beginnings.
Projects often end badly. They go out with a skyful of fireworks, finger-pointing and blame. Why doesn’t the site perform adequately? Where’s all the functionality we expected? Where has all the time, and budget, gone?
Some people say this is because we start projects so poorly.
Product and service development is all about risk. We take on a range of market, design and technical risks in order to gain rewards – new products, better conversion rates, increased market share, improved margins, etc.
Sometimes, however, the risks win. Projects fail for a whole host of reasons: our aspirations run ahead of the technology; we fail to find a commercially feasible solution to design challenges; our competition beats us to the punch. The list is almost endless.
And too many items on that list are entirely manageable. Poor internal communication. Ill-defined scope. Failure to engage key stakeholders. Unrealistic estimates. The project management literature has been calling out such risks for decades.
We know how to solve these problems. We just don’t do it.
That’s the real failure on many of our projects: we fail to see and manage the basic stuff.
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.
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:
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.
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.
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.
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.