| Congratulations! Your project has made it this far. Now is the time to see the fruits of your labor. By this stage in the project, all the heavy lifting has been done, all the tough decisions have been made; now is the time to execute the rollout plan. The following suggestions will help the rollout proceed: -
Modify the project plan from the pilot to include lessons learned ” The rollout plan needs to leverage all prior experiences. During the pilot, the deployment methodology may have worked for some portions of the pilot community, but not for others. You may have discovered that the hardware deployment takes longer than anticipated. These types of things need to be incorporated into the rollout plan. -
Acquire and deploy any additional resources ” From the scalability results and the support results of the pilot, additional resources may have been projected for the rollout. If so, at the start of the rollout, or as the pilot is finishing, acquire and train these new resources. The project needs all its resources to hit the ground running. -
Build a rollout schedule that can be met ” This cannot be stressed enough. With all the preparation, there should be a very good understanding of how long activities take. This should be reflected in the rollout schedule. Now that the project has hit the rollout phase, the finance group and the executives will be watching for delays and cost over-runs. With proper project planning and rollout scheduling, these risks can be minimized. In addition, it is best to ramp up the rollout. Since this could possibly be the first deployment for the production team, time must be allowed for the team to make some mistakes. By not having a heavy deployment schedule up-front, more time can be spent getting it right the first time and developing a healthy deployment methodology. -
Don't be afraid to push off the deployment date if there are uncompleted or untested steps ” The rollout needs to be delayed until they are addressed. The rollout must leverage the work already done and the lessons learned from previous experiences. If something is encountered for the first time during the rollout, the timeframes for resolution are shorter. Thus, it cannot be stressed enough that no steps can be skipped in the pilot or POC stages. -
Have more than enough support staff available to respond after an area is deployed ” When the go-live date occurs, there is normally an initial time period when user support requirements are high. These support requirements can range from installation and configuration issues to questions about the technology. The project support group needs to have more than enough staff available to meet the surge in demand. After the initial surge, support should level off again, as experienced in the pilot, though at a higher level. -
Document so this project can be handed off to support ” When the project moved from pilot to rollout, a transition book was created. The same thing needs to be done for support. The existing transition book can form the basis of the one given to support. This support transition book should include items like the following: - - How the software gets patched ” Once the software is packaged in an automated install, bug fixes and enhancement patches will come along. How these get put into the production system depends on the requirements of the support group and how involved a patch is. If the patch involves simple file replacement, then the new file could be distributed through an automated means, or the existing automated package could be updated. If the patch is more involved than simple file replacement, a secondary automated install may be created. This secondary install should be run after the original automated install. Lastly, any changes to the rollout production systems need to be documented and tested . Since not all users may receive the patch file, there must be a way to identify the users who have the patch. This could be done through the use of a support database that lists the names of users or files to get version numbers from. Preferably, the biometric system has some method to obtain version numbers and patch levels. Even if this information is stored in the registry, automated means could be created to retrieve this information for use by the support group.
- - Who to contact if the IT support group needs support ” While IT personnel are seen in general as the support authorities, they cannot possibly know all the intricacies of the biometric system. Thus, a support point within the vendor's company needs to be identified. By this point, the company should have entered into a service level agreement with the vendor for support. At this level of internal support, the company's support personnel need direct access to a live person at the vendor's help desk. This will ensure timely answers to questions and concerns.
- - Changes made to standard configurations in support of the project ” When the members of the production team were deploying the project, they may have made changes to the standard desktop builds. These changes need to be documented and articulated to the support group. When the support group gets a call for support, it needs to know what is different from the original specifications. The support group may need to re-install the desktop build or change it. By knowing what needs to be different to support the biometric system, additional user inconvenience can be avoided.
- - What types of support activities may adversely affect the project ? ” It is good to know what standard support activities should be changed or avoided when supporting the biometric system. This could include actions like upgrading system files, disabling particular drivers or services, or applying particular patches or service packs . Any inconsistency needs to be documented. At the same time, the minimum and optimum system requirements need to be clear. That way, if software or hardware needs to be changed, the support team can make sure the minimum system requirements are still being met.
|
