Taking the Lead

A good business analyst takes the lead on the project.  Sure, there may be a “project manager” involved but the business analyst is the true driver for the project.  It’s the business analyst who needs to setup the meetings, create the agendas, ask the questions, writes the requirements, tests the program, and signs off on the program.

I’m sure you are saying to yourself “hold on…there are other groups that do this.”  You’re right, there are but the business analyst has the final ok.   The business analyst has to have the will to take control in all of these areas.  For example, the QA team may do the end to end testing but the business analyst MUST do the additional testing because he/she represents the business.  One of the key duties of the business analyst is to think like the client.  Therefore, he/she needs to test like the user.  The QA team can do the specific testing, but the BA gives the final ok.

The other key component that the BA must take the lead is in the meetings.  It’s very easy for a meeting to get out control or lose it’s focus.  That’s where the BA must stay in control.  You do that by having a detailed agenda.  When I create an agenda, I actually create two….one for me, the other for everyone else.  My agenda has bullet points and is detailed out with all of my notes and questions.  Everyone else gets a base agenda with just the headings from my agenda.  I use my agenda to keep the meeting on task and direct the meeting to get the answers I need.


Asking questions and active listening

In previous blogs, I’ve written about asking questions and requirements gathering.  I want to talk a little bit more about it because it is such an important tool for a business analyst.

I’ve already mentioned how my favorite questions start with Who, What, Where, When, How, and Why.  But why do I like those questions.  I like them because they are open ended and probing questions.  You can’t answer those questions with a Yes or No and they lead you to other questions.

For example, lets look at some questions I would ask a client who needs a logon page for a new program.

  • Who will be using the program?
  • What different types of security profiles will be needed?  User? Manager? Support?
  • How would each of the security profiles be different?
    • Why?
  • When would the security profiles overlap?  
    • Can a Manager override a user?
    • Why?
    • Can a manager sign on have multiple profiles?
      • Why?
  • Where would the user select the profile they are using?

Notice how I use the open ended questions to move to a closed end question?  There are times you need to get to a definite yes or no answer.

A good business analyst knows to continue to ask more and more questions to get a solid answer.

Another great tool is actively listen.  That simply means that you want to engage with the client to clarify what you are hearing.  Sometimes the client doesn’t know exactly they want or they just know just enough to be dangerous.  By engaging with the client you can make sure that everyone is on the same page.  I usually look at the client and say “So you want…” or “What I hear you saying is…”  The shows the client that you are engaged and are trying to understand their needs.  Hint:  Using a whiteboard to draw out the process flow or design the application is a complement to this process.  

I will talk more about this in upcoming blogs.   In the meantime, remember the only way to learn is to ask questions.

Preparation is key

Preparation is a key asset for a business analyst.  It doesn’t matter if you are running the meeting or just participating, if you aren’t prepared you run the risk of looking like a fool.  So do you prepare?

  • Read:  You read the project documentation.
  • Make Notes:  Normally, I am making notes, or at least highlighting, different items that stand out during my first read.  I highlight things like the goals of the projects, any processes that are mentioned, and anything else that stands out.  I then write down what my initial thoughts.  (Your first impressions are very important, so it’s important to have those written down so you don’t forget them.)
  • Communicate with others and listen to their comments:  Remember communication is not one way, it goes in multiple directions.  I can’t tell you how many times I’ve read a project charter or a requirements document and thought “this doesn’t make sense”.  That isn’t necessarily because the documentation was written poorly.  If you are having a rough day or are stressed or are new to a project then you may read things differently than they were intended.  By asking someone else for their perspective, you may clarify any confusion that you may have.   Additionally, they may have the same questions or concerns that you have.  If they do, then it will help you build the confidence to bring it up in a meeting.  If they don’t, then they can explain things to you on a one on one basis.
  • Re-read the documentation:  This may seem like a waste of time, but, trust me, it isn’t.  After reading, talking to others, and looking at your notes, you can look at the documentation from a new, usually quite different, perspective.
  • Create your agenda/organize your notes:  If you are running the meeting, you need to get ready for your meeting.  That means creating an agenda so you can keep the meeting on point.
    If possible, you should get the agenda out to the attendees 24 hours before the meeting.  I don’t like to get it out any earlier because it can get lost in emails.  If you get it out less than that, then the attendees may not have time to review it.
    If you don’t have to run the meeting, then try to organize all of your thoughts and questions in a cohesive order.  Hopefully, the person running the meeting has sent you the agenda, so you can put your notes together to coincide with the meeting.

    Valuable trick:  Create two agendas.  One for you and one for the group.   Give the group a high level agenda and use the other agenda to bullet your thoughts, points you want to get across, and questions.

