I took a deep breath before clicking on the “Join now” button of the MS
Teams call. We were ready to present our proposal for a discovery project to a
potential client.

Before today’s presentation, we had several calls with the client to agree on
the deliverables, scope, and timelines of this engagement. The Product Owner
had requested that we include a prototype as part of this discovery, and we
made sure we agreed up front what that meant.

We took the first few minutes to introduce all parties. Several C-level
executives were attending the call including the CEO. The Product Owner
stressed that all the decision-making stakeholders were on the call so the “Go
/ No Go” decision should follow shortly.

The first slides covering the scope went smoothly with only a few questions
being asked. Then, when we presented the timeline, we got a question that
caught us completely off guard.

“Based on this timeline, I see that you will finish the discovery and the
prototype in March. So, when will the users get trained and can start using
the Prototype?” asked the CEO.

There was a noticeable pause… “What do you mean?” I asked. “Well, I presume
the users need at least a basic training to start using the Prototype” said
the CEO.

I could feel my heart starting to beat faster. I had enough experience to
understand we were heading into a discussion that would not be smooth sailing.

“uhm…. Sir, we agreed that the prototype will not be accessible to all your
users. The prototype will be a sandbox where we will only mimic
functionalities to confirm requirements. We can provide access to some of your
key users if you wish so, but we haven’t planned for any user training and
deployment of the prototype.”

The CEO insisted. “I thought we wanted the prototype to be a usable system
that a subset of users could use to confirm everything before we expand it to
a wider group of users?”

And there it was, clear confirmation the CEO was on a different train
altogether.

“Ok, I think that there is a misunderstanding in what we all mean with
prototype. What you are describing, we call it a Pilot.” I said.

A few exchanges between the Product Owner and the CEO confirmed the Product
Owner and the CEO had a completely different understanding of what Prototype
meant and were thus having very different expectations of what we were presenting.

The Product Owner then asked us to stop the presentation and apologized for
the misunderstanding. We all agreed to have another call to define and revise
the scope of the discovery if needed.

Let’s get specific

If, like in my experience above, you use the terms Proof of Concept,
Prototype, Pilot or Minimum Viable Product (MVP) interchangeably then this
article is for you.

There is a (sometimes subtle) difference between those terms, they all have
their place and use and it is very important for the success of any engagement
that everyone you work with is on the same page.

It is key to project success to apply a strategy for identifying and
mitigating risks in the project lifecycle. Enterprise projects can be
especially complex; Whether that complexity is driven by the scope and scale
of applications being integrated, or the number of unique tasks, forms,
scripts, rules and processes needed to support diverse departments.

Each of the deliverables in the sequence below, along with the processes that assist
in creating them (e.g. – Envisioning), should be thought of and focused as
tools to navigate and discover the unknowns in the project and more fully
inform (through iteration) final construction of the system. Appropriate
fitting and execution on these deliverables will substantially
decrease risk of system fit, security, scalability, and governance.

Let us look at the definition and fitting of these terms one by one below.

Proof of concept (POC)

A Proof of concept is an experiment of a specific approach or design to
validate the feasibility of a requirement or idea.

POC (proof of concept) is typically short in duration and is used to
validate feasibility of an idea. A POC is generally “throw away” in that
it does not result in production ready code. –
Joel Lindstrom

Trial of specific approaches or methods in technology, such as
integrations or plugin behaviors, that eliminates the risk of dependencies
on functions that are otherwise not explicit out of the box features. –
Ron Giblin

Examples:

Validate that the Universal Resource Scheduling can be used to book
course delivery to teachers based on the teacher’s availability,
accreditations, skills, and location.
Validate that an integration between Dynamics 365 and a legacy
application can be done, including rollbacks, retries, timeouts and
errors handling.
A company is interested in a new technology such as Power Virtual
agents, so they quickly build out a functional chatbot around one of
their business processes.

Prototype

A prototype is a sandbox environment where we mimic functionalities to
help gather and validate requirements from a User Interface or business
process perspective.

A prototype is an early but not final representation of the User
Interface, with elements in place needed to perform a system transaction
or part of a process. – Ron Giblin

