TUG Buzz

After Acme Corporation was well under way with their implementation of a new sales application, it became clear that the reports delivered with the application were inadequate for the company's needs. The business and IT decided that they should write custom reports using a separate reporting application.

Since the sales application go-live date was looming, the team was looking for ways to get the reports developed quickly. In discussion between IT and the business, they agreed that requirements were a waste of time. IT noted that they had been writing reports for this business group for many years and were very familiar with them. The business agreed, the IT folks had been doing a great job of this for years, so obviously knew what was needed. Here was the time saver they all needed; skip the requirements and get to work on developing the reports.

What could go wrong?

The reports development was assigned to Standard Inc, a vendor specializing in the reporting tool. Standard’s team worked on-site at Acme, so they could have access to internal resources if they had questions while developing.

Development work was delayed by the lack of documentation and expertise for the new sales application’s data structure. The reports team had to send questions about the complex data structure to experts in another country in an inconvenient time zone, and sometimes work by trial and error. As these challenges were addressed, Standard’s progress reports began to indicate that the work was moving along.

Due to resource constraints, testing of the reports started late. Then, when the reports testing began, the number and especially the types of issues discovered were significantly more than expected.

Reports sorted alphabetically by location showed Other between Montreal and Ottawa, instead of at the bottom of the report. Months were shown in alphabetic order instead of in calendar sequence. Presentation of percentage increase/decrease was not consistent on various reports, when the values were positive in one year and negative in the other year. There was also inconsistency in precision, with some reports showing dollars and cents, while similar reports rounded to thousands of dollars. These are examples only; there were many other issues with the reports.

Many of the corrections required either significant or complete re-writes, which caused additional delays in development and required more testing resources. Eventually, IT management assigned a business analyst to document key requirements. The business was at first reluctant, but then did agree to spend time with the business analyst. When the sales system went live, very few reports were done, and the business had to manage without them until they could be completed.

What caused these problems?

There were so many reasons this reporting project went off the rails. First of all, it started late, because the need for the reporting work was not expected. This gap was a significant problem all on its own.

The assumption that IT knew what to build didn’t align with the plan to have a vendor do the work. The vendor, Standard, had no knowledge of the current reports and no understanding of Acme’s business. Perhaps internal IT could have done a better job, but perhaps not, as they had no knowledge of the new sales application and data structure.

Although Standard worked on-site at Acme’s offices, they didn’t really ask many questions of the in-house IT team, as they didn’t realize how little they knew. When they did reach out, it was a challenge to meet, because the internal resources had not been assigned by their managers to spend time on working with Standard and were not allocated to the project.

The status reports from Standard were vague, and failed to disclose how far behind they were in their development work. Investigation of some of the issues (months in alphabetic order, for example) showed that some very junior resources were not adequately supervised by the more senior Standard team members.

The lack of documentation and expert resources for the application’s complex data structure was not identified as a risk so there was no plan to address it. It continued to be a struggle to meet with the remote expert.

Testers were not assigned timely so issues were not discovered as early as they could have been. In addition, the significance of the issues and extent of re-development led to much more testing effort than had been anticipated. Although additional resources were eventually added, this step could have been taken sooner had the issues been recognized.

Conclusion

The users of the new sales application were very unhappy about having to use their new system with no useful reports. Skipping the requirements did not save any time at all; instead it cost time and additional resources.

COVID-19 Update

As we continue our 36th year, we are eager to get back to regular in-person meetings at our favourite hotels. However, in keeping with current health guidelines, we must stay home and stay safe.

The TUG Board of Directors will continue to monitor the directives from the Ministry of Health and make responsible decisions for the health and safety of our members and guests, with regards to the re-opening of our Meetings of Members (MoMs). In the meantime (instead of in-person MoMs every two months) we are planning to compensate by presenting monthly Zoom meetings!

We thank You for your patience and co-operation throughout these unprecedented times.

Stay Connected with TUG

The Toronto Users Group is committed to providing you with communications that are timely, relevant, and insightful. Canada's Anti-Spam Legislation (CAS) requires that we receive your permission to continue sending you emails.

You may have already given us your consent. If you haven't done so yet, or if you're not sure, please click on the following link to indicate that you would like to continue receiving electronic communications from TUG.

Should you change your mind, you can unsubscribe at any time, by clicking on "manage your subscription" at the bottom of our messages.

The Toronto Users Group for Power Systems (TUG) is a user group/forum for the exchange of ideas, and specializes in providing affordable education relating to the IBM iSeries, AS/400, System i, and Power Systems platforms. TUG is in its 35th year of operation.