Best Made Project Plans – Managed Better

I’ve recently been thinking about what we call ‘project drift’ – why it happens, the issues that it creates and what to do about it.

Our definition of project drift isn’t the chaotic and aimless pursuit of an objective. Our projects are well planned, often in phases with their own mini-objectives and they build towards a defined goal. They’re not rigid plans and we factor-in some deviation because research and experimentation are by their nature, unpredictable. Our version of project drift is a gradual and often imperceptible process – an accumulation of small, unplanned activities that slowly nudge a project off-track – and often takes much longer than expected to get back on-track.  

The reasons why it happens here are quite wholesome. Our science team has a healthy amount of curiosity, adventure and they’re (normally) agreeable. Their default response to a new idea is to ‘have a go’. Personally, I’d rather be concerned with harnessing enthusiasm than worrying about how to motivate and convince people who stubbornly refuse to consider anything that hasn’t been previously agreed.

Ours is a good problem to have, but it is a problem because agreeableness can lead to over-commitment and that doesn’t help anyone. I haven’t recently crossed paths with anyone who ruthlessly exploits someone’s good nature, but if you get the reputation for being helpful, it’s easy to be taken for granted and incredibly hard to assert yourself when necessary.

Plans are made for a reason. They structure the service that we provide for our customers to make sure that we reach intended objectives effectively and efficiently. Our project pricing is also influenced by the estimated time it takes to complete. So ‘drift’ has impact.

If a customer has a deadline, it puts pressure on but focuses the agenda. A loose schedule might seem preferable, but these are often the projects that wander. Having time to try something different is great if it happens occasionally but if it becomes the norm, a project can seriously overrun. Without a strict deadline, overrunning may not concern the customer, but it can make a mess of our schedules for other projects and put undue pressure on cashflow if we can’t justify issuing invoices.

What to do about it? We’ve got tried-and-tested practices and systems in place and I don’t think that they need to change. The tweak that will pay dividends for everyone is a simple calculation:

Is the activity ahead… in the plan? Adding value? Affecting the schedule? A one-off/temporary diversion? Might it lead to significant changes in project timescales and costs?

These yes/no questions lead to one of four results: Do it; consider it; revise it and don’t do it. 

It's a basic discipline that works for everyone. It doesn’t deter creativity or prevent alternative routes to a positive outcome. It just means that everyone respects the structure of the project and considers the implications of deviating from the plan.

If a member of our science team still feels awkward being anything other than super-amenable, they can always blame the monster who insisted that they shouldn’t default to an immediate agreement.

The monster? That’ll be me then.

Thoughts and comments welcome.

Richard

Credit: Photo by Jacob Kiesow on Unsplash