Is there a pilot on board?: white paper

"If there is a pilot on board, would he or she please ring their call button?" is something no passenger ever wants to hear. I re-read a remarkable news story from a true incident just like this that happened back in December 2013. After the pilot of a flight out of Des Moines, Iowa suffered a medical emergency, the co-pilot made a request for any pilots on board. Capt. Mark Gongol, a B1 bomber pilot in the US Air Force, stepped into the breach. The plane, passengers, and crew all landed safely.

It's a great story but my going back to re-read it recently was triggered by something very different. A prospective client of ours called recently and asked if they could "pilot" our enterprise project timesheet software. These kinds of calls always make me take pause. When someone on an aircraft says "pilot," we're all very clear about what is meant, but when someone who is evaluating software options says “pilot,” I'm not so sure.

The term “pilot,” in the software world, is often blended together with other challenging evaluation methods, like "proof of concept." Let's take a look at what these terms mean and how you can best use them in your own enterprise evaluation process.

Proof of Concept

This is a term that dates back many years and is popular in electrical engineering. "Bread boarding" a circuit was done to see if the circuit was possible, not to start creating it for production. In proof of concept, you might spend more time at a lab bench than you would in creating the production circuit, but the only damage you could do was to the circuit board you were working on in front of you. It was an inexpensive and low-risk method of proving that an electrical circuit could deliver a desired result.

In software terms, a proof of concept should be designed to prove something. When prospective clients call to ask if I can help them deliver a proof of concept for enterprise project management or enterprise timesheet software, I always have the same response: "What concepts do you want to prove?"

This is typically met with silence and a confused expression.

If you're going to conduct a proof of concept, and you have no notion of what you're trying to prove, how will you know if it's a success or failure? There's no way at all of course.

Why, you ask, would someone even want to do a proof of concept then? The most common answer is that the requestor probably doesn't have the necessary buy-in from management to implement the software they're researching, and hope that if it was just running in front of them they'd fall in love with the idea and agree that it should be deployed. In this case, the "proof" is to management, and the "concept" is the whole idea of enterprise software.

If it were that easy to convince management that enterprise project and timesheet software is a great fit for them, we'd deploy an awful lot more of it.

The problem with this method is that the work you're going to be able to do to deploy this proof of concept instance is extremely unlikely to have the same support as you would get for the production deployment of an enterprise system. When an organization deploys an enterprise system, such as a timesheet or project management system, there are many things that are required to make it a success. First, there will need to be input from management and line-personnel for any aspect of the organization that is implicated in the deployment. Next, there will need to be time for configuration, assistance from technical services to link to other enterprise systems, management sponsorship, time for training, and, yes, money.

If you don't have any of these things, then what will be the system that you can complete in your proof of concept? It will be a shadow of what you desire at best. In today's in-the-cloud age, you can probably get access to a system that is fully hosted so that you can at least not worry about buying servers and software, but just having a system installed is a fraction of the work required to make even a basic deployment of your proof of concept system.

It's easy to understand why an organization will hesitate to devote a lot of money and resources for the implementation of something that has the potential to impact the whole organization. It's a high-risk exercise. We tend to talk only about the benefits of enterprise project management software, but it's easy to imagine that the same project gone-wrong can have an equally negative impact. So, mitigating the risk is an obvious concern. But if the real challenge is to convince management of the benefits of the system, then surely there are better ways to do this. At HMS Software, we've focused on a few of the following techniques:

Talk to a real, already-existing client.

We're blessed here to have some great clients who are by and large quite satisfied. When a new prospective client has concerns over what they're getting into, we get that organization together with an existing client. In many cases, the existing client has been generous enough to offer to host an in-person meeting. In other cases, they do calls with each other that we deliberately don't become a part of. We encourage the existing client to share both good news and challenges.

Let us prove it.

