Building On Sand

Great User Requirements Rule # 1: Write it down

Writing down the requirements is the first step toward alignment. The act of writing requirements forces us to boil it down to the essentials and provides a mechanism to play it back to the system owner.

I enjoy building sand castles with my kids at the beach. Normally we start by digging a moat. The sand from the moat provides good material for the structure and as well as the walls. Although we have fun building the castle, inevitably the venture is doomed. During the construction a foot may be inaccurately placed, causing part of the ground to shift resulting in damage. This forces us to stop and improvise as we spend time on the repair. The tide is another factor that can cause us to deviate from our initial plans. The water coming close to the castle moat causes the sand to shift resulting in even more damage to be repaired.

The kids and I have fun with the process of constructing the castle. Fortunately, we are not accountable for delivering a final product. With the constant shifting of sand and changing conditions we can never say the project is fully complete nor does it look like we initially imagined. We could overcome these problems with a good set of blueprints at the beginning and driving piles deep into the sand on which we would build a stable foundation. But we are on vacation, so that is not going to happen.

While skipping the detail planning for a sand castle is okay, doing so for a computer system is a setup for failure. Unlike the sand castle, there are expectations that a computer system is delivered that meets a certain business need, is completed on-time, and is within budget. Delivering these things requires that a picture of the end product be first established, which is done through a user requirements document. The requirements document will serve as the blueprint and ensure the foundation piles are in place.

Much like the sand at the beach things shift and change in the business world. Often needs change during the course of a systems implementation. Having an established requirements document enables the team to recognize the significance of changes and communicate the impact. Design documents can be easily modified to accommodate changing business needs.

Failure to have approved requirements leaves things open to interpretation. A discussion with users causes both parties in the conversation to make their own little assumptions as they fill in the unspoken detail. A well written requirements document will fill in the gaps with statements that stand on their own, thus eliminating gaps caused by differing assumptions. Having the document in writing allows all parties to sign indicating the system, as designed, will satisfy the business needs.

Without an initial design someone will insist the shifted sand has always been that way; the team simply misunderstood the needs as they were initially discussed. Overcome this by having a clear blueprint that maps the path to success.