4 of 5: Top 5 Mistakes Collecting SPM / EIM Project Requirements

This is probably the most common mistake. You have an allotted amount of time for requirements, you get to the end of that time and you stop… or you at least say you’ve stopped in your status report. Meanwhile, you are vigorously working behind the scenes to “patch up a small leak here and there” as the the captain of the Titanic might have said.

The Problem

Denial and delusion are two of the benefits of the human condition we like to call coping mechanisms. It’s also a proven phenomenon that the smarter and more successful we are, the less likely we are to admit mistakes or failures. Sometimes we can do this by blaming others. Most times it more convenient to put on fake smile and say everything is fine. For those that yearn to avoid conflict (probably 90% of us), this is the preferred approach.

Gathering requirements is not an exact science. Rarely do we encounter a client who holds a 100% clear understanding of what they need and what they want in their system. We start these mammoth sized projects hoping to learn everything in 2 to 10 weeks, depending on the size. But there is no concrete method for determining how long this will take. Through years of experience we have our benchmarks, but stuff happens and it happens more often than not. Resources become unavailable; decisions get pushed up to the infrequently meeting steering committee, plans change, etc, etc.

The Solution

The typical and realistic requirements phase should end with a requirements document and all supporting material signed off by the client. Part of the supporting material is a list of open issues that everyone is still working on. Missed requirements should not be a secret, they should be identified risks. Notice that I’m not suggesting a project get held up because the requirements phase isn’t complete. This isn’t realistic in most situations. You can usually move on to design with what you have. But your loose ends need to be public knowledge and need to be addressed ASAP.

A common occurrence is to sweep “minor issues” under a rug. Avoid this practice; every project has issues and most of them will be minor in size but all are potentially large in effect on scope. The accumulation of a bunch of minor issues can be a problem and minor issues can turn into large issues as you investigate them. Either way, you want to make sure they’re documented and everyone is aware. The worst case is to have a minor issue explode late in a project and have to explain why it took three months to get it on the list.

In fact, when I’m reviewing requirements documents a big red flag gets hoisted if I don’t see any outstanding issues on the first few revisions. It’s statistically improbable to finish this phase with all loose ends securely tied. So wipe away the fake smile and put on a real one. The truth will set you free.