Skip to main content

Author: Kupe Kupersmith

No One Wants to Work With a Jerk

Kupe_March1The debate rages on about technical skills versus the other skills. You know the one about the hard skills of our profession vs. the soft skills of our profession. Which is more important and why. This never gets old for me. As I thought of this title and topic, I realized I wrote about this once before in my post, Will the Real BA Foundational Skills Please Stand Up. Today’s conversation extends that idea.

In the business environment we are always looking for ways to stand out from the crowd and get that desired promotion or additional responsibility or in some cases stay off the chopping block. How do you do that? Do you fine tune your Use Case writing ability or draw better looking workflow diagrams? Yes, if communicating the requirements improves. No, if your goal is to say I can use more symbols than the next guy. Having experience and knowledge of accepted practices is an entry point for most mid level BA jobs and definitely for senior positions. You have to have these skills, be proficient with them, and you have to stay up to date with new techniques that arise. But you hone these skills enough for parity. You need to be able to meet expectations here, but over achieving is not necessary.

Where you do need to over achieve is in your communication skills, your interaction skills, your leadership skills, mentoring skills, etc. Why, because people do not want to work with jerks. Plain and simple, people want to work with those they like and connect with. Think about who you like to work with? Who do you not like to work with? I bet you the ones you don’t like to work with have some jerk quality to them. Are the smartest most technically qualified people the ones you want to work with all the time? Last week I was speaking with a manager that said if an employee is a jerk they are useless to his team regardless of their technical ability. In our environment we rarely have positions that do not require collaboration and teamwork. If someone is a jerk they kill collaboration and teamwork. Their technical skills usually can not compensate for the overall impact they have on the team. If you follow US football you know Terrell Owens, wide receiver, fits the bill of the jerk with great technical ability. In his prime he was the best receiver out there. But he bounced around teams because he was a detriment to the team. His number of catches and touchdowns was just not enough for teams to keep him around.

The next question that comes to mind for me is the timing of developing your hard and soft skills. In the early stages of your career you need to work on the technical aspects to get to the parity level with your peers. But, don’t just focus on the technical aspect. For every technique you learn you should be learning best ways to elicit the information to use the technique, you should learn how to best communicate the results to different stakeholders. Once you feel you hit parity with the necessary techniques go hard for the softer skills. Work to be viewed as the best communicator, the one everyone comes to for advice, the leader of your team or group.

I want to hear your thoughts. Let’s debate and learn from each other. Just don’t be jerks about it!

To your success,

Kupe

Don’t forget to leave your comments below.

The Business Analysts Role in Transition

Kupe_Feb15Have you ever been on a project where the team is thrilled that the project was completed on time, within budget and all the features were delivered?  Then you roll out the new system to the production environment and the users don’t jump for joy?  Some users resist using the new system and others use it but complain. 

I remember one project where my team rolled out a new enhancement on a weekend and had key users there to do some high-level tests.  The implementation was flawless. The high fiving and hugging that ensued reminded me of a team that just won the World Cup. I think one developer ripped his shirt off and slid down the hall on his knees! On Monday another BA and I went walking around the user community to be available for questions.  There was silence.  The reason was partly due to the users not using the new system and sticking with their Excel spreadsheets.  Why?  They were not comfortable with the new system and still had tight deadlines to meet.  There was no time to get accustomed to the new system right away. It ended up they were never going to have time to feel comfortable with the new system.  What did we miss? We did not give enough attention to the transition needs or transition requirements. 

Much of the focus around requirements is eliciting, analyzing, and communicating the project objectives and product requirements.  These are the requirements to build a solution.  Where many teams spend too little time is with specifying transition requirements.  These are the requirements that address how you make a smooth transition to the production environment once the solution is built. 

There are two major areas that impact transition.  The first is the impact to applications and the second is the impact to the people.  Let’s take a look at these two areas where I see the business analysis professional playing a big role in helping ensure a smooth transition. 

The impact to applications

Within applications there are two components I want to highlight.  The first piece is data updates/conversion.  With the new application or enhancements being rolled out there may be one-time data updates needed.  On a recent CRM project one enhancement was to add fields to the contact record.  I made sure to ask the question if any of the fields needed to be populated when we move it to production.  This is different than having the default value of a field being set for every contact.  In this case we were splitting one field into three fields.  Depending on the value of the original field those three fields had to be populated a specific way.

