Is Your AI and Automation Strategy Right for You?
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….
