PMI Virtual Library 2010 Shannon Gaw

Creating Work Plans for IT Implementations

By Shannon Gaw, PMP

IT projects tend to culminate in an event, or series of events, when the product or service that the project is creating is moved into production, replaced, upgraded, or modified.These events are usually high-visibility and highpressure occasions and warrant the use of a work plan tool.

mechanism all parties can use to rehearse the work prior to the start time and it also provides a checklist from which to work once the event has commenced. The audience for this artifact is the project team or the particular subset of the project team producing the deliverable. The audience may also include service providers not previously involved in the project and/or those who may have only had minor roles. Why More Documentation? One of the first obstacles to a work plan the project manager may face is the team questioning (or complaining about!) why another artifact is necessary when the project is already subject to a charter, project plan, statement of work, work breakdown structure (WBS), and, in many cases, formal operational change management. Fortunately, these questions are easily addressed. In the case of the charter, project plan, and statement of work, these documents do not provide the necessary details and are intended for a broader audience. The WBS may or may not have the requisite details but it is certainly not in the form necessary to meticulously coordinate an implementation event, which may include parties that may not be parts of the project team. The work plan may indeed duplicate some of the items that are identified and documented in the RFC (request for change) of a good operational change management process but it usually surpasses the RFC in detail. Although an RFC is intended to provide the information necessary for the organization to determine whether a change is scheduled appropriately and meets the general criteria for success,

Introduction In this context, the work plan is a mini-project plan or mini-statement of work (SOW); it focuses on a time-boxed component of a project to produce a deliverable or meet a milestone as opposed to the entire project effort. For instance, the work plan may describe a cutover to a new data circuit, a firewall implementation, deployment of a major software release, or installation of a new database server. For such endeavors, the timeline for implementation is tight, and the nature of the activities and their sequencing cannot be left to chance. The work plan acts as a script for action and gives all participants a central place for all relevant information and coordination. The work plan provides a

the work plan provides exact instructions. A good change management process itself may require that a work plan for major changes be produced in addition to a summary RFC. Furthermore, those submitting RFCs should enter into the thought processes behind creating a work plan, whether they actually write one or not. What is a Work Plan? The work plan document is typically built with office productivity software, such as a word processor or spreadsheet. Project software is not the best output tool because it is less tolerant of free-form text but it may be an input tool from which to import task listings. Although the plan can be created as an online web page or within another application, ideally, it is easily modifiable and can be generated in hard copy. Particularly with infrastructure projects, online copies may not be available during an implementation window. The work plan is typically not too formal, because the audience is the project team itself. Accordingly, the plan author or project manager should not labor over cosmetics (i.e., style, appearance, grammar, and so forth) unless there is a larger audience. In some cases, however, the project manager might pass along the work plan to a customer or sponsor, to give him or her the reassurance that the team is well-prepared for the event; in these cases, the work plan may need to be more polished. Components of a Work Plan The work plan should not contain any information about abstract project management functions, such as those that exist in the project plan and other artifacts of the project. Rather, the work plan contains detailed task information and may also consist of the following sections: introduction, preparatory tasks, implementation plan, communication plan, test plan, risk analysis, back-out plan, post-implementation plan, and contact list. Introduction The introduction or header to a work plan should capture general information such as that found in an RFC (e.g., a control number, a descriptive name, an objective, and the lead). It should also list the platform, application, and environment being changed, any other platform, application, and environment being affected, and the posted outage window. The author should position this information in the beginning of the document to ensure it is easily discernible.

