In every project there is an extreme retrofit phenomenon that can only be seen when one participates in all stages of a project. I label it as ‘power of the pilot’.
In short, the power of the pilot is the reverse effect that the pilot launch of a prototype has on all previous phases of a project – including the initial analysis phase. But first you need to know how I look at projects.
Non-sequential Phases
I tend to look at projects as a lifecycle of different Non-sequential phases. That is correct: “NON-sequential”. In theory they are sequential. However, in real life none of the phases are completely over until the full project is finished. But each phase is dominant at a particular time.
As you can see in the drawing below, even when the project is officially in the design phase, some activities belonging to the previous and next phases, such as project setup and deployment, will be going on as well. Generally speaking, 80% of the work you are performing belongs to the official project phase you are in, and the remaining 20% of the activities belong either to the previous or the next phase.
The Power of the Pilot
Here is what happens when the project team has struggled through the phases of analysis, design, implementation, and testing: they have reached the milestone of go-live. In most technical projects (i.e.: my world) this is done by means of a prototype that is launched for a small part of the target audience. Generally, this is called a ‘pilot-project’.
Through the eyes of technical people, this is it, and they hardly believe that there is anything that could go wrong, because all features have been tested and – in most cases – representatives of the target audience have been part of the testing teams. So nothing can go wrong, right?
It seems to be more complicated than that.
Over and over pilot projects prove to be battlefields for both, project members and for the target audience. Let’s have a closer look, each from their perspective:
What it Means to Project Members
From the project members’ perspective a pilot is seen as a final milestone. The technical architecture as it stands is at its best. Anything after this point in time will be considered as upgrades or additional feature requests. The only possible reasons to launch a pilot could be:
- A performance check of the infrastructure and systems. A pilot project in this case serves as an estimate of the capacity that will be required for the full roll-out;
- A courtesy to the organization that is granted because the change-readiness is different parts of the organization is going at different speeds. Therefore choosing a tactical target audience might convince all the others to follow the example.
But all in all, project team members expect the solution to be final, and all the rest are details…
What it Means to the Target Audience
More often than not the pilot-project is seen as a threat. But a threat that people will tolerate because management sponsors are endorsing the initiative. There is no certainty at all this solution will be adopted. the only conditions for accepting a pilot project are:
- A first real test of the prototype in practice. We want to see if it is workable in our team, with our data, our deadlines and our customers.
- A first opportunity to see how we can organize our team around this new solution. It’s one thing to do this exercise on paper, but yet another thing to do this in practice.
Things to Remember
Quite a difference in perspectives, don’t you think?
As it turns out in 100% of the cases, pilot projects result in a list of complaints, changes and additional requests. The next thing you know is that you are in the middle of a tense situation where people are alternating between “Who do you think you are?” and “Told you so!”
And then what? Here are some tips to make it alive through your Project-pilot days:
- Mental preparation: “Implementation is the last 99%“. This is a famous quote of management guru Tom Peters. This means that you should not only be prepared for a lot of rework but also for a total redesign.
I know… it’s crazy. - Denial: Don’t label it as a new feature request, because it is not. This extreme retro-fit is part of the project… and most importantly: it should be budgeted as such.
- Detachment: Project managers and technicians easily fall in love with their solution. That’s kind of normal: the solution they delivered is their baby. And when the adoption by the organization turns out to be difficult, they will take every bit of feedback very personal. But consider this: it’s not their baby; they are the midwife.
- Project organization: In terms of project management, you should make sure you have a serious buffer of manpower and budget. My gut feeling says that projects who are serious about benefits realization will buffer 1/5 to 1/4 of the total project budget for “Post-pilot-rework”.
Yes, again… it’s crazy… I know. - Shame: Don’t blame yourself when the pilot-shit hits the fan. There is no way you could have predicted what the end result should have been after intensive pilot-interaction. Consider this quote to make sense of the agony you go through as a project team member: “I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the other side of complexity”. The quote is attributed to Oliver Wendell Holmes.
Anyway, that was just a thought.
Good luck with your pilot project!
