What is an “implementation plan”?

Question

I was recently given the task of creating an implementation plan document. When I asked for an example of one that I could look at, I was told to look at the Project Plan that had already been created an use that as a base. I'm still a bit confused on what I should be creating.

Can anyone point me to a good example out there or to something that explains what this is and more importantly the details about what it should contain.

Answer 1

An implementation plan is a technical document that provides a high level view of the overall structure of your project. Its contents may vary, depending on what information you have in other documents, like the Project Plan, and if this is the first time you are writing an implementation plan it couldn't hurt to ask for a template or the plan for a previous project.

Some examples:

• W3C - Implementation Plan for Web Accessibility (short and simple)
• NASA JPL - Software Management and Implementation Plan For The Microwave Limb Sounder (MLS) Carried on a NASA Earth Observing System (EOS) Satellite (formal, pdf)
• University of Melbourne - National Servers Program Implementation Plan (hardware stack oriented, pdf)
• California Institute of Technology - Software Implementation Plan for the Advanced Composition Explorer Science Payload (formal, old, pdf)

From these, the University of Melbourne one has a very typical structure:

1 OVERVIEW

2 POLICY DEVELOPMENT WITH THE SECTOR

3 SERVICE AND SUPPORT ENVIRONMENT DEVELOPMENT PLAN

3.1 ITS positioning

3.2 Infrastructure overview

3.2.1 Virtual Machine configuration

3.2.2 Data storage infrastructure

3.2.3 Connectivity and Bandwidth

3.2.4 Failover and redundancy

3.2.5 Authorisation and Authentication

3.2.6 VM Capacity growth

3.2.7 Data centre development

3.3 Deployment plan

3.4 Access model

3.5 Roles and responsibilities

3.6 Support and the National Servers Program helpdesk

Answer 2

This depends a lot on the size of your project, and what exactly you are implementing. I've found that a lot of formal documents are overkill for most small projects. I usually start by writing myself a list of things that need to happen before I implement. I ask myself questions like:

1. What actually will be implemented?
2. When do we want to do it, and what do we need to check before we do the implementation?
3. Do users have to be out of the systems when we do the implementation?
4. Is there a time-dependency (i.e. outside business hours, on the weekend, etc) for our implementation?
5. How many actual servers/workstations/databases are going to be updated?
6. Is this a brand-new application, or an upgrade to an existing system (the answer to this changes your implementation plan A LOT)?
7. What are the actual steps we will take to do the implementation?
8. How will we back up the existing system before we implement, in case we need to roll back?
9. How will we test the application after it is implemented?
10. How do we roll back to our backup?
11. Who needs to be notified about the implementation (before, during, after, statuses, etc.)?
12. Do we have documentation of what the changes are, and how the users can use the new changes?
13. Who's going to take support phone calls from users?

Once I have answers to these kinds of questions, I write up the plan, usually as a basic Word document, with different sections and a timeline. I like to put in the detailed step by step parts, with paths to files, etc., logins, etc., so I will have all the sticky little detail in one place.

As a morning person who has to do installs when I'm normally sleeping, I like the comfort of a list of all the steps I need to take, so I don't forget something. I think it is worth writing down the communication steps you'll take, particularly if a group is doing the implementation, and some items are dependent on the others, or if you aren't all in the same place. (ex. I will email Fred when the database updates are complete, so that he can do the web server updates, Fred will email us all when he's done, so we can all do the testing)

Then, once you have one that works, it can become your template for future updates to the same system, or be a jumping off point.

Answer 3

Implementation is about construction and planning is how will you go about doing that construction.

Your implementation plan should include:

• what things or parts will be implemented

• identify a way of knowing when you have completed the things to be implemented

• time estimate and schedule of the implementation effort

• the number of people in the team that will work in the implementation

• whenever applicable, the order in which things will be implemented (what parts should be implemented first)

• figuring/deciding on a way of monitoring and tracking progress or problems

• identifying quality acceptance criteria and goals

• test stages and testing iterations

• what [corrective] actions will be taken when and if things don't go according to plan

Since implementation is part of the whole project development effort, some of these things may already be mentioned as part of the project plan.

This link points to a simple 'implementation roadmap' document from Construx Software http://www.construx.com/File.ashx?cid=1951

From Construx Software here is a useful check list of tasks for a construction lead: http://www.construx.com/File.ashx?cid=1935

Answer 4

You develop log frame of your project, which shows relationship between Inputs, activities and intended results(outputs,outcome and impact ie goal of your project), from the log frame you develop annual work plan, the plan should draw activities from your log frame each year.