Preparatory Activities Preparatory activities document all of the tasks necessary to get to the actual implementation. The objective is not to recreate the WBS and address all activities that got the team to this point, but rather the handful of critical activities that must occur prior to implementation and that are the subjects of the work plan, which could include, for example, the following tasks: Schedule with change management organization Communicate outage parameters to affected end-users Take and verify backups of data, codes, configurations, and so forth Open incident management tickets or cases with vendors in advance Prepare replacement equipment Ensure that QA completes testing and signs off on QA gateway Inform security and/or facilities about any off-hour activity Each task should have an owner who is accountable for ensuring the task is complete and for reporting back to the project team on the status. Implementation Plan This section details the tasks for actual implementation, which is the core of the document and should include enough detail to generate a critical review as well as provide a map of the actual implementation events. Here again, each task should have an owner as well as start and end dates. This section should define the sequencing and synchronization of all tasks between all participants, which the author might find helpful importing from project management software. Communications Plan Timely communications are critical, especially during timed and time-sensitive events. The sheer inclusion of a communications plan, however obvious, will emphasize its importance to the implementation team and will define how often the team is to communicate and via which mechanisms (e.g., e-mail, instant messaging, teleconferencing, etc.). Portions of the communications plan may be integrated right into the tasks in the implementation plan section. For instance, a typical first step in an implementation plan may be to alert the team, monitoring center, and other interested parties that work is about to commence. After each major task, the owner may

PMI Virtual Library | www.PMI.org | 2010 Shannon Gaw 2

communicate its success via an e-mail broadcast or check in via a teleconference. Test Plan Testing is imperative after any change; application project managers know this well, but sometimes infrastructure project managers overlook the importance. The test plan should list the exact tasks, expected results, and owners. For application deployments, this section refers to the testing in production for the event that is the subject of the work plan. Presumably, systems development life cycle (SDLC) testing is addressed in another methodology document, in which case, this section may very well refer to a documented smoke test plan elsewhere; regardless, the testing and communication of results should be listed here as tasks. Application subject matter experts (SMEs) should either provide the input or sign off on accuracy. For infrastructure implementations, ideally there has been some testing in a sandbox, but typically infrastructure cannot be truly tested until it is in production. Accordingly, the team should perform due diligence in crafting an effective test plan and executing it thoroughly. Risk Analysis Rarely can we expect IT implementations to go exactly as planned. Accordingly, the project team should spend some time considering what might go wrong and how they will respond to it, because six hours into an overnight cutover is not the time to formulate a plan B. The project manager will likely want to document the items that have a higher probability of occurrence and greater exposure in some type of risk analysis section in the work plan. A full risk analysis is usually unnecessary; the author will likely just want to document the risk trigger and appropriate response (i.e., contingency plan). Conversely, risks can be addressed in the implementation or test plan sections directly after the task they refer to. The ultimate risk and worst-case scenario are that the implementation is not going to succeed at this time, which, in this case, will require the team to back out. Backout Plan There is always a risk or combination of risks that, if they materialize, will kill any chances of success for the activity described in the work plan; therefore, the team will need to consider, prepare for, and document a rollback or backout plan. The objective is to roll back or back out any changes and return the production service or product back to its original state and then try the implementation again

another time. Team members may be flustered, frustrated, tired, and/ or nervous when this happens, so it is imperative they have a documented plan to follow, no matter how obvious. The plan must identify a trigger (a metric or observation) that requires a decision on the rollback. Also, the plan must identify the individual(s) responsible for interpreting that trigger and making the decision to back out. This latter role may be filled by the technical lead, the project manager, or project sponsor. Finally, if a rollback is executed, it should be tested, and the plan should describe this testing, whether it uses the test plan documented here or another one. In creating the backout plan, the team needs to have thought through the rollback tasks and how long it would take to bring back the status quo. This backout duration (including testing) should be factored into the outage window that the project manager has asked the customer or change management authority to allow. Furthermore, this begs the identification of a point of no return, or the latest point in time in which the backout plan can be engaged in order to still remain within a particular timeframe. The rollback will likely require some physical preparation, which may include the backup of configuration files, exporting of database records, ensuring a code is present in the source repository, and ensuring any changes to interfaces or other applications can be simultaneously rolled back. Such items are typically parts of sound configuration management procedures anyway. Post-Implementation Plan The perception of success is as important as real success, and project managers have a responsibility to ensure the technical triumphs are not undercut by poor follow-up and customer dissatisfaction. The author uses the post-implementation section to document all those activities that will soften the perceived rough edges of the implementation. Despite any miracle work performed during the implementation, service consumers will expect completely transparent operations once the implementation window is complete. The project manager may want to define who is on the ground to assist with transitional aspects or perform damage control. The implementation team may feel it deserves a few hours of sleep after a 36-hour work stint, so the project manager needs to set the teams expectations accordingly. Beyond end-user support, there may be other items that are key parts of the post-implementation, such as the monitoring of any elements that were unexpectedly affected by the implementation, updating a configuration