Prototypes validate how a problem will be solved. It is bigger than a POC
but is not deployed in production. – Joel Lindstrom.

Examples:

Forms and Business Process Flow layout to validate technician activities
to service a job, including the sequence of data inputs and a checklist
of tasks to be performed.
After the POC, Acme corporation prototyped chatbot to a small group of
users to get feedback.
A Power Apps Portals with sample forms, lists and pages to consolidate
Portals requirements.

Pilot

Pilots are small initial deployments of a solution – while they may not be the full and final solution, they should be feature complete for the functionality included and will be used in production in a limited rollout. Lessons learned from a pilot are incorporated to f.e. make a full enterprise rollout smoother. – Joel Lindstrom

A pilot is a production environment of Dynamics 365 or the Power Platform
used in real-world conditions by a small group of users or area of an
organization. The purpose of the pilot is to allow the organization to
determine if the current configuration is the appropriate solution and gives
personnel and users hands-on experience. This reduces the risk of an
unsuccessful wider launch and adoption later. – Ron Giblin

Examples:

A Field Service solution deployed in production and used by 30 users in a
specific region. Following this initial pilot, the system will be
fine-tuned before a deployment to additional regions.
A Sales solution deployed in production and used by 5 key users for a
period of time, before being rolled out to the remaining sales users.
After the Prototype, a pilot of the chatbot was deployed for helpdesk
users in the South office.

Minimum Viable Product

A minimum viable product is a version of the solution that delivers key customer identified features that are aligned and sequenced for delivery according to the roadmap of features identified in Envisioning. – Ron Giblin

MVP is the Minimum viable product – all deployments should have MVP, including prototypes and Pilots so that we avoid scope creep and ensure that the end result is usable. – Joel Lindstrom

Examples:

For a Customer Service solution, the MVP is the case creation and update
including a simplified Business Process Flow for the case lifecycle.
Future releases include an improved Business Process Flow, Case
relationships, SLA and knowledge management.
The MVP for the chatbot pilot included the ability to reset passwords
and open a helpdesk ticket for desktop issues. Future releases include
additional ability like requesting automatic software install on users
machines.

To me, MVP refers to the scope of the solution, whereas pilot refers to the scope of the deployment. – Simon Douglas

Summary Table

The below diagram and table illustrate how POC, Prototype, Pilot and MVP
relate to each other and what is the usual sequence of delivery. However,
each of those are optional and you can pick and choose the ones to use
during your Dynamics 365 and Power Platform project delivery.

Ultimately, following the below sequence is the optimal approach to reduce
risks of unknowns through your project delivery.

A word about project risk and ALM management

While this short article addresses deliverable taxonomy, terminology and definitions to assist sales and project teams in setting expectations and communication, it should be noted that covering all aspects of project risk in detail, is a project discipline on its own.

A full risk management plan will have accompanying risk registers, categories, processes, budget, WBS, roles and responsibilities, and reporting structures. Each project possesses unique risk that need identification and the creation of mitigation plans that sometimes become the basis of on-going ALM and Operations management; As an example there are sometime non – technical risks, such as geo-political elements or events that emerge that can effect supply chains and may require data residency changes for compliance.

In ERP implementations risks and their total elimination are almost impossible. You design and work around your risks and your project charter should have a solid plan to deal with them OR you have already failed. The primary objective of risk management is to minimize impacts of the project unknowns rather than eliminate them completely. This way when you advance through your project stages and your project unknowns are converted to knowns their negative impact on project delivery drop. Your risks still may or may not be there! – Reza Alirezaei

	Proof of concept	Prototype	Pilot	MVP
Purpose	Validate feasibility of an idea	Gather and validate Requirements	Validate solution at low risk by reducing number of users	Functioning solution with enough valuable features to be usable by users
Project Unknowns and delivery risk	High	Moderate	Low	Low
Requires training and UAT	No	No	Yes	Yes
Accessible by users in PROD	No	No	Yes	Yes

Envisioning To Delivery – POC, Prototypes, Pilots and MVP

Let’s get specific

Proof of concept (POC)

Prototype

Pilot

Minimum Viable Product

Summary Table

Authors and contributors