Watch Out for the Matrix

Not too long ago, I was on a review team to look at an RFP (request for proposal) that had, more or less, come in over the transom.*

The project had its interesting points. The basic functionality was essentially a tracking application for custom jobs -- when did the job come in, who touched it last, what did they do with it, etc. It had to hook into a bigger system for planning and billing, but overall, it was fairly small. A routine RFP to evaluate, except for one thing.

This application only had about 15 functional screens plus a couple of administrative screens for login and user set-up. But the requirements document was over 400 pages. That works out to about 25 pages of requirements per screen.

Wow! must have been pretty complex functionality there. No, not really. The UI wasn't that much more complex than using the FedEx site to track a package or using Quicken to see how much you spent last week. So why such a big document?

It turns out each page was a table of about 15 rows, and most of the rows contained a statementnformation like this, "The title shall be Bold." "The logo shall be in the upper left." "The RGB value of the background shall be xxxx." One of my favorites was, "Clicking the Help icon shall open a pop-up window."

Needless to say, there was very little content in this document that explained the real business process behind these screens. And worse, all of these little details about fonts, color, cancelling when you click the Cancel button, etc. were repeated for every screen.

Instead of writing a tight 30-50 page document (or smaller) of very specific 2-3 page functional descriptions for each screen plus an appendix of universal design guidelines, the prospective client paid somebody to create this monster document. Can you figure out why?

Somebody had a big CYA concern.

In the accompanying RFP, was a handy "deliverables" chart with a line item mandating there would be a "Traceability Matrix". That is, somebody wanted to be sure you could match every detail in the requirements to detail in the code design, the code itself, the test plan and the test cases. Aye-yi-yi.

15 rows per page, 4 traces per row, 400 pages of requirements = 24,000 individual bits of information that somebody felt hadto be maintained over the life of this application.

You do not want to do it this way.

Trace if you like, but aggregate the common elements and design specs into one or two documents and check off the screens with a simple pass/fail. Turn the functional description of your screens into user stories or use cases and trace those to the screen that delivers the functionality. Turn thousands of little sentences into a few paragraphs or pages of meaningful content per screen and trace that. Check these chunks off pass/fail, add notes and rework when the grade is "fail". Don't let the Matrix control your project.


* slang for an unsolicited submission. Old-time office buildings often had small moveable windows over the main doors. Imagine someone chucking a bundle of pages through that window into an editor's office.