The last three parts of our conversion blog (see all of the posts here) go hand-in-hand and require the most time on the project plan. Development - During development of the conversion routines, you may want to consider using error handling standards based on corporate standards. This is where data
I have a rule – any conversion or upgrade will require the creation of a decommission plan. A decommission plan should include the following: A list and definition of each database, table and column (source and target). A list and definition of each of the current programs in use (you
The physical data model should represent exactly the way the tables and columns are designed in the in the database management system. I recommend keeping storage, partitioning, indexing and other physical characteristics in the data model if at all possible. This will make upkeep and comparison with the development, test
I have a question --- do we need a logical data model for a conversion? Here are my thoughts. I believe the answer is yes if the conversion has any of the following characteristics: The target application is created in-house. This application will more than likely be enhanced in the
Don't be shy! Interviewing people BEFORE or AFTER a facilitated session just takes a bit of confidence, and good preparation. Building your confidence gets easier and easier the more you participate in interviews. The objective is to prepare and not waste anyone’s valuable time. I like to prepare notes based on
So, the facilitated session is over. You have gathered a tremendous amount of information, and you may be wondering what to do now. I like to categorize all the information, and hopefully during the session you did some prioritization of the requirements based on company goals. If you have never
To complete any conversion, with success, always seems to require a good understanding of the existing environment and platform. In fact, I would not move forward without the background analysis work products. You may want to consider some analysis of what is already in place, and understand: What is the
Testing, testing, testing...do we really need testing? The answer is YES! Always! The big questions are: 1. How do I test? 2. What do I test? 3. Do we just do program testing or do we include testing data quality? 4. What about volume testing? 5. Who signs off on after-test completion?
Let’s get this out of the way: EVERY PROJECT HAS ISSUES at one time or another. Sometimes a technical issue may need to be communicated to the project manager, escalated to gain resolution or just communicated within the project team. I seem to always hit issues during testing, and these issues never fail
Issue management defines the process of documenting and escalating any issue that the project may encounter during development, testing and implementation into production. The process document could include the following: 1. How does the project find the issue? Usually, an issue is reported by one of the business users or conversion
