Simon Battersby

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.