Toolkit for IT Project Management

Deploy

DEPLOY phase of IT Project ManagementKeywords: Configuration, Training, Beta Testing, Parallel Runs, Go-Live
The Deploy phase is further subdivided into the following activities:
Configuration: All the end users and administrators should be identified, their machines set up with the required software and supporting tools and required permissions should be granted.
Training: Classroom type training is usually most effective for more complicated systems that typically enable a complex workflow. The training should have presentations centred on the main concepts, business context, and showcase successful use of the application (perhaps other local deployments); in other words the presentation should build up an appetite for the users on the new systems. Users should be provided with a hard copy of the training material so that they can refer to it very quickly and make ad-hoc notes as the training progresses. Perhaps the most important type of training though is use of the application, and for this purpose several mock-up scenarios should be created, each with increasing complexity of use, and each emphasising a different part of the functionality.
Beta Testing: In Beta testing, the users now work on a realistic work scenario, but the users are encouraged to ‘explore’ all facets of the functionality as well as all workflow scenarios. This is done in a structured fashion using the test cases written during the Develop phase. A testing issue log should be kept in which issues are clearly logged. Note that the priority of each item should clearly and mutually be classified as follows:
  • Enhancement: This issue is a feature requirement that was NOT part of the original scope of the project (as defined in the acceptance criteria), or part of the native system functionality.
  • P1: High priority (Blocking issue), this item has to be resolved before testing can continue.
  • P2: Medium priority: Needs to be resolved before go-live is declared
  • P3: Low priority: Needs to be resolved before the project is completed, but not a pre-requisite for go-live declaration.
Parallel Runs: This phase is only relevant if the project is replacing an existing system. In this phase users are expected to populate the new system with “live” data, such that an objective comparison can be made between the old and new system outputs, as well as performance metrics. The period over which this should be run should be minimised because (usually) the effort is more than doubled, so typically parallel runs of 1-2 weeks are expected.
Go-Live: The definition of go-live is the event at which the new system becomes the primary tool for decision making and data input and output, and the old system (if there was one) may be used only for verification purposes only. The system should be declared as Live when: - All P1andP2 testing issues have been resolved; - Users have been migrated to a production environment; - Business sponsor agrees that go-live should be announced