“Why?” versus “Why Not?”

I am a huge supporter of social network sites and I tend to browse Facebook, LinkedIn and Twitter daily. Okay, I will admit multiple times daily. One day I found that my husband posted an interesting status on Facebook and it made me think of how these two simple questions can produce different results based on the situations. My husband’s quote is as follows: "We can ask the question "Why?" or think of how to make it happen and say "Why not?"

Now, if you take this status and think of everyday life as far as career or dreams you want to accomplish you can interpret this as overcoming obstacles by asking "Why not" and the motivation to make things happen. Where asking the question "Why" could potentially make you second guess your dream or goal all together. My husband is a HUGE dreamer and I appreciate and love that about him because he sets his mind on a goal and figures out a way to achieve it, but when I started to think about this question from a business analyst perspective, I would prefer to ask “Why?” and not the "Why Not?"

How many times as a business analyst have you made things happen due to deadlines set for you or expectations set where you didn't have control. So what did you do? You made it happen and because you made it happen it becameprecedence that if you can do it once you can do it again and again and again. It's when we ask that question, "Why" that you truly get the answers to the end goal.

It’s important that when we, as business analysts, go into requirement sessions that we truly understand the following:

1. The purpose of the project. "Why are we doing this?" It's amazing how many times I have been assigned a project but no one really understands WHY we are doing the project. Someone just had a great idea and for some reason someone believed it should have been a project. In actuality it shouldn’t have been a project to begin with because all there is, is an idea, not a vision or organizational strategic reason to do the project.

2. The stakeholders: "Why are you here and what stake do you have in this project?" – It’s very important to ensure you understand all the players, the roles of the players and the responsibilities of those players. If there are people there to just be there, then you need to find out, WHY they are there. What do they want to get out this project? If they don’t know and you don’t know then there is a problem. More investigation is needed. The stakeholders should have a stake in the project.

3. Requirements Management Plan –"Why are you taking this approach?" – It’s very important to have a plan on how you will gather requirements and the plan should make sense for that project. Some things to consider is what type of methodology you will use, what type of documentation will be completed and how the resources time will be spent for requirements elicitation to name a few. If you don’t know why you are taking the approach then maybe you should reevaluate it.

4. Documentation – "Why are we using this documentation?" – There have been many conversations in the industry lately about templates. "What template should I use?" is a question I hear quite often. It's not about the template but more about what adds value to convey the message to the audiences which will consume the information. If the template or artifact does not add value then you need to ask "Why are you using it?" Our job as business analysts is not to fill out templates but to create documentation that will add value to the project.

5. Solution – "Why are we selecting this solution?" – No one understands the requirements better than the person who wrote them. As business analysts we spend a lot of time with our business partners and we have to ensure that we communicate their needs effectively for the developers (providing it is a software development project) to develop the needs of the business. Though the requirement may be met not exactly the way it was communicated because there was a better way to meet the requirement through the design that is being created, as business analyst we have to ensure that the solution is truly meeting the business need and the solution is not driving the requirements. I've been in situations where a solution was picked ahead of time. That led to the solution driving the requirements because no one really took the time to understand the business need prior to selecting a solution. This is another article for another time.

These are by no means all of the "Why?" questions one could potentially ask as a business analyst but it is interesting to see how the same question, depending on the audience, can render a different outcome. For career development or fulfilling your life dreams asking "Why Not?" may be the best question to ask because that gives you the motivation to make it happen as my husband said. However, when you ask that same question when you are doing business analysis it may not be always be the best to say, "Let's Make it Happen" because that may render very different results such as:

1. Setting a precedence on making things happen with unrealistic expectations upfront

2. Not truly understanding the business needs because you truly didn’t dig deep enough during elicitation

3. Not producing the most effective solution you could have

Take the time to ask "Why?" and figure out what the real business need is, it will give you, the business partners you are supporting and your technical partners less heartburn.

Author: Paula Bell, Business Analyst Certified, B2T

Paula Bell is a Business Analyst, mentor and coach known for consistently producing exceptional work, providing guidance to aspiring business analysts (including those that just want to sharpen their skills), as well as providing creative and strategic ways to build relationships for successful projects. With 15 years in project roles to include business analyst, requirements manager, technical writer, project manager, developer, test lead and implementation lead, Paula has experience in a variety of industries including media, courts, carpet manufacturing, banking and mortgage. Paula has had the opportunity to speak on a variety of topics to include business analysis, project management, relationship building, diversity and software methodology.
Website: www.paulaabell.com
Email: [email protected]
Blog: The Journal of a BA and Much More