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!!!

The Art of a Cut Over Plan

*** The first post in a series of three has been posted. Click to visit.

I just sent out an email referring to a basic set of information regarding a "Cutover Plan".  Out of Curiosity, is there interest in a full blown Blog entry wrapped around this message:

"In order to come in with a strong, well formatted plan so everyone involved knows exactly when they have tasks to do and when they need to be done,  let's create a cutover plan with the following:

At a minimum the plan will have  two milestone related markers:

1.  Activity Milestones (when a particular task is completed it marks a milestone for the cutover)
2. Time based milestone (any time that is defined that activities have to be completed before or after it.

Tasks will need to have the following information at a minimum:

ID

Desc

Resource

Start time

Duration

End Time (calculated)

Dependency on another task or specific time or both (defined later)

Each of the defined tasks will occur before or after the defined milestones (#2) above. We will also be able to know if we meet any timeline constraints after we have completed filling out the plan."

Post your responses if you would like to see a detailed step by step creation process for a "Cutover Plan"!  I would go into detail on many more columns of vital information for those really high risk cutovers as well ....

Time vs. Effort in Data Center Migrations / Relocations

I find it interesting that when you're looking at time vs. effort in migration and relocation projects it's not even close to the same. Based on our experience, I thought I'd represent the data in a visual way to show what it looks like from our methodology and how we implement migrations. Now keep in mind, the time and effort levels we are talking about here are in percentages. So the larger more complex and intricate the project is, the longer it will take. However the percentages should still be accurate.

  

Now defining the difference between time and effort can be summarized as such... Time is the duration in which it takes to complete your project, effort can be considered man hours across the entire project.  So we will be dealing in Percentages of both Time and Effort.  100% of time might be 1 yr.  100% of effort might be 3 man years.  If level of effort to complete a 1 yr project is 10% that doesn't necessarily mean it will be completed in 1.2 months.

In understanding Time and Effort, we need to look at the activities that are identified during the completion of a Migration / Relocation.  The first thing is to look at what is the process that you go through in the migration life cycle.  Yes it is a life cycle.  Depending on the number of systems that are impacted with the migration, you should have a repeatable process to implement for each system set. (note, some folks consider systems to be an application.  I consider a system to be any number of applications that share the same infrastructure diagram). In the planning efforts that we manage and work with there are four distinct activities.  These activities make up our methodology called A.A.I.M., Assess Architect Implement and Migrate.

A) If I were to think of an acronym of what really happens it would be SPBM, Strategy, Planning, Building, Moving...  Not a good Acronym so we'll stick with AAIM.  :-)  Project planning is perceived as happenning in the assessment phase but that really is is a strategy phase.  We come out of this with an understanding of what you're end goal is, as well as an overall larger view of how you can get there (i.e. PMO structure and roadmap).

A) So following that is the architect phase. In the architects phases when you're actually planning your architecture.  You will define what the environment will look like.  Once you know what the environment looks like you can plan for your systems to Move, or be created within that new environment.  There are specific deliverables that come out of the Architecture phase (planning) such as your existing environment diagrams as well as future state diagrams for your systems as well as your network infrastructure and all the different things that make up your compute environment.  So really architecture is an aspect of planning and creating deliverables associated with the planning phase.

I) Next we have implement  : This is the building of the environments and sub environments associated with all of the architecture diagrams. Now depending upon the processes that are in place this will entail everything from procurement to installation of base server software as well as application specific installations. At the end of this phase the applications and or system should be able to start testing.

M) And finally we have migration. This will be the implementation of the migration activities as defined in the detail planning the occurred previously.  This is usually the shortest time frame within the migration project however remember that doesn't necessarily mean it's not a larger effort. Size and scope of the migration will determine how much effort is involved.

So to wrap things up, If you are planning any sort of migration, remember to budget for sufficient planning time in order to implement with little to no disruptions.  As many different folks have said: Plan twice, move once... Or was it measure twice, cut once..... Or... you get the picture...  I hope.

Until Next time:

- Darrell

Speaking at the AFCOM Souther California Chapter re: CMDB

Darrell Gardner will be presenting "The Poor Man's CMDB" at the Souther California AFCOM Chapter meeting on May 26th at 10:00 am.

Courtyard Burbank:
2100 Empire Ave
Burbank, CA 91594

Hope to see you there.

What good is CMDB if it does not Tie into Change Management

No matter how cool the reporting you get from your CMDB tool is, if the information contained in it is stale outdated, or just plain wrong.. You are hosed.

The content of your CMDB is as valuable as the last person that updated it. Most likely the CMDB will be around longer than that person so make sure it is up to date.

Make sure that you update your CMDB as part of your Change process!!! Adds/Moves/Changes to any part of the data center should be required to use Change process. Part of the process should be a check piont that updates any dependent documentation. If you have a CAB board that reviews changes, the udpates shoule be required to be implemented as of a time limit within the change window or even as part of the change plan. Possibly the clean up prortion of the plan right after updating monitoring tools. Then review to verify that changes were put in place. Sign OFF!

Do this and you will be ready for changes to your data center environment. Especially in a hosted environment when you have hands and eyes that are less familiar with your environment (New Hires, Contractors, Co-Lo's).

Any Change to the environment or dependency -> Implement Change -> Update CMDB