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

Tying your Inventory/Assests back to Applications

As I have done many Data Center Migrations, I have found one common thread on the initial engagements....

There is a disparity amongst the support teams and the application owners as to what they call their applications. Support folks tend to shorten or give acronyms to systems and the application teams have their own names as well. This causes some problems within the change management arena as well as documentation. My suggestions are as follows:

• Standardize on the names of systems within your data center
• Standardize on all potential classification area's (ie. locations, support groups, Operating systems, function, etc...)
• Verify that every device ties back to a common system name.
• Within your system documentation you could then track:
•  System Name - Common or Highest Level System Name
• Component: Module or Subsystem Name associated with System (Blank ok)
• Function : Type of device (Websvr, DBSvr, Storage, AppSvr, citrix svr)
• Servicing Location: What locations or Enterprise does this device support?

By doing this you are on your way to having a healthy change management system with accurate information regarding systems and their associated owners, stakeholders, and other upstream or downstream devices/systems.

This is also imperitive in order to have a proper dependency matrix (I'll cover that in another post).