Viral Requirements

I am sure we have all worked on projects where the requirements are poorly defined and out of date. I had the interesting experience at a previous company to work for a team that had no written requirements. I am serious, not one single documented requirement.

The Project Manager refused to commit anything to writing. No documents and no emails. If you emailed him a question the response was “coming right down”, if you cornered him in a meeting he wanted to talk 1:1 afterwards.

The problems started out small, the PM would start sitting next to a dev and having them make UI changes. He then moved to demanding larger and larger feature changes and getting upset at the large estimates.

Eventually the situation devolved into pure madness, with the PM blaming the developers for the fact the product didn’t match what he had been promising management. We finally reached our limit started brainstorming with ways to put an end to the PM’s refusal to commit to requirements.

I proposed solution that I later named Viral Requirements. The idea is actually quite simple, but the effect it had was amazing.

The first step was to setup a MoinMoin wiki and created a new WikiPage for each section of our application. Each WikiPage contained a table with the following columns:

Requirement:
This was a single, testable requirement. The rule was that each requirement was specific enough that it could be tested and could only have one possible valid result.

State:
This was the current state the requirement was in. There were only three real states: Approved, Needs Approval and DEV. The DEV state was used when the Product Manager was too busy to look at the requirements and approve them. The idea was the Dev would give the PM 2 days to approve a requirement before he went ahead and implemented it.

Approval:
The PM was required to put his initials and a date into this field when he approved the requirement.

So the workflow looked like this:

• Dev writes requirements in Wiki
• Dev emails PM with link to pages that need approval
• Dev waits for PM to approve (or after 2 days marks the State as DEV)
• Dev checks in code and submits to QA
• QA tests against requirements
• QA refuses to signoff on the change until all requirements are approved.

That last line is very important, because of the 'State: DEV' the development and testing could continue, but I could refuse to release the product until the PM signed off on all the requirements. This prevented the PM from blaming the team for any delays and forced him to digitally sign his name next to each requirement.

Within a month, all blame games had stopped and things were moving much smoother. Eventually the PM just rubber stamped everything anyway or had the Business Analyst review the items for him.

A nice side effect of this is the once word got out what we had to do to handle requirements, it brought a lot of scrutiny to the PM and how he was running things. When that company was bought out, he was let go.

He was a really nice guy, but he had obviously checked out a long time ago.