Use Cases and Testing Scenarios

Today I want to talk about use cases and testing scenarios.  As a business analyst, it is important to identify, explain, and gather realistic testing data for all scenarios.  While the Quality Assurance team is responsible for the majority of the testing, it is the responsibility of the business analyst to ensure that the testing team has accurate data and knows how to test the information accurately.

Let’s look at a trading scenario as an example.  Most people understand the concept that if you buy 20 shares at $5 per share with a $7 commission, the total is $107.  But there are many different types of trades that occur on a daily basis like short sales.  A short sale is calculated differently and can be very confusing for those who don’t work with it on a regular basis. The business analyst must ask the users for specific examples and step by step instructions as to how to specifically test those items so he and the QA team can test accurately.   That includes gathering the formulas and accurate examples.

What do I mean by accurate examples?  Simple, in the trading scenario, I want to know if the numbers I am using are accurate.  I have never run into a situation where the business didn’t want to teach or give me specific information that I needed.  Simply because by asking for this specific information they understand that I am trying to make the best product possible.

I think it is important to point out here, that when the more complex the calculation or scenario, the more important it is for the business to be directly involved.  For example, in the financial industry, there are many different specialties and certifications, people in these fields have been trained and had specific classes to know the intricacies of their field.  It is NOT the responsibility of the business analyst or quality assurance team to know all of these intricacies.  It IS the responsibility of the business analyst to learn and ask questions so testing can be done as completely as possible.  I like to think that the business analyst and quality assurance team can or should be able to completely test 90% of the items but the business needs to be responsible for the remainder.  That is why you have user acceptance testing.


Coaching…it’s not all about the negative

Coaching has come to be a term people use when someone has done something wrong.  There are times that is In sports, it’s second nature to say “great shot” or “great defense”.  But too much negative coaching can lead to quicksand.  You need to find positives to offset the negatives, otherwise the employee will think that you just focus on the bad.

Just like in sports, people in business start pressing and start worrying about doing something wrong.  Just as in sports, pressing leads to mistakes.  As I’ve already mentioned, there are times when negative coaching is necessary.  In business, you depend to do their job and be professional and when they don’t you have those “coachable moments.”  We are all results oriented and want (or expect) others to do the same but there is a right way and a wrong way to do it.

However, I believe a good manager coaches on the good things as well.  For example, this weekend, Kyle Schwarber hit a go ahead grand slam for the Cubs.  After the game, Joe Maddon mentioned that he was just as excited that Kyle went to left center field.  That’s because Kyle has been in a major hitting slump and he’s been working on going with the pitch.  The home run went into left center with the pitch.  In the press conference, Joe was using positive coaching to emphasize all of the positives around Kyle’s home run, not just the 4 runs.

Positive coaching isn’t hard in sports, it’s second nature to say “great shot” or “great defense”.   But I don’t think it’s intuitive for business managers to do that.  Even managers who have played sports, don’t intuitively transfer that experience into business…or worse they had a coach that only emphasized the negative.  All it really takes is a simple IM or email saying “good job” or a quick phone call saying “you did a good job with that”.

