Last week I completed an implementation for a client. This went to plan, unlike another database implementation I was involved in some time ago. Why did this one one go better? Because I learned from the previous implementation that there are three key areas that need to be addressed: data migration; functionality; and user acceptance.
Data Migration
This is usually the hardest part and is often the most disappointing because the existing data is uaually in the wrong “shape” and is poorly entered as well, and fixing it can take a huge amount of time and money and still be disappointing. Consequently anything that can be done to make data migration easier up front should be done. In this case the new database started with the old database so everything has the same field, table and relationship names to make data imports trivial. Junk fields, tables and relationahips were deleted. New fields were added to the new system *and* the old system where appropriate. In the old system the new fields used meticulously hand-crafted calculations to auto-magically clean up the data and calculate key values, so the old system is constantly migrating its own data even while it’s still in production. When absolutely necessary data is manually cleaned-up to sort out issues, and the old system’s interface was updated to prevent bad data from being entered again. All clean-up processes are scripted. These scripts are built-up and refined as the development proceeds and every day the migration process is re-run and checked. This reduced the data migration to a simple process that was completely automated and took less than 2 hours to run. All that was left was to manage the implementation of the new system and the de-commissioning of the old. That was something the previous migration got right: set up a development server that becomes the production server.
Functionality
The database has to do what people need and work as expected. The only way to achieve this is to scope and spec carefully up front, keep the development focussed, and to test, test and test again. It is vitally important to get the show-stoppers fixed the main process have to work end-to-end. Triage the other bugs and solve them based on priority (eg, the reporting isn’t working but that isn’t needed for 6 months, it will be ready then). And manage expectations: let the clients know that after migration there will be some minor issues, and that time has been allocated to fix them promptly. All the major issues should be sorted. Be careful not to delay shipping entirely: go when the system is usable, not finished.
User Acceptance
If the new system is easier to use than the old system the users will WANT to change. Work out where the pain points are in the old system and remove them in the new system. In this case the pain points were: an interface that was illegible (white text on a navy blue background) with an interface that was difficult to find information in; a developer-created user access control system that required manual log-in without providing any real security; a developer-built data entry system that caused data to be lost if the users closed the window without clicking the “save” button; a non-normalised data structure that required excessive data entry but made reporting difficult or impossible. The new system sported a new interface that was significantly similar to the old so the users could see some similarlty and transfer some skills from the old to the new. The faux-access system was removed and replaced with real accounts and access privileges, and external authentication was used to get single sign-on: no prompting for passwords at all. The “save” buttons were removed and data entry just works with no lost data, and the new data structure has reduced data entry time adn made the generation of reports significantly easier.
What could be improved
There is always something that can be done better and for this project it was communication and training.
The development lasted for a couple of months and while those immediately involved in the work were kept up to date, I made little effort to communicate with the other users of the system or the wider organisation in general. Both are important.
I realised this near the end and made sure that before the migration I personally met with or telephoned each user (some are interstate) and walked them through the new system and the basic database processes. This also doubled as the training session. The similarlity with the old system meant that most users were able to transfer to the new system reasonably easily.
I do think that the users could have had more training but the geographical spread made that difficult, and developing material and delivery takes time and money. A user guide has been developed but I don’t really think these are as useful as they could be: for one thing they go obsolete quickly as changes to the system are made, and I EXPECT to be making changes after implementation.
The client is happy and so am I!
No comments:
Post a Comment