The Art of a Cutover Plan (Part 3)

Welcome to the third installment of 

“The Art of a Cutover Plan”

Ok, Quick Recap (Click here for part 1,  Here for part 2): 

We have our Structure that we will follow in order to create our Plan:

The structure consists of a Beginning/Middle/End otherwise referred to as phases, and within each phase we have two distinct types of milestones that delineate specific important events within our plan. The first being a completion of specific tasks and the second being specific points in time within the plan.  The second part of a creating a cutover plan was defining what Information our tasks Needed to track.

Now that we have the structure, it is time to actually build the plan around the identified milestones.  I will be using an excel spreadsheet to track and manage our plan. For today, our simple plan will be moving a server from one location to another. Our assumptions are that any pre-migration activities have been completed and we’re a go for this particular cutover. 

Now the idea of this plan is to be able to see the structure and flow of how to create something that is probably much more complex in your own environment.   Keep in mind, the process is the same no matter how complex the plan.   So based on the need to move a single server from one room across campus to a new server room, the assumption is that we will have completed testing plans In regards to both the infrastructure as well as any applications that live on the server.  In our plan we will reference initiation of testing plans however the completion and build out of those plans will have done prior to the migration.  

The first thing we have done is to define our Milestones.  Now I have used the Task Type to help me filter all "M" (Milestone) tasks as well as “C” (Communication) tasks to show my communication plan.

 

So the basis of our plan has Both types of milestones that occur in all phases Of our migration plan.  In this example there are three milestones that have hard start times and two milestones that have dependent start times.

The next thing you do is to insert tasks based upon when the need to occur in the plan, either in front of or after any of these defined milestones.  Keeping in mind you should note any communications that need to be sent out as well.  After you have thoroughly gone through and defined all the tasks that need to be accomplished, go back through your plan and add the specifics and resources that will be completing those tasks while validating with those resources the duration and dependencies of each task.  This will give you a very complete and robust plan.  You should continue to have meetings and review your plan with the resources that are listed on the plan until you get to a point where everyone agrees that there are no other tasks that need to be added or modified.

By completing all of the fields (columns) in your plan, you will be able to filter for your other types of tasks such as a communication tasks that will be able to make up your communication plan:

We should know the how, when and what is being communicated, as well as who is doing the communication.

Now this plan is a very simple illustration of a server move, however It does show you the process you can go through to create a very in-depth plan. This plan I created here is a 30 step (task) plan.  My normal plans go from 250 tasks to over 400 depending upon the complexity.  The very complex usually reference other plans that another PM lead is responsible for and I just reference the time frames of key items in their plan that impact mine.  Here is a picture of the full plan:

Plan Execution!!!

As you actually go through the plan, completing tasks and informing team members of start triggers, you should be monitoring the status of the overall plan.  In order to do this, you have to track the original start times and expected durations.  By doing this you can track if an individual task is running late, as well as if the plan is being brought in earlier than expected. This helps in managing resources and preparing the testing teams to potentially come in early or late depending on what is happening.

Communications and status updates:

There is  usually a bridge that is open during the migration for direct resources doing the work.  There can be a secondary bridge used for status updates and con calls as needed.  During the migration, you should send out status updates to stakeholders and team members. 

The updates should contain the following information :

General Status stoplight (Green, Yellow, RED)  

The top portion of the status should be a short executive overview of the current status.

The next 3 sections of the update should contain the following and pulled directly from the plan (cut-n-paste):

1. Completed items since last update
2.  In Process Items
3. Items coming up in the next (X) hours (or whatever your status update schedule is).

Just filter the sheet and then cut and paste the information.

By providing this information you will be actively keeping everyone in the loop as well as being proactive for any tasks that are early or late so dependent tasks are aware of what is coming up.

Requirements

In order to provide this type of communication, you will need to have some automation built into your plan.  The plan I am showing has some hidden columns that allow me to track task status as well as a couple of macros that update fields when they start/complete by me simply pressing the button while I am on that particular task.  So the hidden fields are :

1. Original Start Time 
2. Original End Time
3. Actual Duration (Calculated)

These fields are either calculated or completed at the beginning of the cutover.  So before the cutover starts, I copy the start times and past values into the Original Start times, and do the same for the Original End Times.  The Actual Duration is calculated based upon when each task is completed.  The red pen's in the picture show calculated fields.  So before the cutover starts, I copy the start times and paste as values into the Original Start times, and do the same for the Original End Times.  The Actual Duration is calculated based upon when each task is completed.

In addition to the status, I have a pivot table that updates the status count so you can see an overall picture of where you are from a task count perspective:

This can be the summary portion of your status update.

I hope you have found this blog post informative and useful.  Check back for udpates and please feel free to comment and share.

Thanks,


*** If you are in need of planning help don't hesitate to contact me.  We have reasonable bill rates with great tools to help you get your projects done.  More importantly, if you have a large change event, give me a buzz, we can manage it for you.

The Art of a Cutover Plan (Part 2)

Welcome to the second part of “The Art of a Cutover Plan”.  Click here to visit Part 1

Before we start adding tasks to our cutover plan we need to finalize the structure and rules of engagement. Let’s define our task structure. We will have a rule for the things or tasks that go into our plan that we must follow. 

Start each point with “Every Task will have …”

• an actionable title and description:  


• What does that mean?  When you’re implementing the plan the person that is responsible to execute that task should be able to do something to act upon a task.  In other words the task should be actionable and not the stated outcome.  Stated outcome is potentially multiple actionable tasks whereas every task has a specific resource that will accomplish that task as well as a duration that that task will be completed within. They should not have to ask "what does this mean?"...

