Skip to main content

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!

 

Knowledge Area Assumption Questions
Business Analysis Planning and Monitoring I have spoken to all the affected stakeholders
  • Is there someone else who may be affected by this project?
  • Do the selected stakeholders have enough underlying knowledge of the processes?
 Elicitation  I understand the process being modified
  • Have I identified the start and finish of the process?
  • Do I understand the key steps?
  • Have I identified the inputs and outputs to the process?
 Requirements Management and Communication  The requirements are complete because no one mentions that I missed something
  • Have all the stakeholders been communicated with?
  • Have I spoken to the quiet (introverted) stakeholders to get their opinion?
  • Have the stakeholders actually read the requirements document?
 Enterprise Analysis  I know what the project is intended to accomplish
  • What specific problem(s) do you expect this project to solve? – ask Sponsor and key stakeholders
  • How specifically will the project’s benefits be measured? – ask Sponsor and key stakeholders
 Requirements Analysis  I have the process optimized in the requirements document
  • Should the stakeholders needs be met by improvements in the current process?
  • If I recommend changing the process, will other requirements be invalidated?
 Solution Assessment and Validation  I have presented the solution clearly
  • Have stakeholders asked thoughtful questions in my presentation?
  • Have I demonstrated the solution in at least 2 different formats (ex: Excel and PowerPoint)?
   My test scenarios are complete  

  • Have I thought of every scenario?
  • Have I prioritized the likeliest scenarios, so they get executed first?