For more than 15 years, Microsoft Technology Centers (MTCs) have been delivering Proof-of-Concept Workshops that address the business needs of customers. In this blog post, I will draw from my experiences at the MTC Atlanta and, most recently, the MTC Toronto to offer some guidance on how to best leverage a Proof-of-Concept (POC) Workshop.

I’m often asked by customers at the MTC what the difference is between an MTC POC Workshop and a regular demonstration of a particular solution. Sometimes, a customer simply needs a demonstration of a solution, in which case that’s something the MTC may be able to provide. However, if the customer wants to be involved in the design and deployment of a solution, then a POC engagement is likely in order.

A POC engagement usually falls into one of the following categories and can last a few days to a few weeks.

Performance and Scale
These POCs are usually focused on a single workload, with the goals defined by specific performance criteria. These criteria could come in the form of transactions per second or the measurement of user experience response times. The solutions can be hardware agnostic or possibly tightly aligned to a particular hardware vendor and class of device. In its simplest form, this engagement can be summarized by the idea of “how fast can something perform.”

The goals of this type of POC engagement typically are measured either in architectural validation and/or user experience. This type of engagement will validate whether the solution behaves and/or functions as expected.

By participating in a POC engagement, customers get a sense for how easy, or possibly how difficult, the proposed architecture will be to implement. This allows the customer to determine which resources they’ll need and carefully plan the deployment.

What does “Success” mean?
This is often one of the first questions I ask when talking with customers about a potential POC engagement. Asking this question early on can ensure that everyone is in agreement on the scope of the engagement and what criteria is being used to judge completion. As an example, here are two answers that I’ve received to this question:

Example #1: We want to build a SQL Server cluster and do some testing.

Example #2: We want to build an eight-node SQL Server cluster that spans two data centers that are simulated to be 100 km apart and perform five specific tests related to high availability and disaster recovery. These tests will validate whether the solution will behave as expected under these specific failure events.

There is nothing wrong with either of these answers, but the first example does not provide a clear vision of what will determine a successful engagement or how the MTC can best assist in meeting the customer’s business needs.

Know what matters, and what isn’t important
There are often numerous choices in deploying a particular solution, and many will not be relevant to the POC’s goals. The spectrum of these details can range from simple things like, does the name of the Active Directory forest matter all the way through a detailed storage architecture for a Windows Server environment that needs multiple LUNs to support many different storage IO profiles?”

For all the choices that are not materially relevant to the success of the POC, I often suggest to the customer that we’ll follow common accepted best practices or adhere to a published reference architecture. In either case, the customer will know what the MTC intends to do prior to starting the build out in order to minimize the need for rework later in the engagement.

Where do you want to start?
A POC engagement is typically less than two weeks in length. To understand and meet the objective of the customer, we schedule one or more virtual meetings in the weeks leading up to the engagement. Once the customer arrives at the MTC, we have an environment ready for the customer on their first day.

During the meetings before the engagement and during the customer’s time at the MTC, there is no such thing as “too much detail.” Requests for “generic” installs of technologies will be met with responses from the MTC that leave no ambiguity regarding what precisely will be built. The MTCs make use of automation in provisioning common technologies like Windows Server, Microsoft SQL Server, and Microsoft SharePoint. Automation allows the MTC to provide the customer with a manifest of exactly what was provisioned and what options were chosen during installation.

Role clarity and time commitments
All the standard project management disciplines apply in a POC engagement when it comes to role definition and timelines, and there are a few key points where a POC is different from a typical consulting project.

For example, are there specific tasks that the customer will need assistance with yet wants to perform themselves? An example could be the creation of highly available instances of Microsoft SQL Server 2012 leveraging multiple availability groups.

In contrast, are there tasks that the customer does not need to see and can be performed either in advance or in parallel with other tasks outside of the direct view of the customer?

Are there time constraints on the attendees due to certain components of the engagement that need to be completed before/after specific dates based on customer participant availability?

From the first conversation with a customer to the teardown of the environment after its completion, I remind customers that questions are free within the MTC! As with any other engagement at the MTC, the only questions we don’t like are those that don’t get asked.

Mike Jenne has been with Microsoft for more than 16 years and is currently in the role of Chief Technology Architect for the Microsoft Technology Center (MTC) in Toronto, Ontario. Prior to opening the MTC Toronto in June 2013, Mike was a Technology Architect at the MTC in Atlanta, Georgia, focusing on Windows Server and Microsoft System Center. When he’s not immersed in technology, Mike enjoys photography and spending time with his wife and two sons.