Principles to remember for Analysis and Design

This is a mail that was sent to the Business Analysis team just before we started Phase 3 Analysis and Design. I changed her name from her real name to her nickname to protect her privacy.

From: AJ

To: BPM BA

Date: Mon, Jul 10, 2006 1:42 PM

Subject: Principles to remember for Analysis and Design

A bit long but meaningful for Analysis and Design

* An interpretation of a communication, the least convenient is the correct.

* What you don’t know hurts you.

* There’s never enough time to do it right first time but there’s always enough time to go back and do it again.

* The bitterness of poor quality lasts long after the sweetness of making a date is forgotten.

* I know that you believe that you understand what you think I said, but I am not sure you realize that what heard is not what I meant.

* What is not on paper has not been said.

* A little risk management saves a lot of fan cleaning.

* If you can keep your head while all about you are losing theirs, you haven’t understood the plan.

* If at first you don’t succeed, remove all evidence you ever tried.

* Feather and down are padding, changes and contingencies will be real events.

* There are no good project managers only lucky ones. The more you plan the luckier you get.

* A project is one small step for the project sponsor, one giant leap for the project manager.

* Good project management is not so much knowing what to do and when, as knowing what excuses to give and when.

* If everything is going exactly to plan, something somewhere is going massively wrong.

* Everyone asks for a strong project manager when they get them they don’t want them.

* Overtime is a figment of the naive project manager’s imagination.

* The sooner you begin coding the later you finish.

* Metrics are learned men’s excuses.

* Some projects finish on time in spite of project management best practices. Fast ‑ cheap ‑ good ‑ you can have any two.

* The project would not have been started if the truth had been told about the cost and timescale. A two year project will take three years, a three year project will never finish.

* When the weight of the project paperwork equals the weight of the project itself, the project can be considered complete.

* A badly planned project will take three times longer than expected ‑ a well planned project only twice as long as expected.

* Warning: dates in a calendar are closer than they appear to be.

* Anything that can be changed will be changed until there is no time left to change anything.

* There is no such thing as scope creep, only scope gallop.

* A project gets a year late one day at a time.

* If you’re 6 months late on a milestone due next week but really believe you can make it, you’re a project manager.

* No project has ever finished on time, within budget, to requirement ‑ yours won’t be the first to.

* Activity is not achievement.

* Managing IT people is like herding cats.

* If you don’t know how to do a task, start it, then ten people who know less than you will tell you how to do it.

* If you don’t plan, it doesn’t work. If you do plan, it doesn’t work either. Why plan!

* The person who says it will take the longest and cost the most is the only one with a clue how to do the job.

* The sooner you get behind schedule, the more time you have to make it up.

* The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression.

A word of the wise on reconciliation

Reconciliation is something that you can easily postpone until later. DON’T!

Reconciliation is what the business use to determine if the data has been migrated correctly. It is all too easy to delay, especially when you have data that is not loading 100% of the records each and every time. Here are a few tips and tricks for reconciliations:

1. Start Simple

Start with a count of the no of things that you are migrating. For example a count of the number of clients in the source system versus the number of clients in the target system, and reconcile these as soon as possible, these should be relatively simple. Even if you are not loading 100% of the data, the number of clients in the source should match the number of clients in the target, plus the number of clients that have failed to load. Try as hard as possible to match these.

2. Only count what counts

If you are nervous about the data mapping exercise it can become every easy to try to reconcile every field that you are migrating. This proves later to be a costly and timely exercise because when you discover that this is actually something that cannot be counted, it has usually taken a few days (or weeks) to investigate the various reasons why it doesnt match). Categories of this that you should always/ normally count:

2.1 Customer Money count money coming in (being paid by customers) and money going out (money that will be paid to customers). This also applies to counting factors that will affect the customers money (for example prices)

2.2 Tax Money Dont mess with the tax man, always make sure the source tax amounts, both tax coming in (if applicable) and tax being paid out

2.3 Dates If you have dates that are important do a hash total count of them. For example start dates, next payment dates, end dates. How you do the hash total doesn’t really make a different, just make sure that both the source reconciliation and the target reconciliation program use the same hash count of dates.

3. Don’t count what cant be counted

Don’t try to replicate complicated Mapping rules in the reconciliations. If you are extensively manipulating the source data before creating records to load into the source, don’t try to count them. For example, if you are creating separate records for husbands, wives, children and other members of a family based on complicated rules using their address (or visa versa) where previously they were a single record; don’t try too hard to manipulate the data to force it to match. Make sure to document why it cannot be counted, and be prepared to accept a different viewpoint from the stakeholders on how to count those.

4. Keep lots of people in the loop

Make sure your stakeholder have visibility of the Reconciliations as early as possible, your Business Representative will be able to assist in decide what is required and what isn’t, while the Testing person will assist with ensuring that there is enough test coverage to check the complicated scenarios that cannot be counted.

5. Keep counting

For each load of the source data into the target system that you do in testing, from unit testing all the way through to user acceptance testing, make sure you at least try to reconcile in every run. Make sure that in your reconciliation, you make note of the reconciliations that don’t match because of failures, and where possible, capture the differences. For example, do a hash total of the start date of all the records that failed and see that it matches the differences between what is in the source and target.

Data Migration Key Stakeholders

Key Stakeholders:
Business representative – This person doesn’t need to know everything about the business, but it helps. They will be the person responsible for liaising with the business on the various discussion points that are inevitably raised.
Source architect – This person is the Subject matter expert (SME) of the source system
Target architect – This person is the Subject matter expert (SME) of the Target system
Target Developer – You need to have at least 1 developer who will ultimately be responsible for making changes to the target system to allow for some of the data/ functionality to be supported. If the data Migration project in encompassed within a bigger functional project, this person will be the liaison with the other developers on the team
UAT Test representative – This is a person who will be ultimately responsible for the testing of the Data Migration, this does not necessarily mean the test manager, rather the person on the ground who will do the testing. This person will need to be involved from the start of the data migration project to understand how the data is being migrated, and thus ultimately, how to test it.

Data Migration Lessons Learned – Interacting with the Business/ Client

Interacting with the business at the right level is really difficult because the business sometimes feel that reviewing each data item is ‘too complicated’, ’self explanatory’ or ‘a waste of time’. And for the variety of data items that are there this is reasonably relevant. But, don’t run the risk of not reviewing each data item with at least 1 business representative.

As an example, a field that seems ’simple’ would be ‘Customer Full Name’. This is something that is held in the Source system as a Free Text field, but in the Target, this field is dynamically created using the First Name, Initials and Surname. This means that if we change the way we construct the name that we use to address mail to, this will be dynamically updated.

Thus it was decided that the Customer Full Name is discarded and this will be reconstructed in the target system as part of the data load.

Months later the UAT team were doing a review of data where the client was under the age of 16, who required a parent/ guardian that would act as a representative (and thus receive all the correspondence for), we found that the client’s parent had been ‘lost’. The business then advised that they do not in fact always capture the Parent/ Guardian as an entity in its own right, they actually just update the minor’s Customer Full name with the parent’s name. This then sparked a flurry of activity including the finding that there were +-800 clients where the mail name does not match their First name, Initial and Surname.

This caused concern regarding how much of the Data migration could be trusted, and how thoroughly the analysis and mapping was done because something as ’simple’ as this could be missed.