This is the first in a series of salvaged draft blog posts that I’ve decided to post despite their somewhat stale state. Hopefully, you’ll still find it interesting.

One of the first responsibilities assigned to me at TMS was the product management of our Marketing Dialogue Manager™ distributed marketing system. At the time, MDM was a large waterfall-style project with a team sized to match. The version of the platform I had inherited was not in a very maintainable state, so every little improvement and bug fix seemed to take forever. A sizeable feature count meant big business requirement documents that nobody read.

The business analyst would write these great tomes complete with diagrams and tables but:

a) clients wouldn’t verify that the doc articulated what they wanted and

b) developers only skimmed them.

Not a recipe for success.

Requirements

Via http://www.codinghorror.com/blog/2005/03/on-software-engineering.html

At the time I envisioned this post, I was fresh off some formal business analysis training at U of T. The BABOK recommends a “structured walkthrough” as a useful tool for making sure everyone understands the requirements and has an opportunity to provide feedback. In a waterfall-style project, you basically book a really long meeting with everybody and force them to sit there while everyone reads the BR document together. It works, but it’s painful.

In hindsight, it’s just one of many reasons to go Agile.