Proof-of-Concept

A proof-of-concept enables the design to be tested in a business environment. Organizations often have a test case database, a set of pre-configured test cases coupled with their expected results. The proof-of-concept can be applied to this test database, and, if all goes well, the documented results will be equivalent to the new results. A proof-of-concept aims to answer all question posed by the Deployment Design, proving that it meets all needs efficiently and with minimal risk.

It is generally fast allowing for ample time to refine the design based on a limited set of data. There are usually several rounds of proof-of-concept, followed by design refinement. The last round in the proof-of-concept should be integration of some internal applications. Integration of a corporation’s shared services often adheres to a standard model of sign-on by early adopters, followed by general participation and, lastly, the stragglers. Demonstrated success with early adopters makes it easier to use those applications as references for general adoption.

Early Adoption

Mission critical or revenue-building applications should not be chosen as your first application. A less risky strategy is to choose an important application that will not completely disrupt business operations if there are issues during roll-out. For example, a divisional portal serves as a natural staging ground for a single sign-on (SSO) roll out, rather than an accounting system at the close of a fiscal period.

Also, limit the number of applications roll-outs in the early phases so process flaws can be driven out, results demonstrated, and immediate success recognized. Minimizing organizational risk while maximizing visibility is the optimal roll-out strategy. This plan positions the deployment team with the appropriate product experience to take on critical applications.

General Participation

Although the deployment project begins with a single application, the requirements of other internal customers should be assessed at the same time so that a general purpose system can be built. The central IT group should be able to accommodate the diverse criteria and schedules of the satellite groups in order to provide service that is representative of the larger organization. Schedules must have sufficiently large windows, allowing the satellite groups time to build changes and upgrades into their application’s deployment and quality assurance (QA) cycle.