I look at coaching like going to the bank; positive coaching are your deposits and negative coaching are your withdrawals.  The more positive coaching you have done, the more effective the negative coaching that you may need to do will be.

Neal is available for consulting and coaching.  Contact him today to discuss your needs.

Note taking

Today, I want to talk about note taking.   Note taking is a vital tool for the business analyst.  We’ve all been taking notes since we were in school and some of us do it more effectively than others.  For me, the biggest challenge is running a meeting while taking notes at the same time.  Trying to keep the flow of the meeting going while trying to write something down can be tough.  So how do I do it?  I do the following:

  1. Whenever possible I record the meeting.  Most conference call numbers will allow you to do this and they let everyone know that the call is being recorded before they come on the line.  Recording takes the pressure off of trying to get everything right, right then.  I can focus on asking questions on the fly.  I can still take notes and then compare them to what I had.  It also can save your butt when people will say “that’s not what I said” because you can just call it up and play it back.
  2. I ALWAYS have an agenda.  My agenda is always in an outline form and I always have it open on my computer.  I keep it open because, quite frankly, I can type faster than I can write and it’s much easier to read.  Over time, I’ve learned how to use keyboard strokes to do my indents and so forth, so typing is much easier.

    Having the agenda allows me to stay organized and put the notes in the right place.  That way I can help ensure I keep things in the right context and perspective.  It also allows me to note where I need to go in the recording if I need to clarify something and save some time.  It is also important to keep your notes clear and concise.  It’s better to have short simple sentences than long drawn out paragraphs.

  3. When possible I do a screen share.  Most IM applications allow you to share screens.  Typically, I have two computer screens and keep my notes on the screen that is NOT shared.  When I need to, I can always move the notes over to the shared screen so people can see what I’m typing.  This saves time, keeps people involved, and ensures everything is right.
  4. Finally, I ALWAYS send out my notes after the meeting.  I want to do that as soon as reasonably possible because I want people to review it while the meeting is still fresh in their heads.  That way, everyone can agree on what was said and changes can be made easily.  It also gives people a chance to send you a private message if they were confused about something.  People don’t like feeling stupid and sometimes, especially when they aren’t familiar with the group, they want to get some clarification privately.

Hope this helps as you work toward being a great business analyst.


Neal is available for private consultation and coaching sessions.  Please contact me for more information. 

Ditch the Lessons Learned term

How many of you have seen an meeting request with the title “Lessons Learned”?  What goes through your mind?  When I see it, I usually think “Uh Oh, someone is in trouble.”

What I really find ironic about these meetings is that the organizer always starts the meeting with two things:  “This purpose of this meeting is not to point fingers” and “Let’s start by what went well”.  Let’s face it, most of the time the purpose is to point fingers and starting on what went well is a politically correct way to soften the blow.

So what do I think should happen?  Simple, ditch the term Lessons Learned.  Instead, have a Project Debrief, after every project.  Think about this for a minute.  First, every project, even one that was successful, has something that could be improved.  Every project has something that went really well for which someone should be recognized.  By doing a debrief after every project, it becomes the norm and people will not be as defensive as they would if a project had gone wrong.   Second, by calling it a debrief, you taking the sting out of the meeting.  Coupled with doing this after every meeting, the team will start getting something positive out of the meeting.  The term Lessons Learned by itself implies that something went wrong.

Just think about a baseball practice.  The coach yells out, “man on first and second, two outs” and then hits the ball to the right fielder.  The right fielder catches the ball and throws it to second base.  The coach stops the play and has everyone freeze.  He then uses that as a learning tool to help everyone understand where the cutoff should be, who should be the cutoff, where the first and third baseman should be, who should be backing up who.  It’s the same principle with the Project Debrief.  You want to help people grow.  You want to help people learn.  You want to reinforce the positive.  This is especially true, with inexperienced employees.

This is the essence of true coaching.