Useful strategy documents has to made at early phases of an IT project

Useful strategy documents

Do you find yourself in such situation, that you feel at the end phase of your project: "It would have good if we found the solution earlier" , "would have gone much more smoothly", don't you?

With many IT projects behind my back I think I could summarize what kind of documents are very useful if they have made at early phases of a project. Usually these documents are that ones what project members "hate" to create or like to laze them. But I have to say it's quite wrong practice.

What are these document types?

• migration strategy
• interface strategy
• testing strategy
• going live procedure
• handover/takeover criterias
• acceptance/goal criterias

At this post I will extract my thoughts about the migration strategy.

Migration strategy

The migration strategy document is intended to provide a road map for performing the migration of data from the legacy system to the new system.  It should define the scope and objectives, the critical success factors and risks associated with the data extraction, transportation, transformation and data loads to support the solution. Of course it should describe the conversion and migration requirements of the business too.

This document should be the first product of the migration team of a project. Never let them to wait until the main common requirement or system design document get ready, it should make parallely with this documents.

Who are the targets of this document?

1. The project leaders who should accept the strategy and build it's results into the project 's plan. The managers use this document to understand how the migration team plans to perform the migration, and how the migration may impact the overall project. So they could determine what other project groups are concerned.
2. The members of the migration team.

Mentioned minimal contents of a migration strategy documents

• Logical diagram of the whole migration process
• Data stores
• source systems
• target systems
• intermediate, temporary stores (for example intermediate data conversion, special stage areas)
• Lists of common data types per data modules as
• General ledges
• Inventory
• HR
• etc.
• Strategy plans for 
• Data extraction 
• Data load, import
• Data conversion - if needable
• Error and exception handling
• Testing
• Quality check
• Plans for the technical solution
• Used migration tools
• Custom developed
• data integration tools, frameworks
• Technical suggestions for data moving, for example
• Flat files
• Database tables
• Planned project resources
• Migration team origanization
• Software and hardware requirements
• Project standards
• Risks
• Migration acceptance criterias
• Exact requirements for acceptance
• Metrics for acceptance
• Minimal values for the metrics

Let's go into some details

Logical diagram of the whole migration process

"A picture is worth a thousand words" as an adage says. Some one believe in it someone not, I believe in it. This diagram should show the whole final migration process from data extraction til the checking the migrated data task. I mean it should represent how will the live migration done before the going live date.

Of course allways put a short description after the diagram, to represent all objects, steps that the diagram contain.

This part - at least the diagram - of the document should be made first but finalize last. The first version of the diagram should give a very high level of the process plan for the migration team to begin their work and the finalized version should summarize all changes what has made in plans and all information that has collected in other parts of this document.

Data stores

Commonly a migration process has got source, target data stores but sometimes there are intermediate data stores too. What should you put about them into a strategy level document? Of course not the technical details, so what?

First collect all source datastores. How many times did you find in such a situation when the project's migration teams think that they are ready with the migration, all data has been migrated and checked in the new system and somebody at the client side suddenly ask a surprising question: "Ok that's right, but what about the ... data?".  If you fulfil well this part of the document you could minimize the possible occurence this kind of situtations. Of course it could not guarantee that it would not happened, but how different situation if you could say "Ok that it wasn't specify/enumerate in the migration strategy document what you have accepted earlier."

Never forget to enumerate all target datastores. Usually the solution provider's expert are extremly sure that they know well the target system, but are you sure? It isn't a wasted time if you spend some hour on collection of them. I promise you will head pin with you hand at least once "How good that I have not forget now, what could be wrong if I think on it only near end of the migration process"

Last but not least datastore are the intermediate data stores. These ones what you usually couldn't identify at first version of the diagram, these one comes out when the migration team made decision on data extraction, data transformation and data cleaning procedures.
It's seems sometimes that this data stores aren't necessary, but think on it, how useful are they at migration checking phase, one client side asks why is that data in the target database and you could represent the full migration lifecycle of the indicated data at any phase. What happened with the data after extraction, after cleaning the data, after transformation the data (for example any modification on it) and so on.

Common data types

When you have collect the source and target data source it is time to identify the to be migrated common data types, groups in these data stores. Just put them into a list with a sort description. This table will very useful at migration design phase, for example every row could give the base of a migration import file.

Strategy plans

As you have seen above strategy plans includes plans for 

• Data extraction 
• Data load, import
• Data conversion - if needable
• Error and exception handling
• Testing
• Quality check

Why they are important? I hope most of them speaks for themself.

Commonly every plan should include who, how and when will do the actual step. The strategy plans chapter should declare what kind of steps are factually necessary. Usally only the conversion step is a choiceable step but it allways depends on the actual project goals.

Data conversion step means for me all data modification, converting and cleansing requirement. For example when target data store could accept the data if two extracted data concatenated, or on the extracted data has to run special algoritmic function to calculate the imporable data and so.

Don't forget! Don't go into low level details. This document should make as fast as can, you will have time at migration design phase to extract the details, so just put here only the common, has to be decided, approved high level plan description.

Plans for the technical solution

So were ready with strategy plans, everybody understand what steps are necessary what not, who will do them. It's time to go into some technical details, of course severely staying in high level too.

What you have to decide? Think on this questions:

• What kind of technics do you want to use for extraction, for loading data.
• How do you want to implement the data conversion. Will you store the extracted data in an intermediate database, file. Will you have to develop a conversion tool?
• Is human resources needable for data cleansing or we could use algorithms.
• Do have the client any migration or data integration tool (Oracle Data Integrator, Talend etc.)
• Who will made the live migration, if live data so protected it's possible that the supplier's expert hasn't rights to run the final migration, so how will than it made techincally.
• How would techincally documented the migration process (for example where and how will the log data generated)

Planned project resources

The strategy documents has to contain information for what and how many resources want the migration team to use during the migration.

Some of them already accepted in the project's foundation documents but it's good to repeat them here. So what I think is necessary here? These ones

• Migration team origanization. If you don't do it earlier then name all member of the migration team. (client and supplier side too). Gave the exact details responsibility of each member of this team. Who will be the leader, who has to make decisions, who will be participate in the design, in the development, in testing, in quality check, in live migration.

• Software and hardware requirements. As much as possible at this level specify what kind of softwares and hardwares want to use the migration team during until going live date.

• Project standards. Specify what kind of standard has to keep the migration team during the design and development, such as version control, code standards, naming convetions etc.

Risks

It's what is means. Try to collect any risks that could influence the planned migration process. Anything that could break it, slow it and so on.

Migration acceptance criterias

This is the hardest to part of the document. Usually the client does not know how will they accept the migration. They have got many requirements, many idea about the migration. 

And usually they want to answer for questions that directed on acceptance. Try to not stop here, collect as much information as you could!

Some food for thought sentence

• Try to collect the exact requirements for acceptance of the migration.
• Try to indentify the metrics for acceptance. Which one is harder, a real acceptance metric, which one is just a to be measured metric.
• Try to set minimal values for the metrics, what values is acceptable by the client - which means what has to reach during the live migration.

Summary

I hope I could well summarized what does a migration strategy means for me. I hope too that it will helpful for you and you could use them at your project too.

At next post I will talk about the interface strategy document which is quite simiraly as the this migration migration so I will try focus on the differences.