Tag: Elicitation

The Courage to Ask the Obvious

Written by Adrian Reed on January 10, 2019. Posted in Articles. 2 Comments on The Courage to Ask the Obvious

One thing that Business Analysts are known for is asking questions.

We ask a whole variety of types of questions throughout the business change lifecycle—some help us understand why a particular change is necessary, others help us understand the nature of problematic situations and potential causes, others help us better understand stakeholder needs—and of course there are many more besides. Stated like this it sounds easy. After all, what could be easier than just asking a few questions? That sounds like trivial work, surely?

However, as I suspect most people reading this would attest to, it is anything but trivial and in some contexts it can be very tricky indeed. This can particularly be the case when we are dealing with a group of stakeholders who have a greater depth of knowledge of a particular domain than we do. Of course, as business analysts, it’s important that we have or gain sufficient domain knowledge for the particular assignment, but there will always be domain subject matter experts who have in depth knowledge that we don’t. We might have a good understanding of how a financial services company operates, but there will still be many specialists (including actuaries, compliance, legal representatives and many others) who have deep knowledge that we will need to tap into. This can lead to a nerve-wracking situation where we want to ask questions that we fear will seem so obvious to our stakeholders. Particularly if we are faced with a group of senior experts, we might hear our internal voice saying “You can’t ask that! You’ll lose all credibility”.

The Importance of Being Prepared: Research

Credibility is an important consideration, and it is crucial that we do our homework before engaging in these types of situations. If we’re parachuted into a new domain, spending time reading through everything that we can get our hands on can help us to get up to speed. This might involve scanning through existing project document, intranet sites and also broader internet research. Personally, I find it very useful to put together a personal ‘glossary’, highlighting terms that are relevant for the particular project, and also those terms that seem problematic. This is also a great place to capture department-specific acronyms that might cause confusion.

A broad desk-based fact-finding exercise can often help shape the questions that we ask. We start to get a sense of the context, the goals of the projects and the stakeholders. We start to uncover ‘unknown unknowns’ (things that were completely off our radar), and we can better prepare for workshops and interviews.

Having the Courage to Ask

It is far easier to feel confident with this type of adequate preparation. As the old adage goes “to fail to prepare is to prepare to fail”, and it is amazing the effect that quick, targeted preparation can have. In particular, having created a ‘rough and ready’ personal glossary (which may end up forming part of a project glossary), it can be easier to spot when people are using a particular term differently than we expected. This might mean that we have misunderstood the meaning or that different stakeholders have different understandings. This is one example of where asking the obvious can be very beneficial. Take a term like “customer”. I mean it’s obvious what we mean by customer, isn’t it? Or is it…?

In reality this is one term that is often used very loosely in organizations, and there can be inadvertent clashes in communication. Imagine a hotel that hires meeting rooms to a training company. Who is the customer? Is it the person that makes the reservation (the administration team at the training company), the person that is invoiced (the accounts payable team at the training company), the person who runs the training (a freelance trainer) or the people attending the training (independent delegates). Depending on your perspective it could be any—or all—of these. If different stakeholders were using this term it would be important to determine which they meant! This is anything but obvious.

Of course, seemingly ‘obvious’ questions are not limited to clarifying terms and stopping crossed communication. Sometimes asking seemingly simple questions (“Can you tell me who uses that output?”) will uncover that certain tasks can be optimized for efficiency (“Turns out nobody does, let’s not produce it!”). When these types of questions are asked sensitively—with a foundation of domain knowledge and research—it can help increase our credibility as we add clarity to the situation and help co-create improvement.

So, whilst some of us might find it nerve-wracking to ‘ask the obvious’, it is absolutely crucial that we do so. We might just prevent a major miscommunication and help facilitate a much better collective understanding of the situation!

Feedback is a Gift! Accepting and Utilizing Feedback

Written by Jamie Champagne on January 9, 2019. Posted in Articles.

How often do you thank someone for the incredible feedback you have just received?

Whether it is about your work product, your ability to conduct a meeting or the way you look? Can you remember the last time you said “thank you” to feedback? Whether the feedback feels positive or negative, be thankful that a stakeholder took the time to give you feedback. While business analysts and project managers are often facilitators, helping others achieve their goals, we work with people who often have “day jobs.” They are having to help our current project or change initiative in addition to doing their regular work. They took the time to read what you had created and gave you feedback. That is a gift!