PMI Virtual Library | www.PMI.org | 2010 Shannon Gaw 3

management database (CMDB), or ensuring the new service is included in backup and disaster recovery plans. Resource Plan and Contact Information Finally, the work plan should list all the players, their roles, and relevant contact information, such as office telephone and cell telephone numbers, e-mail addresses, and instant messaging. The work plan should provide escalation contact information to include vendors and any open case numbers and also include collaboration information, such as a teleconference, chat session, and relevant e-mail distribution lists. The team will typically need to contact the organizations monitoring center or help desk to provide status, so this contact information will be necessary too. Compiling contact data is advisable even if there is an online directory, because, first, as noted, during infrastructure projects, the online directory may not be available, and second, because most likely, there will be third-party service providers involvedyou will need their contact information and they will need yours. Templates In order to ensure the requisite variables are addressed and to make the planning process more palatable to participants, the project manager may want to create a template for the work plan document. Templates are especially useful when the project manager pushes down the planning and coordination responsibilities to junior project managers or technical leads. In some cases, a project manager may be accountable to a project management office that requires artifacts to adhere to a certain standard. The template also provides the opportunity for the project manager to embed checklists and content specific to an organization or consistent throughout every project or change activity. For example, every implementation may likely require an entry in a change management system, notation in a CMDB, addition to a backup routine, or approval from an account manager. The template must be a living document. As time passes, the project manager will likely discover items that should be included, refined, or removed to improve the effectiveness of the work plan. As the technical environment evolves, or as the organization restructures, the template will likely need to reflect those changes.

Work Plan Meetings Depending on the nature of the implementation event, the project manager will want to have one or multiple meetings about the work plan. Typically, a project manager or lead will gather a small group to formulate the backbone of the plan, host a larger meeting to gather detailed input, and then hold a final meeting just prior to the event to ensure everyone understands his or her responsibility. The team will likely find that the effort to identify and discuss the material included in the work plan and then performing a group review of the compiled information will be invaluable in itself. Often, the knowledge created and shared in this endeavor is what makes the implementation a success. The project manager or lead should also expect to attend a change management meeting to represent the activity and solicit approval within the IT organization. Again, depending on the nature of the implementation, the project manager or lead may meet with customers or those directly affected by the change to prepare them accordingly. Finally, the project manager or lead may want a postmortem meeting after implementation. Here, the team can review the work plan to determine if all the tasks were executed satisfactorily. The team can document the remaining issues and assign responsibilities for resolution. This meeting may also provide input into the lessons learned knowledge base for the project. The Work Plan as a Critical Tool for Project Management The work plan is an effective tool used to assist in managing the execution of complex IT implementations within a tight time frame. This article reviewed the reason for the work plan artifact, its physical nature, its composition, and the processes involved in its utilization. Although the work plan may only refer to one line item in a project plan or statement of work and may not have the audience and visibility of some of the other project artifacts, it may indeed make or break the success of reaching a projects milestone. About the Author Shannon Gaw, PMP, MBA, is an IT manager in the southeastern United States. He blogs at http://itmgr.org and can be reached via e-mail at shannon@gawsystems.com.

PMI Virtual Library | www.PMI.org | 2010 Shannon Gaw 4