People are getting pre-production stress.
Things should go smooth, but since people do know that the tests should have been better, they get stressed.
Today, one of the people responsible for the data migrated for the system go live tomorrow has just came to ask me why the data has only 379 records. That is the same person that defined the data source scope, the transformation rules and has been validating the this data for the last 6 months...
In the end, it was all correct, it was just a pre-production stress attack.
I think this shows how uncomfortable people really are with the data migration quality assurance procedure.
Friday, March 26, 2010
Thursday, March 25, 2010
Day 358 - Go Live Files Ready
We have received the source files and have loaded them into our staging area.
We have executed the data migration for the entities and created the GIS loading files required for the go live.
The files have been loaded in the quality acceptance environment without a single problem. Tomorrow the testing team will check if everything is in order and, if so, the data will be loaded on the day after.
We have executed the data migration for the entities and created the GIS loading files required for the go live.
The files have been loaded in the quality acceptance environment without a single problem. Tomorrow the testing team will check if everything is in order and, if so, the data will be loaded on the day after.
Day 352 - Data Migration Plan For Go Live
We have just received the plan for the data migration part that is required for the new system kick-off.
We will receive the source data, loaded it in our staging area, execute the transformation rules for the entities and create the GIS loading files for the acceptance and production environments.
Since a postpone has not been granted for the new system go live date, the testing team seems to be working a bit harder and things seem to be a lot better.
We will receive the source data, loaded it in our staging area, execute the transformation rules for the entities and create the GIS loading files for the acceptance and production environments.
Since a postpone has not been granted for the new system go live date, the testing team seems to be working a bit harder and things seem to be a lot better.
Day 345 - New System Go Live
The new system will go live with a new product.
Since this is a new product, only a tiny part of the data included in the migration scope will be loaded at that time.
This will happen on 29th March.
There has been problems with the tests, which can resumed to the fact that the tests are not yelling the expected results and are seen as insufficient by many people involved in the process.
Management did tried to postpone the go live for two weeks. But the project sponsor has denied this request, so, the system will go live as planed.
Since this is a new product, only a tiny part of the data included in the migration scope will be loaded at that time.
This will happen on 29th March.
There has been problems with the tests, which can resumed to the fact that the tests are not yelling the expected results and are seen as insufficient by many people involved in the process.
Management did tried to postpone the go live for two weeks. But the project sponsor has denied this request, so, the system will go live as planed.
Wednesday, March 17, 2010
Day 335 - Reprioritization
The project sponsor is not very comfortable with the current dead line compliance, so management has reprioritized the migration of the business areas.
This happened because management believes that there is need for a greater focus on some business areas where it comes to the data migration.
In practice, this means that credit insurance has been defined as non-priority data to be migrated.
I'm actively involved in this business area and my opinion is that this is actually a mistake.
Credit insurance is equivalent with all other business areas when it comes to mapping and errors, and the other business areas are not "on hold" because of the migration.
The reason the project sponsor is afraid is because the mapping team cannot solve the problems faster or there are dependencies from other players and the testing team is no longer working daily.
There are several management mistakes here. Testing should be a priority now, but the tests have been reduced and the testing team, which was performing ad-hoc tests 4 hours per day, is only doing up to 16 hours of testing per week. Some tests should have been automated by now, but there is not even a plan to do so, so testing will continue to be ad-hoc.
Management should focus on forcing third party players to comply with their tasks and dates instead of reducing the scope of data being migrated. As an example, we are waiting for some data files for at least 6 weeks, but the third party responsible for it doesn't actually care. They've sent a couple of files last week, to shut us up, and they came all wrong...
This happened because management believes that there is need for a greater focus on some business areas where it comes to the data migration.
In practice, this means that credit insurance has been defined as non-priority data to be migrated.
I'm actively involved in this business area and my opinion is that this is actually a mistake.
Credit insurance is equivalent with all other business areas when it comes to mapping and errors, and the other business areas are not "on hold" because of the migration.
The reason the project sponsor is afraid is because the mapping team cannot solve the problems faster or there are dependencies from other players and the testing team is no longer working daily.
There are several management mistakes here. Testing should be a priority now, but the tests have been reduced and the testing team, which was performing ad-hoc tests 4 hours per day, is only doing up to 16 hours of testing per week. Some tests should have been automated by now, but there is not even a plan to do so, so testing will continue to be ad-hoc.
Management should focus on forcing third party players to comply with their tasks and dates instead of reducing the scope of data being migrated. As an example, we are waiting for some data files for at least 6 weeks, but the third party responsible for it doesn't actually care. They've sent a couple of files last week, to shut us up, and they came all wrong...
Day 332 - Yet, Another Team Reshape
There has been yet another team reshape.
In practice this means that there is currently only two business people responsible for the mappings, one which aims to more practical actions and another that aims for business rules validation.
In practice this means that there is currently only two business people responsible for the mappings, one which aims to more practical actions and another that aims for business rules validation.
Friday, February 19, 2010
Day 325 - Sponsor Team Reshape
The team is constantly changing from the beginning of the project and that is not helping the project at all.
This time, the sponsor team has suffered another reshape and one key person will move away from the data migration project.
The person how's being transferred has been reassigned to another task, but this person is one of the few key team members because he knows all the the areas like no one else. The person that is replacing him only knows a small subset of what he knows.
I believe the sponsor team has made a bad move regarding the data migration project.
This time, the sponsor team has suffered another reshape and one key person will move away from the data migration project.
The person how's being transferred has been reassigned to another task, but this person is one of the few key team members because he knows all the the areas like no one else. The person that is replacing him only knows a small subset of what he knows.
I believe the sponsor team has made a bad move regarding the data migration project.
Subscribe to:
Posts (Atom)
Posts
