The new official data migration dates have been released.
It seems we're going to perform a simulation in the weekend before we all go to holidays, which will be the entire month of August. I don't really believe that this will happen since there is a lot of work to be done by the project sponsor teams, specially when it comes to quality. There was no more tests performed since the testing team has come form Easter holidays and it seems that there is no implementation plan regarding the tests we've identified some weeks ago.
We are still 3 months away, so it can actually be done if the sponsor acts fast.
When we get back from the holidays, in the first week of September, we will only be performing simulations until the real data migration happens in the beginning of October.
There are rumors from some sponsor people that the this new data migration date will not happen and that the project will be postponed again to January. These people are the same that have already predicted the other postpones and their justifications for it were always right. I'm afraid they are right again since they are pointing out the quality of the data migration and the quality of new system as major show stoppers. As I've stated before, a lot of testing is still required.
Thursday, April 22, 2010
Day 379 - Data Migration Team Leader is Leaving
Our data migration technical team leader is leaving. He had already planed to leave by the end of this data migration project, when it was scheduled for July. The fact that the project has been postponed didn't changed his plans, so he resigned.
This means that the team has shrink to two people and I will be assuming the technical team leader role. Possibly the team will be increased later on, since the data migration simulations require at least 3 people.
This means that the team has shrink to two people and I will be assuming the technical team leader role. Possibly the team will be increased later on, since the data migration simulations require at least 3 people.
Thursday, April 8, 2010
Day 372 - Project Due Date Postponed Again
The project due date has been postponed four more months. It looks likes the data migration will now happen in the 4th of October.
This happened mainly because the target system will not be fully developed up to June.
It looks management wants to keep the data migration plan to June and give us some months of force holidays. I do hope management won't go with this plan because it is impractical.
It is wrong to believe that the transformation rules can be frozen for 3 months when there will be massive development on the target system. And the project sponsor teams already know it by experience, whenever it was required to change something on the target system there was always a considerable amount of mapping rules that had to be redefined, implemented and tested. Plus, it is also wrong to believe that whatever tests the testing team will perform over this 3 months will not require any mapping changes.
This postpone is a great opportunity to define and implement the test plan. Some of the people from the testing team, which I've been talking to, have seen the number of preliminary tests we've identified and agree that it would be unfeasible to define and implement a testing plan if the data migration was to be performed in June.
This is actually the first time I'm on a data migration project were, once set, the official D-Day had been postponed. And in this project, it has already happened twice!
Like in the first postpone, and as far as I know, the data migration itself is one of the few projects that was on schedule by the previous plan.
As in the previous postpone, this probably means that we will have extra resources for most of the time, considering the amount of work of the data migration team in this stage.
But it is still not clear what management will do regarding all the changes that this postpone brings.
This happened mainly because the target system will not be fully developed up to June.
It looks management wants to keep the data migration plan to June and give us some months of force holidays. I do hope management won't go with this plan because it is impractical.
It is wrong to believe that the transformation rules can be frozen for 3 months when there will be massive development on the target system. And the project sponsor teams already know it by experience, whenever it was required to change something on the target system there was always a considerable amount of mapping rules that had to be redefined, implemented and tested. Plus, it is also wrong to believe that whatever tests the testing team will perform over this 3 months will not require any mapping changes.
This postpone is a great opportunity to define and implement the test plan. Some of the people from the testing team, which I've been talking to, have seen the number of preliminary tests we've identified and agree that it would be unfeasible to define and implement a testing plan if the data migration was to be performed in June.
This is actually the first time I'm on a data migration project were, once set, the official D-Day had been postponed. And in this project, it has already happened twice!
Like in the first postpone, and as far as I know, the data migration itself is one of the few projects that was on schedule by the previous plan.
As in the previous postpone, this probably means that we will have extra resources for most of the time, considering the amount of work of the data migration team in this stage.
But it is still not clear what management will do regarding all the changes that this postpone brings.
Wednesday, April 7, 2010
Day 371 - Tests Needed
The massive data migration performed over the weekend was positive.
We got some errors, some due to dependencies and but nothing critical nor that we were not expecting.
One positive result from this weekend action was a request from the management team. They loved the counts so much that they want us to identify some data tests that should be performed.
We've identified almost 100 simple data tests, most of them queries, that should be performed over the source data, the migrated data and the loaded data to check if there were no records lost nor information mismatch.
They should finalize the document with identical tests related with the business itself.
And it looks like the testing team will start gathering and testing again this week.
Still, we are worried with the tests and the testing plan because the tests are totally ad hoc and there is no testing plan whatsoever.
We got some errors, some due to dependencies and but nothing critical nor that we were not expecting.
One positive result from this weekend action was a request from the management team. They loved the counts so much that they want us to identify some data tests that should be performed.
We've identified almost 100 simple data tests, most of them queries, that should be performed over the source data, the migrated data and the loaded data to check if there were no records lost nor information mismatch.
They should finalize the document with identical tests related with the business itself.
And it looks like the testing team will start gathering and testing again this week.
Still, we are worried with the tests and the testing plan because the tests are totally ad hoc and there is no testing plan whatsoever.
Day 366 - Massive Data Migration
This next weekend will be bigger because of the Easter holidays and we will make a massive data migration and loading during this next three days. It will serve to test the performance and massive loading on a clean environment.
We have already prepared the files and have scheduled their loading in GIS during the next days.
We have performed simple counts in order to check if there were no records being lost among the way. The project sponsor management team loved it.
We have already prepared the files and have scheduled their loading in GIS during the next days.
We have performed simple counts in order to check if there were no records being lost among the way. The project sponsor management team loved it.
Day 365 - One Year
The data migration project has completed one operational year.
This is also the last day of one of our team members which was responsible for the GIS file loading and reporting.
The project is kind of stalled. There is no real advances of the data migration problems nor on the testing area. There is a critical error, a true show stopper, on the account area for over two weeks now, and it seems the only ones that are interested in solving it are the ones that can't solve it because they have no knowledge about it.
The tests continue to be an head ache because now the tests are stopped for the Easter holidays.
We are only a few weeks from the first simulation and there are still no tests formalized what so ever. By now, the tests should already be implemented and automated, but they don't even exist!
The project sponsor management team seems comfortable with this situation, but this is a serious problem and a critical concern for the data migration team.
This is also the last day of one of our team members which was responsible for the GIS file loading and reporting.
The project is kind of stalled. There is no real advances of the data migration problems nor on the testing area. There is a critical error, a true show stopper, on the account area for over two weeks now, and it seems the only ones that are interested in solving it are the ones that can't solve it because they have no knowledge about it.
The tests continue to be an head ache because now the tests are stopped for the Easter holidays.
We are only a few weeks from the first simulation and there are still no tests formalized what so ever. By now, the tests should already be implemented and automated, but they don't even exist!
The project sponsor management team seems comfortable with this situation, but this is a serious problem and a critical concern for the data migration team.
Subscribe to:
Posts (Atom)
Posts
