Menu
Change Management Week
Everyday this week!
That’s us! We were lucky enough to be selected to speak at this year’s BBC Conference and just HAD to document the moment with, what else, a selfie!
Let’s take a step back though and take a look at how this presentation came together:
A long time ago in a galaxy far, far away there were two Business Analysts that wondered how they could be more than average. They wondered what habits they needed to become highly effective and how they could help others become highly effective. They thought and they planned. They collaborated and communicated across their time zones, cultures and countries. They identified the real problems dividing the highly effective BAs from the others. They identified those most important habits to include and prioritized which would be shared. They created GAFFs to describe not-SMART requirements. They continued to do better today what they did well yesterday and a rock star presentation on 7 Habits of Highly Effective Business Analysts was born.
The 7 habits are what make the difference between an entry-level, junior and mid-level BA to being a highly effective problem solving machine. So why do these habits make a difference? What is it about these habits that accelerate BAs to a highly effective level? Read on to find out!
Benjamin Franklin is attributed for saying that “Failing to Plan, is Planning to Fail” and it is definitely the case in business analysis. In order to be efficient in eliciting requirements, the Business Analyst needs to be prepared and needs to have planned their efforts.
One thing is first, use the phrase “eliciting requirements” rather than “gathering requirements” because the art of elicitation is more involved than simply gathering them. Requirements must be drawn out and exposed, they must be worked and triaged until they’re understood and agreed upon. They are never simply collected; in fact requirements are rarely ever simple.
Planning for requirements elicitation necessitates answering the five fundamental questions: who, what, when, where, why, and how. The first question we need to answer when we’re planning is the why and identify what problem needs to be solved. But, let’s park that question for the moment since defining the problem is our next habit.
Once we’ve determined what the issue is that we’re trying to solve, we need to understand the stakeholders involved. Who has interests in solving the issue, and who will be affected by the solution? Using an IGOE chart can help ensure that you’re covering all of your stakeholder groups, including internal and external stakeholders. This chart focuses planning to cover the breadth of the project.
Click the image above for a larger view.
In the Real World with JaredOnce, I was brought into a project where no planning had been done, the project was hemorrhaging money and no progress was being made. I quickly learned that they hadn’t done any planning and they’d missed some key stakeholders.
I rolled up my sleeves, analyzed the stakeholders and moved on to elicit the requirements. I was told by our PMO that my intervention probably saved the company about $250k. Had they gone live without the interface requirements I unearthed, the system would have missed some key functionality and would not have passed User Acceptance Testing and they’d have had to go back and do it again. Proper planning is critical to project success!
There is an art to planning. Too much and you experience analysis paralysis, but not enough and you’re not prepared. Experience will get you through this as you learn what the right level of planning is for your business analysis tasks. Continually refine your planning efforts until you’re comfortable with your approach and then refine it some more so that you become an expert at it!
Planning is also a great communication tool within your project team. If you don’t plan, you’ll have no ammunition for when the Project Manager slots your requirements elicitation into the schedule. Too many times BAs are tasked with eliciting requirements based around someone else’s schedule. Having a plan at my fingertips gives me a chance to influence the schedule and allows me to succeed. I don’t want to fail to plan, because I have no intention of planning to fail.
Only by defining the real problem can you truly solve it. Focusing on identifying what the real problem is a key to success in analysis. Using a technique to frame the problem creates clarity to finding the right solution. Try breaking the problem statement down into these four parts:
This format for the problem statement makes the problem become clearer.
In the Real World with HeatherI had an experience where I learned this early in my career. I worked in the commercial real estate industry which was very paper intense. There came a time where the file storage cabinets were full and we needed more space. It seemed the problem was that there weren’t enough cabinets and the solution was to order more cabinets despite a lack of physical space in the department.
Using the technique above, the storage space problem statement is:
The problem of lack of space to store physical documents to meet compliance standards
affects the compliance department,
the impact of which is the inability to retrieve physical documents.
A successful solution would be to have enough space to store documents per compliance standards.
Instead of thinking that the problem is shortage of physical storage cabinet space, the question arises; do the documents in the physical space meet current compliance standards? Is it possible that some of the physical documents no longer need to be saved? Perhaps the solution is to audit the documents and make more room. The solution to purchase more cabinets is not solving the right problem; the real problem is storing only the documents for the compliance time frame rather than adding more storage space.
This habit puts the focus on understanding what is wrong to ensure you solve the right problem. Once you have the right problem, you can focus analysis to create SMART requirements to design the right solution.
SMART requirements are fundamental to success. It’s the first thing one learns about requirements, that they must be SMART: Specific, Measurable, Achievable, Realistic and Testable yet so many people don’t actually define their requirements to be SMART.
Sometimes to better understand what something is, we need to understand what it isn’t. If you look at the exact opposite of SMART, you come up with Guessed, Ambiguous, Far Fetched, Fanciful, which results in a snowball’s chance in hell for success. The acronym for non-SMART requirements turns out to be GAFFs, which of course is another word for a mistake. It’s no stretch to understand that a non-SMART requirement is a mistake that allows you a snowball’s chance in hell for success.
In the Real World with JaredThroughout my career as a Business Analyst, I’ve come across so many GAFFs and I’ve found that even Senior Business Analysts still use them. One requirement I came across when I was doing a peer review was “The solution must be either temporary or permanent”. Other examples I’ve seen or heard about through the grapevine was “The system must produce letters” or “The system must be friendly” and even “The system must accept all forms of payment”.
Put yourself in the developer’s shoes for an instant. If the developer needs to question what you’re trying to accomplish or needs further clarification, your requirements probably aren’t SMART.
You may understand what “friendly” or “letters” mean but requirements are a communication tool and if you’re using GAFFs instead of SMART requirements, you’re not communicating effectively enough to ensure success.
The habits of planning, finding the real problem, and defining SMART requirements must all support the habit of delivering value. Value is something useful or important to our business partners. We should do the right things, rather than just doing things right.
As we practice these habits, we gain perspective on the things that are the most valuable to our stakeholders, these are the right things! Understanding the real problem allows us to focus on the value of all the features explored in requirements elicitation. Will an update to a user interface be the most valuable if the problem is data integrity in reporting? If the feature is to update the user interface to ensure accurate data capture then yes, that feature could be the most valuable. If the update is to improve user experience and save time in data entry then no, that feature may not provide the most value for that problem.
The ability to understanding the most valuable features is an important business analysis skill. We do this by listening; listening is key to delivering value. Listen and analyze to find:
Tip: Using the SWOT analysis technique is a simple way to understand what the opportunities are for your stakeholders.
If you’re involved with a project that is not focused on delivering value, as a business analyst, you have a responsibility to challenge why we are pursuing that investment. That challenge is practicing the habit of delivering value. Closely related to delivering value is to the next habit, prioritization.
Your new motto: “I can do anything for my stakeholders, but I can’t do everything.” Because businesses do not have unlimited time, money and resources, the habit of prioritization is essential.
To illustrate, picture a clear jar representing project scope. The jar can be filled with big rocks, pebbles, sand, and water, representing parts of the project:
If I focus on filling the jar with water and then add pebbles and sand there is no room for the big rocks. If I fill the jar with the big rocks first then the pebbles and sand there is room for the water to fill the jar. In our analysis work, we have to focus on the most important things first and do those first.
How do you identify the big rocks? Those are the business priorities. Prioritization exercises such as the MoSCoW technique, which require businesses to identify the Must have, Should have, Could have, and Won’t have items from a list of requirements. Once these are identified, the business analyst knows how to define the big rocks that need to be focused on first. It’s important to remember that the business analyst guides the process to identify the priorities and the business owns the priorities. For additional suggestions on Prioritizing Requirements download our Quick Tip: How to Successfully Prioritize Requirements.
Teams don’t always play nicely together. It isn’t project managers vs business analysts or business analysts vs developers or technical business analysts vs project business analysts. We are a team, not a battle between us/them. If we spend most of our time pointing fingers or playing the blame game, there’s little time left to provide value for our stakeholders. When we withhold information and don’t communicate, we are destructive to our teams. Choosing to keep information secret in an effort to retain power is a mistake. We’re only as sick as our secrets and arguing isn’t a cure.
In the Real World with HeatherI sometimes describe my role as a business analyst as a professional communicator. Communication is not easy, it is a skill that each of us can improve on. Early in my career I was involved in a corporate downsize. As part of that downsize, I needed to train the new person on the tasks for my old position. I was not a highly effective BA and I withheld information thinking that that gave me power over the situation.
I learned that in fact, I had harmed myself with my secrecy. I did not feel good about myself and created a perception that I was difficult and not a collaborator. After this situation, I decided that I would be open and honest in my communication. Honesty is the best policy.
As BAs we are in a perfect position to lead the team in open and collaborative communication. As we share information openly and consistently we make it safe for others to share. When we admit that we don’t have an answer, but will work with the team to find an answer, that vulnerability creates trust. Secrets make for sick teams. Share equally and openly with your team to be highly effective.
The elusive 7th habit relates to continuous improvement, which will help you throughout your career. That’s how you transition from a Junior Business Analyst to Senior. You’re not making the same mistakes, and you’re doing things better than you did in the past. Don’t let that improvement stagnate; make sure that you’re always looking for new methods, new tools and new approaches to become better.
You will continue to make mistakes along your journey; just try not to make the same mistakes and make sure that you learn from them. Hone your skills; keep your toolbox full of new tools, approaches, and tricks. Make sure that you do better tomorrow what you did well today.
We want to hear of your successes. We want to celebrate with you as you improve along your journey. We want to know how following these seven habits has transformed you into a highly effective problem solving machine! Feel free to share your success with us!!
Thank you from two highly effective BAs,
Heather & Jared
Heather Mylan-Mains
Heather is from Des Moines, Iowa. She is a stimulus for change as a mom, a business analyst consultant, a Netmind Senior Instructor and currently VP Chapters IIBA®. For the past 17 + years, she has worked with a variety of teams to identify and solve problems. She has been fortunate to work through all the aspects of business analysis; there is no part of the RACI matrix she has not been responsible for! Heather has a BA in Accounting from Grand View College and an MBA from Drake University and is a CBAP®. Connect with Heather: Twitter | LinkedIn.
Jared Gorai
Jared loves being a Business Analyst and has done so for almost 15 years. He’s passionately employed for a Canadian Oil & Gas company headquartered in Calgary Alberta. He holds his Bachelor of Arts degree in French from the University of Calgary and the Certified Business Analysis Professional™ (CBAP®) designation. He is a Past President of the Calgary IIBA® Chapter and is currently the Deputy VP of Chapters for International Institute of Business Analysis® (IIBA®). He will take any chance possible to evangelize the role of the Business Analyst. Connect with Jared: Twitter | LinkedIn.
© Copyright 2023. Netmind. All rights reserved.
Por favor, proporciona la siguiente información para ayudarnos a personalizar la solución.
Netmind España
Barcelona +34 933 041 720
Madrid +34 914 427 703
Nos puedes encontrar de:
Lunes – Viernes, 9:00-18:00 (GMT+1)
¡Te ayudamos!
info@netmind.net
¿Dudas sobre servicios/formaciones?
comercial@netmind.es
