The work plan should not contain any information about abstract project management functions, such as that exists in the project plan and other artifacts of the project. Rather it contains hardcore task information. The work plan might consist of the following sections.
- Preparatory Activities
- Implementation Plan
- Communications Plan
- Test Plan
- Risk Analysis
- Backout Plan
- Post-implementation Plan
- Resource Plan and Contact Information
The introduction or header to a work plan should capture general information such as that found in an RFC, such as a control number, a descriptive name, an objective, and the lead. It should also list the platform/application/environment being changed, any other platform/application/environments being affected and the posted outage window. The author should position this information first in the document to ensure it is easily discernible.
Prep 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 that is the subject of the work plan. For example, these could include the following tasks.
- Schedule with change management organization
- Communicate outage parameters to affected end-users
- Take and verify backups of data, code, configurations, etc.
- Open incident management tickets or cases with vendors in advance
- Ready replacement equipment
- Ensure 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 that is accountable to ensure the task is complete and to report back to the project team on status.
The section details the tasks for actual implementation. This is the meat of the document and should include enough detail to generate 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 stop times. This section should define the sequencing and synchronization of all tasks between all participants. The author may find it helpful to import from project management software.
Timely communications are critical, especially during time-boxed events. The sheer inclusion of a communications plan, however obvious, will emphasize the importance to the implementation team. It will define how often the team is to communicate and via what mechanisms (e.g., email, IM, voice bridge, 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, the monitoring center, and other interested parties that work is about to commence. After each major task, the owner may communicate its success via an email broadcast or check in on a voice bridge.
Testing is imperative after any change. Application project managers tend to know this well, but sometimes infrastructure project managers overlook the importance. The test plan should list 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, SDLC testing is addressed in another methodology document. In that case, this section might very well refer to a documented smoke test plan elsewhere, but regardless the testing and communication of results should be listed here as tasks. Application 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 thoroughly.
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. 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 could be addressed in the Implementation or Test Plan sections directly after the task they relate to.
The ultimate risk and worst case scenario is that the implementation is not going to succeed at this time; in this case, and the team will need to back out.
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 some other day.
Team members may be flustered, frustrated, tired, and/or nervous when this realization occurs, so it is imperative they have a documented plan to follow, again no matter how obvious. The plan must identify a trigger (a metric or observation) that requires a decision on 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 the technical lead, the PM, 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.
In creating the backout plan, the team needs to have thought through the rollback tasks and how long they would take to bring back the status quo. This backout duration (including testing) should be factored into the outage window that the PM 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 when the backout plan can be engaged in order and still remain within a particular window.
The rollback will likely require some physical preparation. This might include the backup of configuration files, exporting of database records, ensuring 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 part of sound configuration management procedures anyway.
The perception of success is as important as real success, and PMs have a responsibility to ensure 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 implementation, service consumers will expect complete transparent operations once the implementation window is complete. The PM may want to define who is on the ground to assist with transition aspects or perform damage control. The implementation team may feel it deserves a few hours sleep after a 36 hour stint, so the PM needs to set their expectations accordingly.
Beyond end-user support, there may be other items that are a key part of post-implementation, such as the monitoring of any elements that were unexpected affected by the implementation, updating a CMDB, or ensuring the new service is included in backup and disaster recovery plans.
Resource Plan and Contact Info
Finally, the work plan should list all the players, their role and relevant contact information such as office phone, cell phone, email, and IM.
It should provide escalation contact info to include vendors and any open case numbers. It should include collaboration information, such as voice bridge, chat session, and relevant email distribution lists. The team will typically need to contact the organization’s monitoring center or help desk to provide status, so that contact information will be necessary too.
Note that compiling contact data here is advisable even if there is an online directory. Firstly, because as noted, during infrastructure projects that online directory may not be available, and second because there are likely third-party service providers involved – you will need their contact info and they will need yours.