The Terrible State of Report Requirements Gathering

Executive Summary

• The common problems with technical documentation on IT projects.
• How consulting companies overcharge for inferior quality report specifications.
• Why are low quality report specifications such a common problem?

Introduction

It’s interesting to listen to people talk about data warehousing and business intelligence, and how much focus there is on technology. I am curious, have you analyzed how the reporting requirements have been captured that the business intelligence team is building reports towards? If not, everyone who is interested in this field should. We have a major component of the resources that work in BI that have a difficult time writing English, and this is not simply because there are so many English as a second language resource working in the field (although it certainly does not help). The tolerance for shoddy documentation in the area of reporting is shocking to me. Here we have all types of discussions related to the merits of different technology “is Netizza faster and more scalable than TeraData,” etc…, meanwhile the reporting forms are poorly designed, the mock ups nonexistent and the overall forms often appear to have been a completed under a competition where the objective was to see who could complete the form while writing the fewest words while completing all the boxes.

I have seen this behavior a number of times, and it stems from people who don’t actually know how to write, and the instinct when being forced to write, is to write as little as possible, because after all, they are just providing technical knowledge about the application (or at least that is what they think).

The Implications of Borderline Illiteracy

In IT there are few implications to being only semi-literate. Interestingly, rarely does an inability to write, or write logical sentences reduce a person’s opportunities in a company. While educators and the politically correct police would vehemently disagree, American business, and particularly information technology areas of American business are now only semi-literate, which goes some way towards explaining the domination of communication through language simplifying software such as PowerPoint. Edward Tufte, and expert in the display and communication of quantitative information thinks so little of PowerPoint as an application for the communication of information that he wrote a book essentially calling out PowerPoint as a communication platform for idiots. I read it and its hilarious.

NASA’s Take on PowerPoint

NASA actually blamed part of the reason that the senior managers missed information that lead to the Columbia Disaster on the fact that they were over relying upon PowerPoint, which has a natural tendency dumb down the information to be communicated, and that furthermore, this over-reliance on PowerPoint was reducing their analysts and engineers’ writing ability.

The Specification and the Mock-Up

Most reporting forms I have seen have far too much bureaucracy contained within them. A good reporting form only needs to explain the purpose of the report, update frequency, system of origin, etc.. The meat of the report specification is the mock-up. The Different reporting front ends offer different capabilities, all of which can usually be modeled in an Excel mockup. The mock-up needs to represent the actual capabilities of the reporting front end accurately. The method for doing this, and integrating the reports with the application front end, which works alongside it, is described fully in this post.

I observed for months how an IBM consultant billed hours to an account and left for India for a long-term holiday with no mockups. The documentation he created was unintelligible, and he had stopped at simply setting out the fields that were necessary, there was no documentation that described what reports would be created, what their purpose was etc. I had to create the mockups and basically start from scratch, and I don’t think IBM refunded any money that they billed for this atrocious work effort. I have come to find over time that this is the general standard of work from IBM. IBM employs resources next to no writing skills and without knowledge or training on creating reports.

Conclusion

One reason that reports take so long to arrive is that companies choose bad technologies (like SAP BI for instance), but another reason is that not enough resource understand how to create a report specification. A combination of many resource being from India, where English is really a second language, and a lack of interest in selecting for good communicators or writers in domestic resources, combined with corporate inattention on this issue has led to both poorly designed report forms in addition to poorly filled out forms and often non-existent mock-ups. The consequence is that many areas of the business are suffering because they lack the right reports to understand their business and to help them make decisions.