I never liked the words pilot nor proof of concept.   I have been through many pilot projects and proof of concept as projects or in projects.  Although the intention is well understood by everyone at the very beginning, by the time we reached the end, there almost always seems to be confusion about the purpose and next step.  Now I don’t even seem to know the differences and intentions anymore.  Even though everyone seems to know that they are different, they receive the same miracle software expectation.  It’s an execution confusion issue.
But I think the main reason for pilots and proof of concepts is to get feedback.  Spikes do the same thing too.  You know you’re seeking enlightenment when you start saying “I don’t know … enough…” or “It depends…” or “What if.” Whenever we work with a new domain or a tricky part of an application, we are searching for feedback, not miracles.  If you practice TDD and do exploratory testing of concepts that are not 100% clear in design and even understanding, then you know what I mean.  Perhaps we must just drop the grand classification labels and our response should be something like “Well, let’s explore this tiny bit and see what happens” or “Why don’t we try out this idea by doing …”.

So we do proof of concepts and pilots all the time.  It’s just that I hate searching for miracles but I like feedback which helps me change the probabilities of certain of things happening.  And I like it to be part of my workflow.  Exploration gives me feedback and increased understanding that leads to more exploration.  I hate it being a milestone on a Gantt chart and when that milestone is a common point in critical execution paths for the project, then I know, for sure, someone was actually looking for a miracle.

If you are somewhere on the agile adoption curve, then drop the Gantt chart.  Now you’ve just removed the shrine for miracle worship.  There are no shortcuts to enlightenment, just feedback with every step.  Success depends on how you absorb and react to that feedback.