The second is coordination with other applications that will be impacted.  If the new application you are moving into production integrates with other applications you need to coordinate roll-outs to ensure all applications are in sync. The worst thing that can happen is your team is high fiving while another user community is impacted negatively and can’t use their current system any longer.

The Impact to the people

You have probably heard me say this before. Projects are for people. In the end you don’t implement a project for a company.  It is for people within the company. And every project no matter how small or large is a change.  It impacts people. Deep down inside we really don’t like change even if we ask for it all the time. With almost every implementation current processes that people perform are going to change.  How they do their work every day is impacted by the implementation of the projects you work on.  We have to work with the user community to gauge the impact and design an implementation or transition plan which will result in the least amount of disruption to people. 

I think it is safe to say most of us use MS Word.  If you made the transition to MS Word 2007 you know it took some time to get used to the new user interface (UI).  I like the new UI, but it took me longer to format a document the first few times I used it.  It was actually a little frustrating because I was in a rush. There are still some features I struggle to find.  This feeling is what your user community experiences every time you implement a new application or enhancements.

As the business analyst you get to know the environment and the people.  You need to help design a training plan for the user community, and help the team and business determine how the cutover will take place.  By cutover I mean will you go cold turkey and flip the switch on the new application and the old one is gone.  Or will you run both in parallel for a period of time. Or will a small pilot group use the new application for a period before rolling it out to the community at large. 

The goal is not to build something.  The goal is to build something that the users will use because it improves their work and in turn adds value to the company.  If you focus time on the transition needs, you increase the chances of having the project team and the user community jumping for joy.

All the best,

Kupe

How a Business Analyst Should Prioritize Knowledge Transfer

Kupe_Blog_Feb1My friend and fellow author on BA Times, the Bad Ass BA, just wrote an article, The Bad Ass BA Observes the Hunt for the Right Business Analyst.  In the article she discusses different types of business analysis job requisitions that are currently on all the job boards.  One type that she highlighted got me thinking about an issue which companies deal with every day.  The type of job requisition she touched on was the “clone the 25-year veteran who just retired” job opening. This is where a hiring manager wants to have someone with the exact experience and knowledge of someone that has been working on the same application and with the same customers for years.

Why do some hiring managers need that?  They have relied on that one person to work on that application and with the customer base far too long.  Why do they do that?  A big reason is that the customer gets comfortable with a particular individual and they do not like change. So as long as the person they love does not want to pursue other opportunities they will stay there until they leave the company due to a staff reduction or reach retirement age. 

This particular post will not address the ways a BA manager can help spread the knowledge to avoid this situation.  An earlier blog post, The Sadness of the Silo’d BA, touched on this subject. This post will focus on what the new BA who is replacing the long established BA should focus on to be most effective. Until organizations start pairing BAs, BAs will be in silos and will continue to be the only ones with certain knowledge.  Coming onto a new project team, a Business Analyst needs to obtain as much information from the departing BA as possible. If you are the incoming BA there is so much information you need that it often feels like you are drinking from a fire hose. You have limited time with the outgoing BA, so you have to prioritize the topics you cover. 

Conventional wisdom may lead you to believe the main priority should be the application(s). That in fact should be the lowest priority.  Yes, you need to learn the features of the application and as much about the application as possible, especially if you are also responsible for production support.  But there are other team members that often have knowledge about the application.  QA Analysts and developers have in-depth knowledge of the application, so use them for support until you have had time to get caught up on the application. 

Your top priority should be focusing on the stakeholder(s) who may be most upset about a new BA coming onto the project.  Have the departing BA schedule time with those stakeholders to personally introduce you one-on-one.  It is in your best interest to make these stakeholders feel comfortable. Ask them what you can do to make the transition easiest on them.  The reality is that the departing BA is departing.  The stakeholder may be upset, but if you ask for their input on making the transition smooth you are taking the first step in winning them over. 

Next, get the departing BA to give you a brain dump on how all the stakeholders like to communicate.  Which ones like formal meetings and which ones prefer hallway conversations?  Get a list of those that like formal documentation and those that do not require formality. Understand what communication medium the stakeholders prefer; email, text, phone, face to face, etc.  What stakeholders are usually positive on projects, which ones bring conflict?  Are there stakeholders that don’t get along?  Are there stakeholders that dominate meetings?  I think you get the gist of where I am going.

The BA who is departing understands and subconsciously considers all these factors when interacting with each individual stakeholder.  That’s why they love him/her. Since it has become second nature for the departing BA, it may not be easy for them to think of the answers to your questions. 

