Simon Battersby

I’m reading this book about Scott’s expeditions to the Antarctic at the moment.

A bit of background information about the Royal Navy particularly interested me. It talks about communication between naval vessels in action. In Nelson’s time in the early 1800s it was very difficult, with the result that each captain had to rely on his own judgement and initiative. By the mid to late 1800s, however, improvements in naval signalling meant that captains relied far more heavily on orders from superior officers, with the result that initiative and individual thought was largely stifled, and the quality of naval leadership suffered badly as a result.

It struck me that there are parallels with today’s “always in touch” culture via mobile phones, emails, Blackberrys and the like, all of which discourage people from using their initiative and making a decision, because there’s always someone else to refer the decision upwards.

Maybe one day a week should be declared “trust your own judgement” day…

In the very first paid job I did, as a fresh-faced 18 year old, I was on the receiving end of some new technology. It was an interesting experience.

The technology in question was a complex piece of machinery which automated the process of splitting up multiple carbon copies of orders for distribution to different sections (shows how long ago it was…). This had previously been done by hand. The order packs came in batches of 48 at a time, and needed to be threaded through this machine before the process could be run. This was rather fiddly.

Now, once it was installed, we had lots of senior visitors who came from the top floor to see this wonderful machine and marvel at how much time was saved. Except, it didn’t really save that much time, if any, because the total time taken was pretty much the same as before for a set of 48 packs, and actually rather longer if there was less than 48 – this happened quite often because urgent orders had to be printed off as soon as they were entered.

The clerical people that actually did the job knew all this, but nobody had asked them… I managed to put my foot in it by saying this to one of the more senior people and was told “You’re not paid to think”. Ouch!

This is especially critical in a contact centre/CRM environment where usability is so critical to the success of an application. On one occasion I commented about the lack of involvement from users in design, and was told it was OK as the Director of Customer Service was involved. But they’re not going to use the system on a call with a customer, are they?

Make sure the real grass roots/coal face/sharp end users are involved in design. They will be the harshest critics of anything that isn’t quite right – and what seems like an acceptable compromise in a design workshop may be the end of the world in a busy contact centre.

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.

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.