I have started these series of posts on how to build a System Center Proof of Concept. I guess some explanations on what is a Proof of Concept are in order.
I would begin by stating what a Proof of Concept is NOT:
- It is not a complete project
- It is not a deployment in production (that would be a Pilot)
I have been in some situations where the customers asked for a Proof of Concept, being enticed by the short schedule and fixed price usually associated with this type of engagement. But soon after starting the engagement it was clear that they were expecting a full project (full features implemented, complete documentation) and were asking for deployment in production.
It is my firm belief that a Proof of Concept cannot be a substitute for a full deployment project. A typical solution implementation should have the following phases:
- Evaluation – determining if solution features will meet the customer requirements
- Planning – creating the project plan, schedule and functional specifications
- Build/Develop – for infrastructure deployments this means testing in lab and creating implementation procedures
- Deployment – install the actual solution in the production environment
- Operating – administering and supporting the solution during its entire lifecycle
Skipping one or more phases from the above and rushing to deployment usually create a lot of risks, the more important one being that the solution implemented does not meet the customer requirements.
This is where the Proof of Concept come into place. In a typical evaluation phase the high level requirements are collected and analyzed. Next the potential solution is evaluated to determine if it would meet these requirements. This evaluation is not always easy, especially for complex features, so a Proof of Concept can help with the decision.
A Proof of Concept is an implementation of the solution in a lab environment with the purpose of evaluating if the solution features meet the customer requirements.
Unlike a Proof of Concept, a Pilot deployment is typically performed at the beginning of the Deployment phase to test the deployment procedures into production environment, before going to full scale deployment.
A Pilot is performed in production environment on a limited number of systems (servers, workstations) and involves a limited number of users. The Pilot is a test of procedures, a dress rehearsal.
However a Pilot cannot be performed without careful preparation and going through all the phases of evaluating, planning and building the solution. One cannot test the deployment procedures if does not have them.
Above said, the procedures presented in these series of posts have the purpose of evaluating the solution features.
- The procedures should be used only in a lab environment.
- They cannot be a substitution for a full project
The standard disclaimers apply: The procedures are provided on an AS IS basis without any warranty. Use at your own risk. Myself and my company cannot be responsible if something does not work for you or creates damage.
And remember a Proof of Concept is performed in the lab, not in production.
That recalls a System Center Configuration Manager deployment project I have done two years ago: I went through all the phases, evaluation, planning, testing in the lab and creating procedures. The customer stated they didn’t had SMS or Configuration Manager before.
When we went to the deployment, we found that the Active Directory schema was already extended and they had a Configuration Manager installed siting on a workstation machine under a desk.
Someone has performed a “Proof of Concept” for them 🙂