So why does it feel so hard to receive this feedback when it is negative? It is because you took the feedback towards yourself, not your work product. Yes, you spent 6 hours producing a requirements traceability matrix that you validated with numerous SMEs to ensure all elements were captured. Yes, the presentation was very clear and concise with aesthetically pleasing visuals. But your job as the BA or the PM is to help the team deliver their solution. This is part of getting behind the best idea regardless who came up with them. You do not own the end solution – your stakeholders do. The first step with feedback is letting go of personalizing the feedback.

Once you have let go of your own ego, you can take a moment and be proud that you were able to elicit feedback. Knowing if you are going down the right direction or the wrong direction is better than having no direction. Put on your analysis hat and look at what kind of feedback you received. Was the feedback about the presentation style? Your content could have been correct but came across unclear due to presentation style. Or was the feedback about specific requirements? You might have not discussed the requirements with a particularly knowledgeable SME who knew additional details to include. Be specific on your analysis to clearly articulate what the feedback is focused on.

Then work WITH the stakeholder to make it ‘right.’ Ask the person giving feedback what they would do to make it correct. A different presentation format? Additional requirements? Modify the acceptance criteria? And then literally make the updates right then and there WITH the stakeholder. They get to see you take the gift they have just handed you and apply it. Make the stakeholder part of the solution, not the problem.

This is a great consideration when you are trying to facilitate feedback. Rather than walking into a meeting with chest puffed out excited about how awesome your business requirements document (BRD) is, go in with an attitude of what’s missing. Business analysts practice asking good questions all the time. They often know there are risks with leading questions when you are talking to a stakeholder. If you lead them into an answer, then you will get that answer. You want a different answer, then you need to ask a wider question. If you are wanting feedback on your BRD, do not walk in telling people how awesome it is. In some cultures, they will simply smile and nod at you, giving you the impression you are right. Only the stakeholders are too scared to say anything and will discuss all the ‘wrongs’ only after you leave the room. Walking in with a more open attitude geared towards developing the great solution with those in attendance gives more space for the feedback needed for a successful solution. Do not forget why you need the feedback. The feedback is not about how well you’ve completed the task. Feedback is meant to help your stakeholders define, deliver and leverage a successful solution. That is your ultimate measure of success.

So treat your feedback like any gift you may receive this holiday season – always be thankful that someone has thought of you. Later you can decide whether to keep it, return it, exchange it, get rid of it or re-gift it for someone else but remember feedback always starts with a gift.

How To Get Requirements From Resistant SMEs Part 2

Written by Deena Chadwick on January 8, 2019. Posted in Articles. 4 Comments on How To Get Requirements From Resistant SMEs Part 2

Eliciting Requirements Like a Mother of a Teenager.

They call it gathering or eliciting requirements for a reason–it takes effort!

Have you ever, as a parent or concerned adult, tried to have a conversation with a teenager? They slouch down, fidget in their chairs, staring blankly, grunt responses, get enraged, or even storm away. Teens are notoriously uncommunicative, especially with their parents. It takes both art and science to successfully communicate with a teenager. Lucky parents have cracked the code.

Mother of a Teenager

I have seen this analogy fit so many BA | SME relationships. Even though the BA is just trying to do what is best for the business, the subject matter expert is annoyed, doesn’t want to take the time, and feels like the BA is either wasting their time or poking into their business. Some SMEs are eager to give info and answer while others clam up. When you find yourself with the latter, you need to approach them using the same techniques parents have been using to get their clamshell teens to open up.

Learn how to ask probing questions

Probing questions can be used to get information from SMEs who struggle with or are reluctant to give in-depth answers. These should be a series of questions; each question should be designed to get closer to the heart of the matter. Do not lose their interest or let them get bored. If they feel like you are wasting their time, they will shut down. You will then have to stop and start over again at another time.

Sample Probing Questions:

I already know A & B, can you tell me about C
I know a little about _____, can you tell me more
What would have to change if…
How did you decide/determine/conclude…?
If you were ____, how would do _______ differently?

Use Tough Love

There are times when you have to define requirements by interviewing someone who either doesn’t believe in or disagrees with the idea or plan. This is where you have to apply a little tough love. Make sure they know this project is going to happen whether they like it or not. If they could have stopped it, then you would not be tasked with gathering the requirements.

