Managing Moving Migrations: What’s Done isn’t Done

TL;DR If you don’t know what the actual end state is your techies will do their techie thing to make you happy and you’ll think you’re finished before you are.

This is not the blog post I had planned to write now, it was always going to be part of this series, Managing Moving Migrations, but logically it should be the last entry because I’m going to talk about how you know its finished. However really that is not something you can leave till the end if you don’t know where you’re going you’ll never arrive. So this should have been the first blog post in the series, except that until we had defined some general requirements and a typical system it would be hard to talk about. We also really need to investigate granularity but we’ll do that next post. So maybe this is the right place after all.

Looking at our requirements the relevant one seems to be:

11. Governors need to be able to show appropriate project metrics

We’ll be dealing with just four metrics in this post but we’ll be coming back to this requirement later on.

Part of this post stems from a conversation with the technical and non-technical staff engaged on a migration project and how easy it is for people’s different view points to give rise to confusion.

So what, in terms of migrating between live systems, does done mean?

This depends on who you are.

• For a user this means that all the content that I’m working on is now in the new system and I never have to use the old system ever again.
• For a manager this means that there is no requirement for additional project time, and hence cost.
• For a techie this means that all the content is in the desired state.
• For a governor this means that they can show that all obligations have been fulfilled.

Superficially they look the same but they don’t exactly match so when someone says that the migration, or part of the migration, is done this can cause confusion. A typical example is when a project manager says its finished and then the governor asks for the final validation report. Hold on says the project manager the budget is exhausted so we can’t do that. Then I’m not reporting to senior management that the project is finished says the governor. What normally happens then is that a techie then uses time allocated to another project to just ‘finish up’ a project reported as finished.

Lets look at another real life example. The developer moves the last of the content and declares the migration finished. A user has a link to the annual reports folder in a document they send to senior management once a year, this link still references the old system. Someone uses that link next year and it fails. They try and find out where their data has gone but the project is disbanded and the third party who did the migration no longer have a contract. If only the Knowledge Management professionals knew about it but the developer didn’t leave any documentation behind.

We also need to add in a basic human trait that is often overwhelming present in technical staff, especially developers, and that is the need to please.

I’ve observed this over the years, in myself and in others, and it seems to be a key part of the ‘developer mindset’ a deep seated need to please people. If you’re not a developer you may well not have noticed this and may instead think that developers have a deep seated need to obfuscate and be obstreperous. The cliche of the dismissive, arrogant and unpleasant developer is there for a reason but developers need to be task orientated and when asked ‘is it finished’ or as I have heard it “why isn’t it finished yet” developers seem to just say “it’s finished” and then often have to actually finish it afterwards, at the expense of the project. Understand I’m not having a go at developers but just reporting on what I’ve seen.

How can we prevent this from happening? We all have to agree on what done means and we have to track that where its visible to all. I’ll talk about how we can make metrics easily visible in a later blog for now I want to look at what done means and why we are going to need at least four.

Lets say we have 5 million bits of content which use around 20 Terabytes of data, the project has a budget of £400,000 and the source platform will be switched off by an external supplier on the 1st of April next year.

Let’s start with the user, what do they think done is.

Its done when I only have to use the new system to access it.

Users don’t care about the size of the content, no-one ever says I have 10 Megabytes of annual reports, they talk in numbers of documents, I have 15 annual reports, each with four supporting documents. So they will appreciate having reports based on numbers of items of content, they don’t care that some of it is much bigger, and as we’ll see later on when we get to “Hey Tech Bro How Big is My Document” document size is one of the least important factors when moving content. They also don’t care about other users content but only the content they use. Thus when a user’s content is available in the new system then the migration is done. They need a report that talks in terms of how many of their pieces of content have been moved.

For managers its

Its done when I don’t have to allocate any more budget to it.

Managers don’t care about the amount of data or number of items being moved they care about costs and when everyone else reports that they need no additional resources, which could be people or computer resources, then its done. To them a project is finished when all tasks are finished. This means they need to track all of the ‘softer’ tasks as well including handing over documentation to the Business As Usual team and reports to senior boards. The metric that will concern them will be a ‘value’ burndown or burnup. This is the cost of people’s time and computational resources. If there is a fixed amount that can be spent this is best shown as a costs burndown, otherwise a known tasks burndown is more appropriate, which for a moving target is going to be hard so we’ll come back to that later.

For technical staff its

Its done when all the content has been migrated

The technical staff don’t care about the numbers of documents but as throughput is likely to be constrained by volume, which as we’ll come back to is later can be hard to figure out, then a metric that shows how much volume is left to migrate is going to be best. Interestingly by showing actual content volume migration against theoretical content migration the amount of friction can be calculated and this metric is of great interest to the people who are in charge of the project, the governors who nearly always want to know “why is it taking so long”.

For governors however its

Its done when we are compliant with all external obligations

Governors have to ensure that all obligations are met, these are typically expressed as high level milestones and often have little to do with the actual content being transferred. Good examples of this are ‘no active content held on the burning platform’ or ‘The Knowledge Management Function can demonstrate that there is only one copy of each piece of content’ or ‘Business as Usual have been granted access to all project documentation and have accepted it as complete. These can be shown as a burndown against significant milestones.

So we’ll need to track the following to determine when our migration is actually done

• How many pieces of content are still to be migrated.
• How much content is still to be migrated.
• How much budget is left.
• How many milestones are outstanding.

TL;CR If you don’t know what the actual end state is your techies will do their techie thing to make you happy and you’ll think you’re finished before you are.