We’ve recently completed a Proof of Concept in Switzerland which was a little unusual. Its not unusual for us to work in Switzerland, I mean the PoC was unusual in that it included a Pilot. There’s nothing actually wrong with including a Pilot in a PoC, if the implementation phase needs checking, then this is the place to do it, but it is unusual for an organisation to recognise early-on that this phase of the project needed verification, and for that, I applaud them.
The topic of PoC’s is a rich vein that I’ll dig into in future posts no doubt, but for todays topic, I want to discuss the value of building a Pilot Implementation into the development cycle, (even in the PoC) and to ask if Pilot’s are really necessary in the BPM world where new processes are being rolled-out periodically.
What's a Pilot?
At it’s most mis-interpreted, the term ‘Pilot’ is used interchangeably with ‘Proof of Concept’, really, I’ve heard it. I guess there’s nothing wrong with doing this, as long as the audience is constantly reminded of the current definition, but its probably easier to get the vernacular correct from day-1 isn’t it? In my simple world, the birth of an application looks something like this…
This is greatly simplified (where’s the UAT I hear you cry) but we can see from this that the Proof of Concept should be about examining uncertainties and proving (or eliminating) theories, whilst the Pilot is a reliable way of validating the implementation approach and reducing risk when the big button is pressed. Think of the Pilot as a dress rehearsal, complete with a broad sample of users (not just the smart or co-operative ones!) which mimics the full roll-out as closely as possible.
When do we need a Pilot?
Of the many advantages of BPM, the rapidity of development should be the one that reduces the need for a pilot. It makes sense that if an organisation is regularly releasing new functionality or entire solutions, getting the implementation phase right is a ‘work unit’ in its own right and a set of processes and behaviours should be established for application to each new iteration or set of functions. Whilst this is broadly the case, it’s probably worth having a standard set of parameters to ensure that what you’re releasing into the wild fits into your ‘standard’ implementation model. As some suggestions :
Dependencies, are there an unusual number of outside factors, or reliance on systems (or even departments) that are less familiar to the implementation or development team?
Scale, is everyone comfortable with the breadth of the project or the time it must be conducted in? Perhaps the roll-back position is more complex if there are many sites or departments and therefore a ‘bail-out’ might need to be called earlier (reducing the implementation window)?
User preparedness, User Acceptance Testing should have thrown up any warning signs regarding initial drops in productivity or service levels. Multiply these by the audience affected and you could have a reason for a Pilot.
Remaining Risk, Risk is a catch-all that comes in many guises, but try to expect the unexpected here. For example, is there a political risk (come on, don’t pretend these don’t exist!) Are there dissenting elements that would make-merry should the project stumble? If so, then the fallout from a failing Pilot is easily turned into the success of a cautious and well-planned project.
If reviewing the above list against an project that is due for release makes you uneasy, or throws up more questions than comforts, then you should consider a Pilot.
I’ll probably post about the ‘shape’ of a pilot at a later date, and I’ve no doubt I will be discovered eulogising about the value of PoC’s very soon, but for now, why not pencil the word ‘Pilot’ on all your project plans with a big question mark….