Set the tone – Let them know you are doing this for them
Set the goal and expectations – Explain the information you need and how you expect them to help you
Explain consequences – What happens if they don’t participate
Follow through – Be willing to follow through if they don’t participate

Have their best interest at heart

There are times that a SME clams up and you don’t understand why. You know they do believe in the project, they can make the time, and they do know how to articulate the information you need. You might want to consider that they may have clammed up because they have trust issues with you or your role. Maybe there is a history of broken promises.

You know you have their best interest at heart, but do they know it? Before you begin or continue questioning, you need to do some relationship and trust building. Whether it is your or your role, to get them to open up, you will need to convince them that you are trustworthy, that you will do what it takes.

If their concerns go beyond simple relationship issues, then you will need to convince them that it is in their best interest. Experts at persuading people, say that people respond better when you can identify and overcome their concerns or issues. Here are some techniques that have been successful:

Show WIIFM (What’s In It For Me…them)
Show POE (Proof of [your] Expertise)
Show that you are invested by being prepared
Show that you are willing to do what it takes through support and by following through

Much of what you do and say needs to be aimed at maintaining a healthy relationship. BA | SME communication and collaboration will set the tone for the entire project or product team.

Remember that a SMEs approval and support are critical to the success of your project or product.

How To Get Requirements From Resistant SMEs Part 1

Written by Deena Chadwick on December 12, 2018. Posted in Articles.

Eliciting Requirements Like a Curious 2-Year-Old.

Curiosity is not a sin it is a virtue it is a talent.

If you have it, you should continue to hone it. If not, you need to train yourself to be curious. Being curious is what makes us great, finding the right answer–not the easy answer! Curious people uncover truths that others are afraid to face. Here are some techniques that will help you be curious when eliciting requirements.

Let your inner child (2-year-old) come out and play

Unlike babies, two-year-olds are strong enough for them to muscle their way into rooms and cabinets and bookcases, but their judgment and self-control are still immature. This leads to them being notoriously curious. They have no filter because they have no idea that asking the same question over and over again could bother you or make them look dumb. They just want answers, and they are willing to do almost anything to get them!

5 Whys (Follow Up Questions with Other Questions)

I have often wondered if Sakichi Toyoda, the person who developed the 5 Whys technique, was a father of a two-year-old. Kids have been asking this question over and over throughout history.

Asking 5 times seems to give you as complete an answer as possible. It encourages others to provide thoughtful and complete answers. The information you are genuinely seeking seems to rise to the surface. You get more reasons than excuses, more causes than effects, and of course better answers.

You will also find that it also surfaces questions and information that didn’t occur to you initially.

Confirm Requirements by Asking the Same Question Different Ways

What do 2-Year-olds, teachers, and surveys all have in common? They ask the same questions in different ways. It isn’t to trip you up or confuse you. It is the opposite. To make sure your answer is complete or to gauge your confidence in the answer you are giving.

It is also well known that people often answer differently when either asked in a different way or allowed to answer differently (True or False vs. Multiple choice).

Walking In With Little Or No Assumptions

Two-year-olds are often working with little or no background. That is why they are never satisfied with a one-word answer. When they ask ‘what is that?’ A one-word answer will probably not solve their curiosity. After all their question is really: ‘What is that thing called?’, ‘Why is it there?’, ‘What is it used for?’, and probably ‘Can I have it?’ The reason they keep asking the same question, is because you answered as if they only asked what is that thing called?

If you walk in with assumptions, you might miss asking an important question or skew the answers in the wrong direction. Assumptions are from intelligent thinking, but they are not facts.

No Assumptions = No Surprises = No Regrets!

A Business Analyst’s CRM Labrynth

Written by Tom Lyttleton on December 6, 2018. Posted in Articles. 1 Comment on A Business Analyst’s CRM Labrynth

C-Suite executive level information systems, report, and dashboard requirements are evolving rapidly with IoT and digitization.

I am often asked to provide business process analysis for corporate CRM solutions. Many times, these requests are to review stalled or a “problem” information system project. I provide these on a one time, annual, semi-annual or quarterly time frame.