If you really do have a concept that needs proving, then let us help prove it to you. There are legitimate reasons why some aspects of some implementations need to be proven first. Perhaps the deployment will have very large volumes of certain kind of data. We were asked once for example, to show our solution functioning with a particularly large project load. We've been asked to show software working with certain browsers or with certain databases, or linking to particular versions of certain external systems. If that's the kind of concept that is blocking the evaluation, then the best people who can overcome that challenge are the subject matter experts.

You can have some training with that.

In the case where the prospective client absolutely must show the system working with their data used by their personnel, we help load the data into a hosted system, then do a minimum to configure the system as desired by the client and to train the people who will be involved. We highly prefer being brought into the company to help with the demonstration itself, but if that's not possible, we ask to review the script or demonstration that the people involved will use, and ask to help adjust it or train people to deliver it.

Where's a pilot when you need one?

So what about the pilot project? That's better, right? It could be. If you've been asked to establish a pilot deployment of an enterprise timesheet or enterprise project management system, you should start by determining the goals. If the goals are all about proof of concept, then you're not in a pilot program at all.

A pilot project is a real, in-production, live deployment. It typically involves a subset of the total user base that is being considered for the system being evaluated, and therefore a pilot program is likely to take some time. While the needs of the complete target user base are considered from the beginning, the pilot program focuses on doing a real implementation for the pilot users. They will actually be managing their projects or actually filling in their timesheets with the new system.

The same challenges that a complete production deployment will face are also faced by the pilot implementation, with the exception of the volume or complexity of data. The most common challenges of Pilot projects I’ve seen include a lack of sponsorship, insufficient budget, time and resources and, probably worst of all, a lack of articulate goals to know how to determine if the pilot project was successful or not.

This isn’t to say that a pilot project is bad. Doing a pilot could be very sensible and can serve to mitigate the risk of impacting the entire organization with an incomplete or poorly configured deployment. But making a pilot project successful takes some thinking.

Recently, we started working on a significant-sized deployment for a public sector organization. What is gratifying about the exercise is that the organization has already spent all the time they should have completing their evaluation. They’ve made their choice of enterprise system. Happily, it’s ours. We’ve worked with their evaluation team over the last year to make sure their technical questions were answered, but now the focus turns to the impact on the day to day process of the people in this organization.

They proposed that we work over a 6 month period with a group that, while sizable, is still only about 10 percent of the entire group. There’s an adequate budget, the pilot has the support of management at the most senior level and we’ve got enough time to make sure we can assist with everything we’d normally do on a deployment like this one. The group who will be put onto this project tracking and timesheet environment will be working with it, in production, for the foreseeable future, so it’s not just a test. This is more like the first phase of deployment, not a “try it and we’ll see how it goes” exercise. With all these factors in place, we have every expectation of a successful result late this year.

Wrapping up

Pilot and Proof of Concept projects are a fact of life in enterprise software, but if you have one in your future, you can help make it a success to point out some key success factors to everyone involved:

First, make sure you have your goals clearly articulated.

Next, make sure that management understands what you need and will support you in terms of money, resources, and time in order to achieve those goals.

Finally, make sure you make a project plan and manage it like any other project in your portfolio.

About the author

Chris Vandersluis is the president and founder of Montreal, Canada–based HMS Software, a Microsoft Certified Partner. He has an economics degree from McGill University and over 30 years experience in the automation of project control systems. He is a long-standing member of the Project Management Institute (PMI) and helped found the Montreal, Toronto, and Quebec chapters of the Microsoft Project Users Group (MPUG). Publications for which Chris has written include Fortune, Heavy Construction News, Computing Canada magazine, PMI’s PMNetwork, and Project Times. He teaches Advanced Project Management at McGill University and often speaks at project management association functions across North America and around the world. HMS Software is the publisher of the TimeControl project-oriented timekeeping system and has been a Microsoft Project Solution Partner since 1995.

Chris Vandersluis can be contacted by e-mail at: chris.vandersluis@hms.ca

If you would like to read more EPM-related articles by Chris Vandersluis, see his EPM Guidance blog (http://www.epmguidance.com/?page_id=39).