Simon Battersby

Sometimes the best thing to do with a project task is to start it…

Sounds a daft thing to say, but there’s sometimes a danger of over-planning and over-analysing a task, instead of actually getting on and doing it.

I can think of two personal examples. A few years ago I was managing a complex set of interfaces between two systems. One of our suppliers was reluctant to sit down and talk about it because they wanted more preparation. However, we gained more from a rough and ready two hour meeting with everyone round the table than we would have done from a couple of weeks planning. The supplier was generous enough to agree this as well.

My other example concerns a web tool which had been discussed for a long time at high level, to the extent that everyone thought it was a difficult task. Again in a couple of hours, by talking about some detail and the sort of data we wanted to display, we were able to take a big step towards understanding what we were trying to do, and realise it wasn’t quite as hard as we thought.

Sometimes you just need to start talking about something – it’s pretty certain that talking discussing some detail will focus thoughts and help get a clearer idea of what it is you’re trying to do.

Here’s a great quote on the subject:

Aside: This quote is generally, but incorrectly attributed to Goethe, but in fact was introduced as part of a “very free translation” from Faust by John Anster in 1835. Now you know…

I was thinking last week about empowerment and accountability within a programme structure.

If a programme is going to deliver something of value to a business, the programme manager or director needs to be accountable to the rest of the business – fine. But the business also needs to give the programme the space and resources and trust to deliver. Critically, once the programme structure and responsibilities are agreed, the business needs to step back and let the programme get on with it.

If the programme is delivering into an existing business structure – and most do, of course – the business is going to need to be kept informed of what’s going on (quite apart from any implementation management activities). There’s a danger, however, that the business switches into “can’t let go” mode, and micro-manages, effectively disenfranchising the programme. This is a slippery slope. If this happens the lines of reporting and control get confused, with clear control and accountability for decisions being lost, with project managers, for example, reporting to many masters.

I’m not for one minute trying to say that the programme should ignore the business. Far from it. A lot of IT problems happen because business and IT are not linked hand-in-hand. I think this risk is best enabled by embedding business people within a programme or project, and empowering them to represent the business within that structure. These people are accountable to the project for agreeing requirements etc, and also accountable to the business for representing it accurately. The business needs to trust (there’s that word again) these people and, again, let them get on with it.

So, give the programme accountability, empower it, and then give it enough space to do what it’s there for.

Not all problems can be solved by throwing more resources at them.

A few years ago I worked on a programme with three or four workstreams, with maybe 70 or so people in all. For various reasons, the requirements were relatively fluid, and because the programme was quite large, there was a danger of some design decisions being made without taking the full picture into account.

The master stroke (and I can’t claim responsibility), was to set up a small team, with one person responsible across the programme for requirements, one person responsible for technical design, and one person responsible for build. This team achieved a vast amount in only a few weeks in aligning the requirements, assuring the design, and generally tidying up a lot of loose ends. Like all small teams, everyone in the team knew what everyone else was doing and what they were responsible for.

Once again, a few people in tune with each other was the critical difference.