Firstly, the review process is best performed by someone not connected to the internal team or any software or vendor of the company. It is well worth the effort and cost to bring a 3rd party consultant into facilitate the elicitations and provide any recommendations. This seems obvious, but many organizations try to save money by performing system reviews internally. Most Subject Matter Experts and team members respond very differently when chatting with supervisor’s vs an outside consultant.
I use an approach that starts with business process analysis integrated with Gemba (the actual place) mapping. Then following the actual process flows from initiation to completion. The process of observing and documenting the actual workflow is very enlightening. I will walk you through it.

You began by sitting face to face with C-suite executives to determine the basics. The basics would include their view of the background of any internal Team’s SME’s (Subject Matter Experts).

If there is an internal team supporting the system, such as an Administrator or Architect, meet with them to determine their approach to providing functionality for the users. Does the Architect primarily have a buy, or build approach? Is there an internal roadmap with documentation of any major customizations or configurations? How do they communicate with end users?

With this high-level view in hand, one would start working with each operational role in the company. I like starting with the persons or processes that answers the phone. Observe and document what happens. (I use MS Visio to provide a living document.) Take note if the CRM system does integrate with caller id to display the caller’s information or into a CRM record, if already in the database?

An inbound call is a request for personal assistance. It may be for an appointment, a complaint, a lead wanting more information etc. Follow all these requests through the organization’s processes, observing and documenting as many steps as reasonable to determine efficiency and potential areas of concern. Does the user’s primary interface, or software home screen, allow them to perform all tasks for their area of responsibility? If not, what functionality is not being provided within the system?

You may observe CRM users entering data in other, disconnected tools, such as an excel spreadsheet or cloud application. Make sure to document these occurrences. Also, document suggestions from the users, defining how a system or process, could be made more efficient, from their perspective. User feedback is critical to any improvement. The best workflows are ones that follow the “Toyota Way”. They are continuously improving and monitoring, to eliminate waste, including waiting time, over processing, motion and of, course errors or defects. The process should be easy to use, intuitive and provide guidance through help screens and notes.

After gathering information from each role in the company, 3 categories of fixes may come to light. User interface issues, missing functionality, and user training.

A work screen for a user/role should be intuitive in that the work tasks should be easily performed and guided by the system. As an example, a role that inputs a new lead should be able to process the information required in an efficient manner and if necessary, with prompts from the system. The input screen should be limited to those fields that are required to move the newly inputted lead to the next step. In most cases, the required are name, email, phone, the lead’s reason for calling code, product type, service, more info etc.

Missing internal functionality is exhibited by using external tools. This is an area for risk analysis on a number of levels. Error, data corruption, and/or duplications are possible issues that may occur as there may be limited cross checking between external tools and an internal to the CRM system, record.

User training and disconnections from the system architect(s) is one of the potential issues with remote development or configuration, the disconnect between what the architect thought was intended and what the user really needed. As an example, a user was not aware that picklist fields were available to select attributes for a new lead. The fields were not placed in a highly visible area nor were they made required fields. Consequently, the user(s) elected to place this information in a text field. This created records that are not as useable or referenceable for other roles or workflow rules. Any system error checking or field validation is lost. This exemplifies two failures, one to train, (Documentation?) the other not providing a simple, easy to use, data entry screen.

We learn a great deal from these sessions. After accumulating all the information found and documenting the current state, we document from the team, all possible improvements. With using the same tools, the potential process improvements are documented, and GAP analysis performed.

The current state model may expose some decisions that were made when other options weren’t available. Perhaps decisions were made as functionality development, vs configuring an existing tool, were done unintendedly without understanding the risks. The model may also expose poorly executed or incomplete modifications and implementations.

With the gap analysis complete, the Business Analyst can provide further clarity by evaluating potential improvements for effort vs gain to the organization. Many times, they will find that an easy, fast, configuration wins in this area. In turn, this will improve team and user’s morale. I like to prioritize those.

Present 3 possible solution and/or improvement paths for the stakeholders to debate where there isn’t a clear single path. It is critical that the stakeholders determine which path to take. Change management will be monumental without user buy in, ahead of any proposed changes. The fact that the users have been involved from the discovery process on, helps immensely.

The Independent Business Analyst must remain unattached to the decision, assuming as much of the risk or reward as possible to be exposed to the decision makers. Document the decisions and deliver the report.