What’s the point of a pilot? How to iterate learning to success.

Normally this question has an easy answer: to transport me to either (a) the French mountains or (b) a cheap european weekend away. In this case though, i mean a different pilot. The type that we talk about a lot, but rarely pay much attention to.

The point of a pilot programme is very simple: to take what you’ve created, to try it out with a small population, and to refine and revise it to make it better. It’s a chance to reflect on the learning experience and prune out the bits that don’t work. Except that this virtually never happens.

What usually occurs is that we complete a project in a rush, show it to some people and ask them what they think of it, then maybe tweak it a bit and push it out again, invariably in an even greater rush than before. This process, whilst adhering to the terminology, misses the spirit of the occasion and misses an opportunity.

To carry out a Pilot successfully requires us to define the criteria on which we are assessing, and to reserve both time and budget for revisions. If done correctly, the Pilot should be viewed more as part of the build process, less as something you do once the project is ‘complete’. It’s also a chance to reflect on and capture what went right. This type of ‘cross project’ learning is always hard to manage, at least in a structured way, but can be hugely valuable.

I do, of course, speak from a position of rarely running effective pilots myself. It’s one of the things i’m actively trying to address myself in current projects, but it’s not easy. I feel very firmly grounded in an Action Research approach during projects these days, with cycles of planning, doing and reviewing, but we still tend to hit all the usual barriers at the end of the day: time and resource. Well, i guess you can’t solve every problem at once!