Reflections on an Inprotech Release 4 Upgrade

I have recently been involved with delivering a project for a client that required moving the firm from release 3.3 of the system to the latest release 4 patch.

The firm has approximately 150 staff and uses virtually all of the client/server Inprotech modules as well as the Client WorkBench. The software is integrated with their document management system and there are a significant number of in house written reports.

As a result, the system touches on all users in the business, as well as clients. The project was therefore staged in a manner that tried to mitigate risk of disruption to the business from the change as much as possible. We also wanted to introduce the new versions of the software in a manner where the staff could take advantage of any useful new features and, as an adjunct, document the overall upgrade process so that moving to future releases would be easier.

The approach we took was as follows:

1. Analysis & Preparation. All release notes were reviewed and assessed with the business to determine which areas of new functionality could be utilized by the firm and what level of configuration was required.
2. Unit Testing. The software was installed in a test environment to allow configuration and testing of the new functionality identified in preparation for acceptance testing.
3. Integration Testing. The newly configured software was tested then with integration to Word, the document management system and the in house reports.
4. Acceptance Testing. Representatives from various areas of the business were co-opted (conscripted??) to test the software that they were affected by in a test lab environment with test cases that mimicked everyday usage of the software.
5. Deployment. Training materials showing the changes in the software between the different versions were constructed and training courses were delivered to reinforce the major changes. Actual deployment occurred over a weekend when the production database was upgraded and the new requisite client components for the user PCs were delivered via a silent install process that had previously be developed and tested.

In my view a formal approach is necessary for major upgrades where lots of people are affected but the same principles apply to smaller releases, just less effort is necessary and you could probably skip the acceptance test phase (or make it significantly smaller) and the deployment step will be easier.

For this project we generally achieved our goals with an excellent team effort however what are the things that others maybe should be aware of?

The first thing we found was that the effect of the new release on end users was fairly minor. This is because the big ticket items in the release: electronic data exchange, trust accounting, IDS, Canadian GST, Clerical/Professional WorkBench are only applicable if you do massive amounts of renewals, work in a particular jurisdiction or use the new web modules.

There are some interesting minor enhancements that we took advantage in the back office of but, to be honest, the most beneficial piece of the release to the user (outside of being on the current version for support) is the ability to maximize the screens and have the software, in the majority of cases, re-size itself to display more information (and remember that it has done it).

The re-design of the reminders screens is also nice for the project but that was available in a previous release so not necessarily a release 4 thing. As well the Launch Pad now docks and remembers where it has been docked between logons which adds to the overall usability a little bit.

Note however that the re-sizing only applies to screens that are of a tabular nature so it does not do anything for screens with fixed field locations such as the Instructor tab or some of the name tabs. Note also that it has only been applied to the main screens in the Cases & Names module. The other programs and the timesheet, billing and accounting modules are being done in a future release or releases as I understand it.

The second thing we found was that we had quite a few issues with the document generation Word DLL and had we three iterations of this crucial little piece of code delivered to us during the testing phase. Hopefully it is now stable in the current patch level.

The main issue was around the way Null values are handled. Instead of returning no value for Null the dglib.dll (the module that handles data requests from letters) was now returning a space. The client’s templates were checking for no value and colour highlighting these fields in the letter to indicate possible missing data. When a space was returned the check no longer highlighted the field.

The new dglib.dll is also less forgiving with poor coding. Whilst this is probably a good thing in some respects it does mean that some recoding work may be required for letter templates and testing of letters is critical to a successful upgrade. The following were typical of the issues found:

• You must always register a Docitem BEFORE it can be referenced in any VBA code. In the previous version all Docitems were registered by a separate DoItems call, usually at the end of the macro, but now they are registered dynamically so the order is more important.
• The registeritem must nominate the correct destination type and cannot be blank. In the previous version it would default to being a string returned to a bookmark if there were errors which sometimes allow the template to complete even though the code was wrong.

The nett result was that a significant number of the Word templates used were affected and as a result a good deal of work was necessary to make changes to the templates and testing them. As the generation of documents is probably one of the key deliverables to the system to the business we really had to make sure that this was right before we deployed.

Other things to look out for:

• The reminders program seems to handle security slightly differently (although we are not sure if it is a bug) so we had to do some extra configuration here,
• There is an annoying bug that has been introduced in the DocItems program that resets the flag for images and stored procedures even though you don’t change it.
• The client PC now requires to have some software to be loaded to it. (Previously the client had run the entire system from the server).
• We had to upgrade SQL server 2000 to SP4 with the latest hotfix to resolve some policing and billing issues.
• Some custom changes were needed to the upgrade scripts because the client used different codes to CPA (eg WO instead of PCT and different code for ‘Leave Open in Word’ delivery method ) .
• An extra cleanup script was required to remove some duplicated names attached to cases in CASENAME (mainly contacts but also other name types). We at first thought that this was something site specific but other clients have had the issue and CPA support have a script to assist if you know to ask for it (which you do now!).
• A fairly significant workbench issue in drilling into case details which were corrected by stored procedure patches, which presumably will be incorporated into the main release at some stage.

Lastly, a special thanks to guest editor Dave Palmer who revised and wrote some of the more technical items here!!