Running pilot projects differs from production projects, but both demand sound management practices and accountability.

There are similarities between managing mid- to large-scale production projects and running smaller pilot projects, but it is a mistake to assume the same set of practices can be applied to both types of projects.

Pilot projects by nature are “try and buy” or experimental. The promise of the project is not that it will work—an implied promise if you are working on an internal production project that has been vetted and approved by users and management. Instead, a project is being piloted because it has a strong chance of being a success, although success is not guaranteed.

SEE: Hiring kit: Project manager (TechRepublic Premium)

Tips to keep in mind when running a pilot project

If you’re tasked with running pilot projects, you still want to pick projects that are likely to succeed and build trust with stakeholders. If you see the project will not work, you also want to pull the plug and move on as quickly as you can.

Additionally, there are several other important management techniques for pilot projects.

1. Pilot projects should be highly structured and appropriately prioritized

Because a project is in pilot and not immediately targeted for production, there can be a tendency to de-prioritize it when faced with production crunches. There are also companies that start pilots without a defined project schedule or any specific metrics or targets. Instead, these companies run all of their pilot projects like they are tinkering in a sandbox.

Here is a real-world example:

I visited a company that was excited to pilot a project using telematics. When I visited them six months later, I asked the CIO how the telematics pilot was coming along.

He scratched his head and replied, “Oh, yes, I think we have someone in networks working on that.”

When a pilot  project is approached like this, it loses credibility as a serious undertaking—and the project advocate will encounter much more management resistance the next time they propose a pilot.

It is important to keep in mind that if there isn’t enough time to thoroughly plan out and audition a potential project or solution in a pilot project, then don’t take it on.

2. Vendors should be active participants

Pilot projects are considered “pilot” because there is much about them that is unknown, such as how it works or fits in the business environment as well as whether it can demonstrate significant business improvement in a tangible way. In addition, it’s unknown how difficult it will be for users and IT to learn the product, use it and support it.

Not all of these questions can be answered by reading product manuals or searching online help. Therefore, it’s best to make sure product vendors commit to the project before taking any steps toward production.

This might entail the vendor being on-site to help shepherd the project through the pilot. Or, it might require the vendor to train the IT staff and users. In some cases, it might even entail the vendor writing some of the interface code for the product to the organization’s systems, if that is needed. Finally, the vendor needs to be responsive if a glitch or a bug develops.

If this level of vendor support is not present and there isn’t enough on-staff experience, it may be best to defer the pilot until an adequate level of support and expertise is there.

3. Set a project timeline that fits the business use case

Pilot  project timelines and events should be calibrated to the business use cases they are being trialed for.

For example, when piloting a new accounting solution that has the potential of reducing month-end close time from three days to one, it seems reasonable to trial the solution to run for at least three months. This way both accounting and IT can confirm the desired monthly close goal is achieved and that results are accurate and consistent.