If a system is not established at the beginning of the project or if the system is not dead simple for everyone to use, the project can devolve into a pile of email. Without a simple solution several 100’s of emails end up in inboxes every day and the email mountain becomes a huge burden on the entire project team. In addition to the time it takes to get through the emails the new business requirements don’t make it into the actual specification documents and it becomes difficult to know what the true requirement is at a later point in time. It ends up slowing everything down and eating up a bunch of extra time\budget that could be better spent doing actual work.
At times, I have been guilty of not setting up systems to manage the changes that came in and emails quickly overwhelmed the team. One such time was a global project that had team members in the US, Asia, Europe, and Australia. It was running 24 hours a day. During this project it was not uncommon to have a couple hundred emails in the morning and then accumulate another 100 during the course of the day. It was next to impossible to actually get real work done among sifting through the piles of emails as many of them were not applicable to every recipient, some had little things for various team members tucked in the middle, and some had various to-dos for processes unrelated to the rest of the email. Then because of the volume of correspondence, the conversion specifications became out of date and it became a complete mess.
There are different ways to avoid this mess and different teams like to manage the work in different ways. For some teams ticket or task reporting software work. With these solutions, I find that as soon as some minor bump happens it falls apart as the project moves faster than it takes to resolve the bump. There is also some ramp up speed for each new team member that joins the project to learn these additional tools.
Keeping it as simple as possible seems to work the best for me and here one simple way to help manage the changes and defect reporting. This way won’t work for people that like detailed tracking of lots of status codes and teams the like high level dashboards that track the actual of number of changes that have been requested\resolved in a week. If those metrics don't need to be tracked, this method allows the data migration team to react quickly to what needs to be updated\reviewed for each conversion at a glance.
This method works the best if specification documentation is maintained in Excel or similar spreadsheet software. To manage the changes\defects, just add 1 or 2 additional columns to the document labelled “Status (Spec Change\Defect\Development Status” or something to that affect. These columns will be set to some value indicating that the mapping rule for the field changed, that a defect is reported and potentially more information about the defect, and where the data migration programmer is with the status of the change (released\currently under review etc). I prefer one column and just fill it with the important status or note. Then take the column with the mapping rule, duplicate it, update the rule for the affected field, and flag the field as something that needs to be reviewed. If a defect needs to be addressed, just update spec change\status column. Once the change\defect is addressed, the migration programmer, just clears out the field.
The below print screen is a simple example that I mocked up that outlines how this could look.
The document may look a little different based on how the document is set up, but keeping the process to a minimum amount of steps, with a minimal amount of technology\documents seems to work well even for complex projects involving multiple legacy with teams spread around the globe.
If you have any questions or comments, please email me at firstname.lastname@example.org or call me at 773.549.6945.