Change is fuzzy. It’s about doing stuff you’re not currently doing. So it’s about stuff you lack hands-on experience with that you’ll have to learn about.  

That means you’re going to make mistakes. You’ll won’t estimate the time required accurately, go down blind alleys, need to rework things as you get feedback.

Yet, for most organisations, projects are black and white. You fix scope, set budgets and deadlines, specify outputs, define roles and responsibilities. No room for fuzziness there.

You could argue that you need this fixed foundation in order to innovate. Projects give you a framework to build from as you explore the unknown. If this was what I saw happening, I’d buy this argument.

But it’s generally not what I see happening.

In most organisations, projects are pressurized environments. All scope for flexibility and experimentation has been squeezed out. People feel the weight of deadlines, tight resources, status reports, external scrutiny. So they keep their heads down and avoid risks.

These projects aren’t learning environments. Not at the organisational level, anyway. The team may learn about how to do projects. But the organisation doesn’t learn about what options are available, where those options are applicable, how to create the most effective change.  

All it sees is how to create safe, predictable change.

Of course, for many situations that’s enough.

Many projects are about safe execution. Moving office. Migrating content to a new website. Adding a well-defined capability to that site  Upgrading to the next version of the underlying software. Running a campaign that’s a small variant on one we’ve run before.

For these projects, conventional project management is entirely appropriate. Create some fixed points then work tightly within them.

But our entire portfolio can’t be about such projects. If the organisation is going to do any sort of substantive innovation, it needs to take on more risk.

It needs to run some of those fuzzy, learning-style projects. That needs a different style of project management.

A style that does things like:

1. Set fuzzy goals

Sure, we need to be clear about the overall direction of travel, but over-constraining objectives reduces our scope to examine alternatives.  

Fuzzy goals, on the other hand, give people scope to explore options and trade-offs. They encourage discussion about what the goals mean, how best to achieve them, etc.  

That’s what we want: an environment where people are questioning and thinking, not just heads down doing.

2. Accept that things will change

When we fix budgets, deadlines, specifications, etc, we close off options. We need to think about these things, give ourselves a map of how we expect things to pan out.  

But the map is provisional, to be redrawn as we learn more. Milestones aren’t there for control. They’re there to record assumptions, tell us whether the world is really as we expected it to be.  

If it isn’t, then we need to adjust course, renegotiate objectives.

3. Create slack

The last thing we want is to have everyone’s time fully allocated to pre-defined tasks.  

That means there’s no time to check out alternatives, to backtrack when things don’t work as expected, to reflect on what’s going on, to experiment.  

When people have too much on their plates, they concentrate on getting stuff crossed off the list, not on exploring options.

4. Encourage failure

If we want people to experiment, we have to accept that some of those experiments will fail.

More than this, we should mandate that some of those experiments will fail. if they don’t fail occasionally, then people probably aren’t pushing the boundaries hard enough. They’re playing too safe.

5. Devolve control

You can’t do this from the top down. If people are going to take the initiative, they need to be given scope to make their own decisions.

 If we try to manage too tightly, we’ll just push people to keep their heads down. They’ll soldier on bravely, but they won’t innovate.

This goes against much of the project management literature. That’s mostly about managing within tight boundaries: reducing risk, controlling change.  (After all, PRINCE, the project management standard, means Projects in a Controlled Environment.)  

That’s fine for safe, well-defined increments to existing capabilities.

The problem is: this literature causes many organisations to think all projects should be managed that way. It creates the illusion that change can be made safe.  

Just specify it tightly enough, and you can avoid the fuzziness. That just isn’t so.

As Mario Andretti said, “If everything seems under control, you’re just not going fast enough”.

Somewhere in the portfolio we should be doing stuff that pushes the boundary – develops new products, tests new technologies, explores new markets.  We need to manage these projects differently.

Our Web Project Management – Fundamentals training course covers the fundamentals of project management for web projects: what it is, why projects go wrong, and what’s different about web projects. You will be given an overview of different project management methods (traditional/waterfall, agile and incremental delivery) and be shown how to manage each.