The easier thing for the departing BA is to give you a demo of the application.  Fight the urge to allow that to happen unless you have the time – after the analysis of the stakeholder(s) has been completed. 

My one warning on the subject is to validate what you have been told.  We all have biases and the departing BA may bring theirs when answering these questions.  Take into consideration what you have been told – but make your own final judgment as you interact with these individuals.

All the best,

Kupe    

Don’t forget to leave your comments below.

Gain Credibility by Being Prepared

Kupe_Jan_18_BlogI received a tweet from a buddy during the first week of the year saying he had 8 meetings scheduled in one day.  Seeing as though there are approx. 8 hrs in the work day, those meetings consume his entire day. Hopefully the meeting rooms were close because there is no time between meetings to get from one to the other.  Unless he can fly like Superman, he was leaving early for some and getting to others late.  I should have warned him to not drink coffee that day.  No time for breaks.  Having a full day of meetings may be rare, but having multiple meetings in a day and back to back meetings is not.  Some people accept this as part of doing business in today’s work environment.  I say you should avoid it at all costs.  Here’s why…you need to be prepared.

How many of you run into meetings and say “why are we here again?”  Hopefully it is not a meeting you are leading.  As a business analyst a way to gain credibility is being prepared for every meeting you lead or attend.  Many of you know I am a trained Improv actor. My improv troupe was always asked if the dialogue was scripted. Even though we explained there were no scripts for the show, audience members just couldn’t believe it.  They felt the dialogue on stage was just too smooth for their not to be scripts.  How did we do this?  We practiced many hours to be prepared for any situation on stage.  Our performances were 2 hours long and we practiced 6-8 hours every week.  Look at other professions, like professional (US) football.  They practice all week to play for 60 minutes.  So why do we feel it is OK to run into a meeting and ask “why are we here?”  I would have been booed off stage, football players would be out of a job. 

I know this is hard in today’s environment, but do what you can to be ready.  Here is an old tip that I learned. I break it out if I feel the back to back meetings are just wearing me down.  Start your meetings on the half hour or quarter hour.  You will instantly install cushion between meetings.  I would say 99% of people schedule meetings on the hour, 9am, 10am, etc.  By starting yours at 10:15am you’ll have 15 minutes after your 9-10 meeting and potentially 45 minutes before your 12pm meeting(hopefully they are serving lunch).  That gives you time to prepare for your upcoming meetings. 

I have been in too many meetings were half of the meeting is spent waiting for people to arrive, setting up the projector and helping everyone understand why we are there.  The goals of the meeting are not accomplished therefore another meeting is scheduled to finish up.  This behavior just adds more meetings meaning less time to prepare and the cycle continues. 

Make sure you are prepared for every meeting you attend and do what you can to provide the necessary information so others attending your meetings are prepared.  This behavior will be received well and leading by example, one at a time you can change others behaviors. 

Now stop reading this blog post and get ready for your meeting!

Kupe

Don’t forget to leave your comments below.

It’s the Communication Stupid

Kupe_Blog_Jan_4I was reading a book that talked about how the phrase “It’s the economy stupid” was born. This phrase was created and used by the 1992 Bill Clinton presidential campaign when he was running for U.S. President. According to the story, James Carville wrote three things on a white board to help the campaign get focus.  One of the items on this internal list was “The economy, stupid”.  He wanted the campaign to stress how Bill Clinton’s opponent, George H. W. Bush, did a poor job with the economy during his first term in office. This is a very simple and clear direction for the campaign. It helped them make decisions on how to answer questions from reporters and when creating and delivering campaign speeches. This phrase was a big reason Bill Clinton went on to win the election.

I have a phrase for business analysis that will help you focus and help you make decisions during a project. “It’s the Communication Stupid”. I urge all of you to post this sign on your desk. Post it in a place where you see it every day. Maybe move it around so you not only see it, you read it every morning. Keep the sign until the concept is a part of who you are as a Business Analyst. When your actions start to follow the meaning of the sign, it is time to pass the sign to another BA in need.

In my unscientific research, I found a large theme among top analysts is they constantly ask themselves “will this help communicate the business need and/or solution requirements?” That is the backbone on how they plan their work and how they make decision related to their work during a project. You probably have heard people say, “BAs need to do just enough requirements” or something like,” only use a technique if it adds value to the project”. What is just enough and valuable? Communication is the value. If the message is communicated then that is enough requirements. 

I feel I communicated the message I wanted to get across. So, no need to add more words!!!

Happy New Year,

Kupe

Don’t forget to leave your comments below.