Beware of Assumptions!

You all know what assume makes out of U and ME. This old adage stays true to this day and is very applicable to the business world.

Assumptions are some of the biggest culprits in scope creep, misunderstandings, and successful projects being declared failures. This article will provide examples of each and ways to take the assumptions out of the picture and make your project a success.

Assumptions in requirements elicitation sometimes happen by accident such as when a user forgot to tell you about a particularly important piece of functionality. They sometimes happen maliciously as in the case of a sponsor trying to squeeze in programming that would never have been approved if presented to senior management up front.

In the first (non-malicious) case, the way to battle assumption related omissions in requirements gathering is through questioning multiple people early in the project. Question the sponsor, their direct reports, and most importantly other stakeholders. For example, a sponsor from the operations department asks for screen changes and a few reports. Make sure to question stakeholders from the marketing and relationship management departments. They may uncover hidden requirements that would surely lead to uncovered requirements gaps upon project implementation. Also, question the sponsor’s direct reports (diplomatically of course). Often, they are aware of steps in the process that their superior is not.

In the case of malicious requirements creep, the sponsor uses the excuse that they made an “assumption” that the piece of functionality they’re requesting is in scope when in fact they know it is not. The way to avert this is by carefully documenting and communicating the scope. This should be done in writing and orally over the course of several meetings leaving no doubt in anyone’s mind.

Ah, misunderstandings. That’s just an assumption by another name. My favorite story about misunderstanding is sitting in a key stakeholder’s office describing how an IT solution made up of multiple screen changes will make his life easier. He was happy, of course until he casually mentioned how thrilled he was that we modified the reports to match the screens. Oh,oh -we never talked about reports. It turned out; he was assuming that we knew enough to modify reports as well as screens. Always make the requirements in scope painfully obvious to avoid this situation.

One of the banes of the profession is a project where requirements are carefully crafted and executed, but the project is still declared a failure by the business. Digging deeper, the people declaring the project a failure have most likely made assumptions about the project that have been false. For instance, an operations manager may have assumed that a project will allow for increased headcount for his group, but that has not materialized. A business head may have assumed that a system enhancement will drive additional sales. When additional sales don’t materialize as an outcome, the project may be blamed.

Finally, make an effort to close all assumptions as soon as possible. Do this by asking questions even if some of the questions sound obvious. Keep asking until there are no assumptions left. To make things easier, use the following table as a guide to ferreting out assumptions during requirements elicitation. While by no means exhaustive it should serve as a starting point to generate your own.

Good luck BAs!