Continuing the series with our guest blogger, Jeremy Chapman.
As with any IT project, the first part of planning is about building a plan. There are several things you’ll want to accomplish with a pilot and depending on your organization, the importance of each validation area will vary. I think of the pilot as trying to achieve the following key tasks
Once you have the project goals in mind, there are many ways to execute the pilot in minimize user disruption. The idea is to start small and gradually increase the number of pilot seats – ensuring that you have an adequate representation of users, hardware types and sites (or geographic locations). Now is the time to document a plan for rolling out the pilot. You will also want to define success criteria relatively early in the process and what should constitute sign off for each phase. This typically means the number of issues and issue severity that you are willing to live with during each phase – recognizing that things should improve as you get closer to the production deployment. The concept of severity is important here as with any testing. You can use the following as a sample guideline for classifying severity:
Your quality gates should reflect these severity levels and include some count or measure for success. These numbers should get better as you approach production deployment. Here are a couple of examples:
By now you should have project goals, a system for assigning and prioritizing issues and a few quality gates defined for sign-off when moving up phases. Now is the time when we define the high level phases for the project with timelines and who is targeted per phase. I’ll save that for Part 3 of this blog series though.
Stay tuned and thanks for reading,