Solutions provider takeaway:Solutions providers need to ensure their customers' new applications are fully and properly deployed as part of the production acceptance process. Follow these final steps and complete all of the IT systems management tasks listed in the forms below to help ensure a successful deployment.
Read part one of this chapter excerpt on IT systems management: The production acceptance process.
Step 9: Document the Procedures
The documentation of any systems management process is important, but it is especially so in the case of production acceptance because such a large number of developers will be using it. The documentation for these procedures must be effective and accessible (see Chapter 20 for ways to ensure that documentation is both of high quality and of high value).
Step 10: Execute the Pilot System
With a pilot system identified, forms designed, and procedures in place, it is time to execute the pilot system. User testing and acceptance plays a major role in this step, as does the involvement of support groups such as technical support, systems administration, and the help desk.
Figure 9-1 Sample Production Acceptance Form
Step 11: Conduct a Lessons-Learned Session
In this step, the process owner conducts a thorough, candid lessons-learned session with key participants involved in executing the pilot system. Participants should include representatives from the user community, development area, support staff, and help desk.
Step 12: Revise Policies, Procedures, and Forms
The recommendations resulting from the lessons-learned session may in¬ clude revisions to policies, procedures, forms, test plans, and training techniques for users and support staff. These revisions should be agreed to by the entire cross-functional team and implemented prior to full deployment.
Step 13: Formulate Marketing Strategy
Regardless of how thoroughly and effectively a cross-functional team designs a production acceptance process, the process does little good if it is not supported and applied by development groups. Once the final policies, procedures, and forms are in place, the process owner and design team should formulate and implement a marketing strategy. The marketing plan should include the benefits of using the process; the active support of the executive sponsor and peers; examples of any quick wins as evidenced by the pilot system; and testimonials from users, service desk personnel, and support staff.
Step 14: Follow-up for Ongoing Enforcement and Improvements
Improvement processes such as production acceptance often enjoy much initial support and enthusiasm, but that is sometimes short-lived. Changing priorities, conflicting schedules, budget constraints, turnover of staff or management, lack of adequate resources, and a general reluctance to adopt radically new procedures all contribute to the de-emphasis and avoidance of novel processes. One of the best ways to ensure ongoing support and consistent use is to follow up with reviews, postmortems, and lessons learned to constantly improve the overall quality, enforcement, and effectiveness of the process.
Full Deployment of a New Application
By this point, the production acceptance process should be designed, approved, documented, tested, and implemented. So when does the new application become deployed? The answer is that the process of developing the process does not specifically include the deployment of a new application. When the production acceptance process is applied, it will include the use of a form such as the one previously described in Figure 9-1, which includes all of the activities leading up to the actual deployment. In other words, if all of the tasks outlined by the form in Figure 9-1 are completed on time for any new application, its successful deployment is all but guaranteed.
One of the key aspects of this entire process is the involvement of the infrastructure group early on. The development manager who owns the new application should notify and involve the production acceptance process owner as soon as a new application is approved. This ensures infrastructure personnel and support staff are given adequate lead time to plan, coordinate, and implement the required resources and training prior to deployment. Just as important are the follow-up and lessons-learned portions of the process, which usually occurs two to three weeks after initial deployment.
Real Life Experience -- Celebrating Process Independence Every Day
The IT department of a company offering satellite services to residential users contracted with a consultant to implement a production acceptance process. They selected a financial module of PeopleSoft as their perfect pilot. Everything went flawlessly and the team consisting of the project manager, developers, operations, and other support groups celebrated their modest success. Two months later, several additional modules of PeopleSoft were planned to be installed. But the CIO and development manager had now both moved on and their replacements did not see the immediate value in a production acceptance process. Without it, the implementation of the three additional modules took far longer, and with far more disruption, then the original pilot module.
The new CIO and development manager eventually agreed to follow the process for all future production application implementations. But it came at a price. The original consultant had moved on to his next client and was unavailable for a short follow-up. The development group was familiarized with the original production acceptance process, but it took longer and cost more than if it had been followed through from the start. The important lesson learned here was to commit to a new process for the long-haul, and to make it independent of key personnel changes.
Distinguishing New Applications from New Versions of Existing Applications
Users of a new process understandably will have questions about when and how to apply it. One of the most frequent questions I hear asked about production acceptance is: Should it be used only for new applications, or is it for new versions of existing applications as well? The answer lies in the overall objective of the process, which is to consistently and successfully deploy application systems into production.
A new version of an existing application often has major changes that impact customers and infrastructure groups alike. In this case, deploying it into production is very similar to deploying a new application. Test plans should be developed, customer acceptance pilots should be formulated, and capacity requirements should be identified well in advance. The guideline for deciding when to use production acceptance is this: Determine how different the new version of the system is from its predecessor. If users, support staff, and service desk personnel are likely to experience even moderate impact from a new version of an existing application, then the production acceptance process should be used.
Distinguishing Production Acceptance from Change Management
Another question I frequently hear is: How does one distinguish production acceptance from change management, since both seem to be handling software changes? The answer is that production acceptance is a special type of change that involves many more elements than the typical software modification. Capacity forecasts, resource requirements, customer sign-off, service desk training, and close initial monitoring by developers are just some of the usual aspects of production acceptance that are normally not associated with change management. The other obvious difference between the two processes is that, while production acceptance is involved solely with deploying application software into production, change management covers a wide range of activities outside of production software, such as hardware, networks, desktops, and facilities.
This chapter is an excerpt from the new 2nd Ed. of IT Systems Management, by Rich Schiesser, ISBN 0137025068, Feb. 2010, Prentice Hall Professional, Copyright 2010 Pearson Education Inc. For a complete table of contents please visit the publisher site: www.informit.com/title/0137025068.
This was first published in March 2010