PoC GUIDELINES1. All PoCs require:
a. A valid CPQ quote and this is a mandatory requirement. The quote must clearly contain the “system(s)” configuration
b. A unique opportunity ID within Salesforce
c. A comprehensive PoC test plan indicating success criteria which is signed off by the customer
d. A detailed solution design document depicting the intended PoC setup
2. The POC team will confirm within 2 business days availability of stock for the PoC. Assuming all requested stock is available then the DC configuration teams will require a minimum of 15 business days to Pick, Assemble, Configure, Position the PoC equipment in the CoE PoC Area and provide VPN network access.
3. The PoC Service provides a 100Mbps VPN uplink. The internal customer network depends on the POC configuration and could be either 1Gb or 10Gb.
4. Work with the customer to create an agreed Test Plan containing a Detailed Configuration Diagram and well-defined test cases. Each test case needs to have Measurable Success Criteria. This is the most important component of delivering a successful PoC.
5. Keep the customer engaged through the entire PoC process. Do not surprise them with a Test Plan that the account team created without the customer’s involvement.
6. PoC Test Plan review with the customer is extremely important to ensure the environment, test cases, and success criteria are in line with their expectations. This meeting should happen as early as possible but not before at least one internal review with the account team has taken place. When meeting with the customer make sure all of the PoC stakeholders are present.
7. Always get detailed information about the configuration, test cases, and success criteria. In cases where there is flexibility on what equipment to use, simply state it in the Test Plan.
8. It is not uncommon to change test cases and success criteria during the PoC setup or execution phase. Ideally this should not happen because there was enough planning and there was enough information to draw the right conclusions on the test cases. But just like anything else, we do not live in a perfect world and differences in configurations, software versions, and other variables in the environment may impact the results that were expected initially. As long as there is a reasonable explanation and understanding from the customer on the changes there should not be a problem changing them. Ideally these changes should happen during the internal dry run.
9. An internal run (dry run) should always take place several days before the project is delivered to the customer. Our experience has shown that the more time is spent on dry runs, the higher the success rate is for the project. Sometimes due to the nature of the test it might be difficult to do a dry run, especially when there are time constraints. The main point here is that during the planning phase you should always allocate as much time as possible to do dry runs and also enough time to make the necessary changes in the configuration based on the preliminary results/findings from the dry run. The last point is very important because in some cases you will learn something new after the dry run and you will need time to adjust the tests or configuration and will need additional time to not only do this but also to run the tests again. Although meeting the test plan success criteria is our ultimate objective, we also use the dry run to provide input to the presenter on his delivery. Here is where we have a chance to suggest using different terminology, changing the sequence of tests, or even adding diagrams or white boarding to ensure the information is presented clearly and effectively to the customer.
10. Documenting a PoC is extremely important so that the knowledge obtained during the project can be shared with others or used in future projects.
11. Hardware: The CoE will source the required PoC equipment however; third party equipment or loan equipment is the responsibility of the requesting country and/or the customer.
12. Software: The CoE will source the required PoC Software. Any additional third party software and licenses is the responsibility of the requesting country and/or the customer.
DEMO GUIDELINES1. During which sales cycle should I request a demo? An interactive demo is useful tool to engage the customer during early stages of the sales cycle. However we do require the respective account team to position the solution prior to the demo. If assistance is required with this, please select the relevant "offering" from the CoE portfolio.
2. Who should attend the demo? The account team is required to take ownership of managing customer expectations. The demo is setup to provide a technical overview of the defined solution content as listed in the demo catalog`s.
3. Please ensure you provide all information in the demo request tool located
HERE #ThoughtLeadership#Blog