I used to have a truly brilliant boss who had gotten a bit jaded. Sometimes he wasn’t fully connected, simply because he was so incredibly smart. Many people couldn’t really (or fully) understand either what he was saying or the full implications thereof. He was smart, but maybe a bit too smart for the people around him.

It was a pretty dynamic and fast moving environment. We were often in a rush. So it would happen on occasion that we had worked very hard and diligently at resolving some urgent issue, or delivering a nice application, only to learn upon delivery that it wasn’t really what our customers needed or wanted. And he would sigh: “There is never time to do it right, but always time to do it again.” Since then, I have learned there are really only three ways to get your requirements wrong. And I’ve also learned that it’s almost a miracle if you manage to avoid all three of them.

Three ways to get requirements wrong

How might I get your requirements wrong?

1 – you expressed your needs very well. Unfortunately, I recorded them wrong. At some point, we gotta do it again.

2 – you expressed your needs imperfectly, but at least I recorded that well. Now we learn together (the hard way), that we gotta do it again.

3 – you expressed your needs well, I managed to record them well, but in between that recording and my delivery, your needs have changed. Hopefully I find out sooner, but in the worst case after we’ve gone “live” we find out we gotta do it again.

What “it” is that you need to do again, depends on when you find out about the misunderstanding. The sooner, the better, or at least the cheaper it will be.

In the first case, if we debrief the requirements as I recorded them, we ought to find out before I start any project work that we need to sit down again. This is not a good start, but this scenario carries the least risk. After I play back my notes to you, it should be pretty obvious that I missed something. Or misunderstood you.

The second scenario is a bit more tricky. Now I rely on your critical review, and additional reflection on your needs. In particular in hectic and fast moving environments that might be a bit much to ask for. Who digs into the details of meeting minutes, anyway?

The third scenario vividly demonstrates why short(er) development cycles are so important. And also why it’s such a good idea for developers and users to stay in touch.

As Yogi Berra said: “You can observe a lot by just watching.” What I have observed, is that scenario three tends to get “the blame”, when most often it really was one or two. Somehow that’s a “safer” explanation, it appears, because it’s neither me nor you that missed a trick, it was the world around us playing games with us.

What to do about this?

Given these mechanisms, the question arises of course, how you can give yourself the best opportunity to avoid all three scenario’s? Since you cannot know in advance where you are the most at risk, you need to cater to all three scenario’s.

For the first scenario, you mitigate risks by debriefing your understanding of the meeting. Different people have different preferred modalities. Some like writing, others like diagrams or images, yet others record best through talking and dialogue. Therefore you’ll want to try as many media as you can reasonably manage. What is “reasonable” depends on the complexity or ambiguity of requirements and risks of getting it wrong.

For the second scenario you rely on business partners to scrutinize your documentation. And ideally, you want to encourage and motivate them to put in additional effort to reconsider their needs. Some choose a formal “sign-off” to provide extrinsic motivation to business sponsors. The idea being that will make them more wary to commission work they don’t really need. Don’t use this practice to play some “blame game”, but otherwise that might be a good idea.

The third scenario can only be mitigated by staying in close touch with the business throughout the project, so as to ensure needs don’t change (too much) along the way. This is really about embracing change, one of the cornerstones of Agile and iterative development methodologies. Waterfall approaches have a hard time with this scenario, in particular large(ish) projects.

Conclusion

Although building “the wrong” solution is frustrating at times, I haven’t become jaded. At least, not yet. But I did learn (the hard way…) that it pays to put in my effort at the start of projects. Requirements gathering is too difficult and too risky to assume you’ll get it right the first time around. At least you do not want to bank on getting requirements right every time. This has led some people to adopt agile practices (which I favor), but in any methodology you need to acknowledge the odds of getting requirements wrong.

Good requirements gathering is a preventive action to avoid development scrap and rework. Robust software development processes are contingent action you need to put in place, to minimize the cost in the event your recording of requirements wasn’t quite perfect. That doesn’t always mean “wrong”, more often you didn’t quite deliver the value you might have created from resources at your proposal. And that’s a responsibility each and every one of us has.

Download full article