Assumptions in Analysis

Being an analyst is not an easy job! As thrilling as it may sound, working with unknowns is a nightmare. As one begins to work towards identifying the unknowns, an important challenge comes to the fore – How do we manage the unknowns that remain so even after dedicated efforts? Should we give up? Having loose ends impact the overall solution that shall be developed. And eventually impact the business objectives or even worse leading to failure of the business objectives!
Assumption – Defn: a thing that is accepted as true or as certain to happen, without proof.

Assumptions are as important as architecture, design, solution, model etc. Identifying assumptions is not rocket science and is not a cakewalk either. Discussing the solution with engineers, or design with architects, or while interviewing users – are some entry points that help capture statements or boundary conditions that have the potential to turn into actual assumptions.

While in the nascent stage of solution or requirements definition, assumptions provide a wonderful placeholder to document and manage the unknowns. As numbers of users grow and product/software evolves requests to modify the solution increase as well. Most of these requests, if not all, would require a change in the assumptions that were initially documented. It is extremely important to keep review the assumptions periodically and keep those up-to-date. Take, for example, an assumption that smart phone users may not have the blue-tooth switched on all the time, thereby indicating an extended battery life. With the arrival of smart watches, which must be paired using blue-tooth with a smart phone for optimum benefits, the assumption on blue-tooth usage must be taken out of the solution!

Applying reverse engineering principles, assumptions could actually be used to identify ways to improve and evolve solutions/software thereby improving business value. Personally I have immensely benefited from this activity and have come up with innovative thoughts to improve solution or identify gaps in the solution.

I prefer to manage assumptions by using a simple structure, defined below:

• Actively managed – These are the assumptions that carry a high risk and could change very quickly
  • High Impact
  • Medium/Low Impact
• Others – Though these do not pose high risk to impact the solution. However these provide a way to capture the boundary conditions for the product/software.

Example:
Google Glass – Take a moment….What, in your opinion, are the top assumptions in the Google Glass project? In my opinion those would be,

1. Wi-Fi connectivity is available
2. People not having a perfect (say 20/20 or 6/6) vision cannot obtain optimal use out of it
3. Applications built for this product shall differentiate between a proper eye-gesture and natural blinking!
4. The glass device shall not obstruct natural viewing.

Simple analysis of these assumptions

1. Assumption 1 has tremendous impact on the software that shall be built for Google Glass device. Unlike tablets or smart phones, Glass is a device that requires real-time data (restaurant reviews, monument details etc) for best usage.
2. Assumption 2 captures a basic usability requirement that is just not a part of the current version of the product (let me know if it is!).
3. Assumption 3 addresses a very important characteristic of the applications built to cater to the Glass device. If we cannot differentiate between the natural blinking of eyes and a specific gesture, the results of using the device could range from being bad to disastrous.
4. Assumption 4 captures a basic usability requirement!
   

Please share your views on how identifying assumptions helped in analysis of a problem.

Don’t forget to leave your comments below.