Trials – sometimes called a proof of concept, or an evaluation – are a common phase in technology projects. The term is often thrown around in early planning meetings, and despite seemingly a simple step in the journey to technology change, it can mean different things to everyone around the table. The following discussion lays out some thoughts on the topic.

Why do we do trials?

From the solution-selling side, when a buyer mentions ‘trial’ as the next step, it’s easy to assume that the sale is almost done. From the buyer’s side, when the seller offers a complimentary trial, it may be natural to jump in and give it a go. Problems arise when we haven’t agreed what the trial means, what it is setting out to achieve and, most importantly, what happens after the trial is completed.

Buyers can do trials for many reasons:

• De-risk a project - Setting out to answer questions about scope, functionality, or business process re-engineering. The intent is that if we try this technology, all our outstanding questions will be answered.
• Validation - It might also be about justification or answering open questions in the business case, about savings, or resource requirements.

Sellers can do trials for many reasons as well:

• Process requirement - They might believe it is a mandatory step in the process, where there is no other avenue to completing a sale and commencing an engagement.
• Proof of delivery - They might also believe that a trial is needed to confirm requirements, or the solution fit for the buyer.

All too quickly everyone can jump in before asking: why do we need to do this, and what do we all need to get out of it?

It’s important to discuss early on what all parties will see as ‘success’. Some forms of success are obvious, such as the supplier securing a sale and the buyer making the right decision on what technology solution to deploy.

However, trials are often a ‘honeymoon period’ where two parties are each evaluating whether a longer-term relationship can prosper, or what needs to evolve for this to happen.

Do we really need trials at all?

This is a great question to ask and will really draw out what the key milestones are. Trials can often speed a project up, but they can also slow them down.

Buyers might have requirements confirmed and are ready to deploy and wanting to decide on which solution or partner to go with.

Sometimes technology is new and needs to be proven and sometimes the technology is proven, and the trial is about proving that the solution will fit and deliver the desired results.

Objectives

By setting trial objectives that are SMART (Specific, Measurable, Attainable, Realistic and Time-bound) and can only be truly answered by a trial, the trial is given a purpose and a mission in the buyer’s journey of technology change. Trial objectives should be documented between the buyer and the seller and be signed off by both prior to commencement.

Next, it's important that all parties invest in the trial. This might mean funds, resources, or equipment. When all parties invest in a trial that has objectives that are not only agreed but SMART, we are setting the trial up for success for all parties.

A trial that is motivated by getting free stuff from a supplier is doomed to ultimately fail because, regardless of even short-term trial success, it is inevitable the follow-on deployment project will stall due to ill-preparedness, such as lack of funds, or an approved business case. The expectations of the supplier and the buyer are often worlds apart when contributions or investments in the trial are skewed in one direction.

Where a supplier and buyer invest equally in trials (i.e. the supplier contributes hardware/software and the buyer contributes resources and partial funding), the success rate of both of the trial and follow-on widespread deployment is far greater. This can be put down to the old saying of having ‘skin in the game’, a personal and a corporate motivation towards success both in short-term trial outcomes and long-term deployment.

As with any project, rigour in project management methodologies around trials stands to reason. The planning, execution, finite close and debrief afterwards are all worthy phases and an investment in ultimate success of the larger program of work.

What happens now

Where a trial sits in the overall program of work and what happens if the trial is successful – or not – needs to be agreed early on. A simple flow diagram can be used to document these two alternatives, and it’s important to document both.

Achieving a successful trial is great but what happens from then reflects how well the process was planned when the trial was in its infancy.

Every trial is different. The great ones lead to something tangible and thorough. They stick in your memory as something to replicate again-and-again.