• a Task id:
•  Identifier that is unique and able to be referenced by other tasks for dependency definitions
• a resource:
• A particular person that will accomplish this task
• a group:
•  If you plan on being very detailed in making sure every task has a resource then you might want to include a group in case you need to contact someone within that group to help the resource out or get resource time allotted.
• a start time:
•  If the task has to start at a specific time (otherwise this is calculated depending upon it’s dependency)
• a duration:
• All tasks should have a defined duration in minutes 
• an end time:
• This should be a calculated field. We need to know what time tasks and/or milestones should be scheduled; however, they should be dependent upon the start time plus the duration of the task.
• a dependency:
• Any dependencies that impact the start time of this task should be listed and identified by the other task IDs.
• a Status:
• At any given point in the cutover process, each task should be in a specific state (Not Started, In Process, Completed)

Optional fields:

There are several optional fields that you don’t have to track, but are nice to have for reporting, or planning purposes.

1. a Task Type:
1.  Define the task type as Separator, Communication, Testing, Milestone
2. an Activity Type:
1. Let’s you group your tasks based upon multiple resources working through tasks to accomplish a shared outcome (like MDF completion required resources from multiple groups but occurs during a particular part of the cutover).  You can have a plan within a plan capability for filtering.

This will be the basic construct of your cutover plan and you can build upon it from there.  Oh and by the way, you can use the same methodology for developing any project plan.  We are showing this to see how important a cutover plan is and what a minute by minute activity looks like as well as the tools that I use to help implement that.  In the example Cutover Plan I review, I will show many other fields used for tracking purposes. If your change event is very important and you need to track tasks being ahead of schedule / behind schedule then you will need some other "calculated" fields to track that.

In the final Blog Post we will cover the management of the plan and the communications expectations.

... Click here for Part 3 ...

The Art of a Cutover Plan (Part 1)

Welcome to the first part of “The Art of a Cutover Plan”

The purpose of this blog post is to walk through the creation and the process that you go through in order to create a cutover plan.  The goal is to create a well-thought-out process that will allow you to organize your thoughts when thinking of what needs to be covered in the case of a major change event that an organization might be facing.  With that being said, I decided to break this blog post up into three sections.  The first section covers the strategy and the “why” as it relates to the need of a cutover plan, the structure of the plan, and method that we will use to fill out the plan.  The second section is about the creation of the plan, using the structure and the methodology mentioned above. Finally, the third blog entry will be about the implementation of the plan, the ways you intend to communicate it, how it will be managed and what the expectations of the cut-over weekend from the Stakeholders perspective will be.  So let's get into the methodology or as I like to refer to it the philosophy!

Now, I know that talking about a cut over plan as a philosophy sounds a little bit out there; however,  when you think about it, it’s really a good driving force to define the “why” when you are doing  this cutover or change event.  If you understand the “why” you have some guidelines to follow to make sure this is a non-impactful change event.  That, after all, is the reason we do planning, to diminish the amount of risks that we take when implementing changes. No matter what your Change event, a change event plan should be a required Deliverable.  For Migrations, It most certainly is, as well as being repeatable depending upon the number of applications involved.

 So let’s look at our first phase of the cutover plan.  We need to create a structure in this first phase as the structure is going to be the building block that will help drive to completion of the cutover plan.  Just think of a cutover plan like a story.  You will have a beginning, middle and an end.  There will also be some key building blocks that we define that are used throughout our plan to support it, while it is being developed.  Those building blocks are referred to as cutover milestones.  Now the second building blocks are in areas of planning that define specific timeframes.  Milestones will help delineate between those  phases, as well as, within those phases.  The important part of the phases is they are easily communicated and well defined periods of the cut-over process.  So what I mean by that is, we are going to define specific terms that coordinate with my beginning, middle and end.  For the purposes of my cutover plan, I will refer to them as "Pre-Cutover", "During Cutover", and "Post Cutover".

We have defined our base structure for the plan and we have defined some building blocks that we’re going to use as reference points in order to build the plan.  Anything added to the plan, will have to drop into a particular phase either before or after a defined milestones.  That brings me to the different types of milestones. 

In my summary blog post I mentioned that there are milestones specific to a date and time.  A hard deadline if you will.  With that, milestones have hard deadlines that will occur within a specific time and other activities will either happen before or after that milestone.  The second type of milestone can be tied to an activity completion. That means a task or several tasks have been completed and will represent a milestone within the activities on the cutover weekend.  Now this milestone is not specific to a time or a hard deadline, but it is dependent upon certain tasks to be completed.  Once this milestone is achieved usually there’s some sort of the communication that occurs after it.  Sometimes that milestone is the completion of the testing of the tasks that create a milestone moment.

So in completing the structure of our cutover plan we have defined the following:

1. We have a purpose and understanding of the reason why we’re doing this change and what the impacts are if it is not done properly.
    
2. We understand the phases that we will be working with (beginning, middle and end).
3. We understand the clearly defined separators (milestones) that we will be tracking with and documenting to.

This completes the structure of our cutover plan and how to start it.  In the next blog I will walk through the process of creating the cutover plan using this structure.  We’ll talk about adding tasks understanding what questions to ask in order to fulfill the milestones that we provided.  So before we end, Start to define your plan by understanding what your beginning, middle and End.  These can also be referred to as phases.  Identify what the milestones are that separate those phases as well as any specific milestones that you can think of that will live within those phases.  We will start to build our Tasks that look like:

Next Blog entry:  The Art of a Cutover Plan (Part 2) Click to visit

feel free to comment and share!!!