I Am Not David Blaine

Written by Elizabeth McKellar on November 3, 2014. Posted in Articles.

“Hello. I am not David Blaine. Nor am I Penn and Teller or Miss Cleo. I am a Business Analyst, and I am here to ask questions and get to better understanding of your business and needs. I am not here to read your minds or predict your requirement changes 72 months from now.”

Do you ever feel the need to start conversations off like this with your business partners? I feel that way all the time. And I certainly do not think I am alone in that feeling.

Like anyone else, business partners tend to be completely caught-up in their own world. They know their business like, well, the back of their hand. Skipping steps, information or needs that should be a factor in future design or program functionality happens and it is not done on purpose by any means. This is just a side effect of knowing an area so well and forgetting that outsiders do not have the same tribal knowledge. Remember, often times, Business Analysts are brought in to work on a singular project and business owners often have multiple projects going on at once. What might be majority of a Business Analyst work may be a tiny part of the business partner’s day. This is true of any industry and any methodology. Being Agile or Waterfall or Kanban is not a free pass on experiencing these pains.

Is there a way to avoid this situation? The short and true answer is NO; requirements will be missed and you will not find out every possible detail of their job that you should probably be aware of. Unless you are in fact a magician with telepathic powers. If that is the case, then please set-up a conference and teach us all your skills! So how can Business Analyst work to combat this inevitable situation? Among the many different tips or tricks, below are the three most common.

Job Shadowing

One way to overcome this is to job shadow your business partners. Not just speaking with the SME (Subject Matter Expert). Sit down with the actual business end user of the software or program. Who uses the application every day? Who would notice a change the most? Sitting down with the SME’s is critical and should never, ever be overlooked. But often times, our conversations tend to stop with the SME’s and leadership. Take a few hours at the beginning of the project and get into the weeds and get the perspective and opinions of the end users. I ask to be trained like a new person joining the team that you want doing the job on their own in the next 48 hours. Ask ‘why’ and ‘how come’ often and keep strategy and future state in-mind. Ask them thought provoking questions that they might not have ever thought about. Go back to them throughout the project and get their opinions. Show them mock-ups and story boards. An awesome side effect of doing this is you can end up with a person or a team that will be more than willing to help QA work later. And – BONUS – you get some nitty-gritty information that SME’s and leadership might have overlooked.

Write it Down

Sometimes, business partners need help remembering what they said was a ‘must have.’ This can be especially true if you use the Waterfall methodology. They may remember a conversation having Outcome A when you remember it having Outcome B. How can this be avoided? Take. Good. Notes. Do not rely solely on your memory or the memory of those around you. Write it all down. Things to consider in your notes:

The meeting or discussion date
The attendees and contributors
The topic at hand
Key pieces of information and decisions made
Who is following-up on what and when are the follow-up’s due back to the group

This does not mean you have to write down everything that was said. Remember, you need to be listening and participating more than writing. After you have cleaned-up your notes a bit, email them to the group. That way they can help correct any confusion and they have a record of the discussion and decision too. This will be a win in your corner when business changes their mind or contradict themselves down the road when discussing requirements and acceptance criteria. In a way, having all the information written out, shared with the group and saved allows you to be a pseudo Miss Cleo. I mean, you are predicting that they will forget what they said six weeks ago.

Ask..and Ask Again

More often than not, we are put on a project that covers a business area we are not familiar with. This is especially true if you are a consultant going into a new client every six to nine months. The great thing about this model of work is that you learn a lot about many different areas. Your breath of skill gets wider and that can lead to more opportunity for long term growth in your career. At the same time, it can leave you feeling a bit frustrated. It is important to keep in mind that you are learning another group’s work (or multiple groups work) and having to understand a job they have taken years to master. Always ask the questions until you truly understand. Never assume something works one way or is there for a certain reason. Do not be afraid to admit to your business partners ‘I do not understand. Can you please explain it to me again?’ They will be willing and, if they seem irritated, just reassure them that the better you understand this in the beginning, the better their technical solution will be. You cannot write requirements, acceptance criteria, project charters or anything else unless you have a firm understanding of the business and their needs.

You are not a mind reader that can zap information out of your business partner’s head. You can, however, anticipate certain behaviors. You can anticipate business SME’s and leadership having a ton on their plate and juggling multiple projects. You can anticipate they will not think of everything that needs to go into a project’s requirements and that they will change their minds on requirements, especially if the project is over an extended period of time. Last but not least, you can anticipate you not understanding everything in the business. Do not go out and by a crystal ball. Instead, take the time to implement certain behavior in your own routine that will help you and the project. Talk to more than just the SME; get to know the the end users. Get their opinions and input. This will make them feel more connected to the project and what you are changing. It will also help you find out details that leadership might overlook. Write down your discussions and key information. We cannot expect to keep everything in our brains and expect others to remember conversations in the same way. Be sure to send your notes to the group so that they have the same information you have. And never be afraid to ask the questions to your business as often as you need. The end result will be a better project or product because you have more details to work with. No project or product change is flawless; but following these three simple steps and remembering that you are not a mind reader will go a long way.

Don’t forget to leave your comments below.