Pilot Feature is a software project management best practice that I have been using throughout the years with excellent results. It is simple and effective when applied in context.
It means that with every new feature that is not yet very well understood, you delegate a small amount of time and resources to start earlier than initially planned and work on some small but useful part of the feature.
In usual context of a project with iterations, you just start one iteration earlier than expected.
By sacrificing some time upfront, you reduce the risk substantially. Almost all of the unknown unknowns will show up. Infrastructure will be ready. All licenses and authorization will be set up. Domain knowledge will have a much better foundation.
After Pilot Feature is prepared, estimations for follow-up features will be much more precise. You will have much better hold on the project schedule, I cannot stress enough how important that is.
I found out that after Pilot Feature, all the groundwork is done, so next features are much more easily parallelizable. Because of the understanding of the domain you got, you can split the work so that developers will not step on each other's toes.
On the other hand, sometimes, after Pilot Feature is done, some unforeseen problems arise, and the Feature is canceled. That is also a huge win.
You should apply Pilot Feature only when the feature is substantially large, on your own scale. It does not make sense to apply such pattern to a one-day job. We are talking about weeks rather than days.
Other than that, the person that approaches Pilot Feature should be competent enough to make progress in the light of uncertainty. Ideally one should have some experience in the similar domain, although I would not say it is strictly necessary.
It is absolutely crucial for Pilot Feature to be small, but an end-to-end portion of work to be done. Ideally, every stone should be lifted.
Example A - new data source
There is a new data source that your team should digest. Management thinks that data will be read and modified by different groups of people, so quite a few new views will be implemented. Additionally few existing reports will be extended.
Instead of jumping right to the whole thing, delegate one person to create a Pilot Feature: load that data and display in some simplistic manner. This simple maneuver will make sure that when more developers will take on more complex tasks:
All the necessary rights will be granted on all the necessary test and production servers
There will be some unit or integration tests to base further ones on
Quality of data will be reviewed
At least one developer will have the domain knowledge required to work with the data
Example B - introduction of structured logging
Some developer found out that the project could benefit from structured logging approach. She decided to start early and leave old logging for a while adding new structure based logs to just one of the modules, the one that was debugged most often.
Because of the small scale approach she took, when the next iteration starts:
All the packages are already in the project
Log server is already set up both in test and in production
Other developers, even those that did not hear about structured logging previously, can see how it works in a familiar context
There are some examples of production code that will serve as a base for further work
Pilot Feature is a project management practice that significantly reduces risks by starting early. The ideas are similar to those of Lean Product and Sprint 0, althought Pilot Feature applies mostly to already running projects.