Author: Kupe Kupersmith

You Need Desire to Be a Desired BA

Written by Kupe Kupersmith on March 2, 2010. Posted in Articles.

There were a few comments on my last blog, Will the Real BA Foundational Skills Please Stand-up, referring to a business analyst’s need to be curious and inquisitive. No one can argue this is a essential trait for a BA. Conventional wisdom says this trait is innate, meaning, you are born with it. I agree 100%. On this subject I hear people say that you are either born with it or you are not, and you can’t teach someone how to be curious and inquisitive. In this I disagree 100%.

Everyone has this trait in them. We are born with curiosity. We learn and grow based on our curiosity. Growing up we ask questions and we explore the unknown to better understand our surroundings. Have you ever met a 4 year old that did not ask “why” until it made sense to them? I have a rule with my kids. If I can’t explain it in five or less “whys”, we “Google” it. This stops me from getting frustrated and saying, “Because I am the father and that’s the way it is!” Because I believe everyone is born with natural curiosity, I believe everyone can be a BA.

You have it in you to be a great BA. The question to ask yourself is “Do you want it?” If you want it, if you have the desire, you will put in the extra effort to do what it takes to be a great BA. If you have the desire you will adapt your approach over time to do what is right for the customer. You’ll question practices that are done just because that is how you or others have been doing it for years. You will become persistent in trying to find out the root cause of the business opportunity or challenge to feed your natural curiosity.

The profession needs more people with desire. There is a lot of talk about BAs not getting the respect we deserve; management does not see the value we bring, yada, yada, yada. We need to remove that talk from our vocabulary. We need to prove our value and earn respect based on our actions.

You are on board and really have the desire, but still struggle with unleashing your natural curiosity. Here are two reasons why your curiosity is not working at its peak performance.

Suppressed Curiosity

If everyone has the natural curiosity to be a BA, then why are there people that don’t use it? I believe it is due to years and years of being programmed to suppress our natural ability. I am closer to psychic than I am to being a psychiatrist, but I believe all you need to do is reprogram yourself. There were many points in your life where your curiosity was being squashed. I look back at my childhood and for me it came from trying to better understand my religion. When I asked about certain traditions I sometimes received the answer “this is the way it has been done for thousands of years.” Maybe it was my love for Math as a kid. There is no need to question why 2+2=4. That’s the answer. I also remember getting the “because I said so” answer from adults in my life. All of these things suppress our curiosity.

Take a minute and think of your past and see what may have suppressed your curiosity. You need to try bringing it back. You need to try and reprogram yourself to make curiosity part of your routine as a BA. Go out there today and ask that extra why. Remember how it feels as you get to the root cause of the issue. Then keep trying it.

SMEness

Another reason we lose our natural curiosity is we think we know the answer, so why ask. Many of us move into the BA role because we were subject matter experts on an application or business area. When you are on projects that touch that business area or application you feel you know the answers, so why ask the new subject matter expert you are working with. Remember, now that you are a BA, you are not an SME. The day you switch roles your “SMEness” begins to diminish. As a former SME you do have an advantage. You know the business area and can quickly develop questions to ask the business area. But a big disadvantage is you don’t ask the business the question because you think you know the answer. Ask the questions. You may know many of the answers, and there will be some that surprise you.

The desired BAs of the future ask the extra why. The desired BA is one that is persistent and tries to understand the root cause of the business challenge or opportunity the business is trying address with the project. If you want to be a desired BA, you need the desire to continue driving out your natural curiosity. Our profession needs you.

Curiously yours,

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected].

Will the Real BA Foundational Skills Please Stand-up

Written by Kupe Kupersmith on February 16, 2010. Posted in Articles. 1 Comment on Will the Real BA Foundational Skills Please Stand-up

An interesting discussion was started on a LinkedIn group a few weeks ago posing the question, “What would you think is the single factor that determines project success?” This sparked a healthy debate and made me think on a more micro level for business analysis. I asked myself what are the foundational skills needed by a business analysis professional? It did not take me long to answer my own question. Let’s see if you agree.

Let me start with what I think they are not. In our profession it has been discussed that at a minimum, BAs had to know the accepted techniques used in the role. Examples include use cases, workflow diagrams, context level data flow diagrams, etc. These are critical pieces to making an excellent BA, but not the foundation. They are interchangeable and new ones can pop up at any time. Did people not analyze before use cases became a standard format for analyzing and documenting requirements? Sure they did. These techniques are not a constant.

Analogy time! Let’s consider a house. The foundation is solid (hopefully). It supports the living space of the home. The living space is filled with appliances, furniture, art, rooms with doors, closets, windows, etc. Depending on what you are doing in your home at any time, you use some rooms, some furniture, and maybe an appliance. At the same time rooms, furniture, and appliances are not being used. Then there is the bread maker you were given for a house warming gift. That baby only comes out during special occasions. The rooms, furniture, and appliances are the equivalent to the techniques I mentioned earlier. The techniques are used when necessary. Every project does not require the use of every technique you have available. So then, what are the real foundational skills you need?

When I think of a foundation, I think of something that is constant, always there. Your foundation needs to be built with trust, analytical and problem solving skills, mixed with ethics, personal organization, business knowledge, and communication and interaction skills. These are often referred to as soft-skills, but these are nothing close to being soft. This is your foundation. From here everything is possible.

In the IIBA BABOK these skills are called underlying competencies. The writers of the BABOK define these as “the skills, knowledge, and personal characteristics that support the effective performance of business analysis.” The writers got it right by using the words “underlying” and “support”. Without these skills BAs cannot perform at their peak, just like a beautiful front door that won’t open or close properly because of a settling foundation.

Knowing the technical aspects of the techniques available to you is not enough. Even if you know the when to use an Activity diagram and all the symbol definitions, it is useless if your foundation is not secure. What good is that technique if you don’t have the interaction skills to elicit the requirements, or the communication skills to ensure you understood the requirements, and the ability to ensure the solution team clearly understands the need.

Take a few minutes and inspect your foundation. Is it secure?

Foundationly yours,

Kupe

Don’t forget to leave your comments below

Get Your Head Out of the Weeds!

Written by Kupe Kupersmith on February 2, 2010. Posted in Articles. 1 Comment on Get Your Head Out of the Weeds!

In our profession there is often talk about business analysts needing to get out of the detail and take a look at the bigger picture to make sure your efforts are still heading towards the goal of the project and the company goals. I refer to the syndrome of never getting out of the details as being “in the weeds.” In theory, looking at the big picture every now and then makes perfect sense. I have been asked by BAs how do you do it and when is a good time. I thought I would give an example of how I try to build-in project milestones where I force myself to pull back the weeds and take a look to make sure I am heading down the right path. Now, on agile projects this should be built in to the process. Before beginning a new sprint, the team should be looking at the big picture and determining the right path. The example below addresses how I did this on a recent project using more of a traditional approach.

The Project

I was the lead analyst on a project with a goal to elicit and analyze the business processes for four sister companies to help them determine if it was feasible to build an enterprise-wide technical solution for all companies. The project was initiated because each company had built and maintained systems. In many cases there were multiple systems with the same feature set. This project was part of a large initiative to reduce costs. The thought was, if there was one system rather than four, the long term cost to maintain and enhance the system would be less. The first step we took was to identify every business process conducted by each company and come to an agreement on all the process names. It was imperative to compare apples to apples. That effort revealed 145 unique processes to analyze. Yikes…that’s a lot! I’m not even going to bring up the timeline given to us. Let’s just say it was unrealistic.

Insert Milestones

The business stakeholders did not want any recommendation until all the processes were analyzed. They felt very strongly that without seeing the analysis of all processes, there was no way they could make a decision. Deep down I knew if we waited to show results of our analysis until the end there was a huge risk of us missing the mark. So I convinced the business stakeholders that we should attack the 145 processes by breaking them into smaller logical groups. We organized the 145 processes into 16 high-level groups. That is about nine processes per group which was very manageable chunks. The project plan was developed to attack the highest priority groups first. I also was able to have everyone agree we should stop at the end of each group and validate our understanding of the processes, present similarities across the companies, present variations, as well as the benefits and challenges of moving forward with an enterprise solution. In essence, we applied an agile approach under the disguise of a traditional approach. This is where we had milestones built in to the plan to get our heads out of the weeds.

The Result

After we analyzed the first group, we validated our understanding of the processes, presented similarities across the companies, presented variations, as well as the benefits and challenges of moving forward with an enterprise solution. Then we asked two questions to the group.

Did the information provided give you enough information to make a decision about moving forward with an enterprise solution?
Was there a reason to continue to the next group?

We wanted to uncover any issues our stakeholders had with what we presented. We had to know if we were doing what was necessary to meet the project objective. This gave us an opportunity to inspect how we were doing and what needed to be changed. Based on the answers, appropriate changes were made to our approach and we were asked to continue to the next group.

After the next group was complete, we asked the same questions. This time the business was able to determine that it was no longer necessary to compare business processes across the four companies. They had enough information to realize building an enterprise solution was not worth the investment. The initial project was canceled and new projects were initiated to help each company build update, and maintain their systems. In this case, our path ended before we anticipated.

By building in milestones in our project to get out of the weeds, two critical things happened:

The initial project was stopped, potentially saving approximately 200k in cost.
By stopping the initial project and moving forward with implementation projects for the companies, they will realize the benefits of new and enhanced systems four months earlier.

By getting your head out of the weeds and checking to see if you are still headed down the correct path is a characteristic of a seasoned business analyst. As you gain more experience you will naturally look up every now and then. If you are not there yet start inserting milestones in your plan to give you definite points in time to look up and make sure you are headed down the right path.

Stay on the right path!

Kupe

Don’t forget to leave your comments below

Treat Your Career Like Weight Watchers

Written by Kupe Kupersmith on January 19, 2010. Posted in Articles.

This week I caught the Joy Behar Show on Headline News. Joy is one funny lady. This segment of her show was about weight loss/maintenance. One of her guests was the CEO of Weight Watchers, David Kirchhoff. The one thing that has always impressed me with Weight Watchers over the years is their philosophy. Mr. Kirchhoff explained it in three words, education, support, and behavior change. As I was watching the show I kept thinking, that philosophy is what needs to be a part of our daily lives as business analysts.

Education

As we have discussed before, many business analysts are moved or hired in from other areas. Many come from the technical side of the house and others come from the business side of the house. Not until recently have you seen universities teaching students some of the skills needed to be a business analyst. Actually I am starting to see elementary schools breeding future analysts. My daughter’s third grade class was learning about process flows. I almost cried when I reviewed my daughter’s homework. Her teacher thought I was a freak when I ran into the classroom the next day and would not stop thanking her for teaching the kids about process flows. But I digress.

What this means is many of us got into a BA career without any kind of formal training. It is critical for newcomers to get foundational training on the techniques available to business analysts. The projects we work on are critical to the success of our companies. How can we expect consistent positive outcomes from those that have not been trained properly? Why is this tolerated in our field?

Education is on-going and not a one-time event. You don’t go to a class and check off a box saying you did the education piece. I hope blogs like mine and others are educational. There are more advanced classes, books, conferences, online forums dedicated to business analysis and, of course, your local IIBA chapter. My advice is never stop learning.

Before we move on, I want to make sure everyone knows my background/bio. I do work for a business analysis training provider, B2T Training.

Support

In the United States, January is National Mentoring Month (NMM). Created by the Harvard School of Public Health and MENTOR, NMM is marking its ninth year in 2010. By focusing national attention on the need for mentors, as well as how each of us-individuals, businesses, government agencies, schools, faith communities and nonprofits-can work together to increase the number of mentors, we assure brighter futures for our young people. I think it is wonderful that these organizations are promoting mentorship for children. Learning at an early age the value of having a mentor or mentors will help these children succeed in life.

Now more than ever it is so important for us as business analysts to find a mentor. At the same time, we should open ourselves up to become mentors for someone else. It is very enriching to be a mentor. Without mentors, BAs will continually be set-up to fail.

A mentor is someone with experience in a field or subject that helps a less experienced person advance in their career. In the past, companies had a layer of management that moved up the ranks. Part of their role as a manager was to guide and mentor the less experienced team members. Although I am seeing a shift in that BAs are growing up to manage BAs, there is still a large gap. Many BAs are managed by people who have never played the role of a business analyst. This presents the situation where many BAs cannot look to their manager for guidance around the BA activities they do day in and day out. We need the support because we can’t do this alone. Even the greatest Jedi to ever live, Luke Skywalker, had a mentor in Obi-wan Kenobi. Find a mentor that can help you grow as a business analyst.

Behavior Change

It is not enough to get the education you need and find a mentor. You have to make the commitment to change. At times, I am just as guilty as the next person when I come out of a training class/seminar. I am fired up and excited just thinking about how I am going to implement all these new things I learned. I wake the next day, bounce out of bed, and I rush to the office. I sit in my chair day-dreaming about all the new skills I have, and then do the same thing as I did prior to training. This is natural. Sometimes it is hard to determine which of the new skills you should try out and when.

My suggestion is start small and keep building. Brad Childress, the Minnesota Vikings head coach, said he starts his rookies off with a small menu, but with deep knowledge. In other words, he gives his rookies a few plays to focus on instead of the entire playbook. As the rookie gets comfortable with the few plays, he adds more to their plate. Use this philosophy as you learn new things. Don’t try to make a complete change all at once.

Take a few minutes to think about where you may need some education and look for avenues to acquire what is necessary. If you don’t have a mentor, please begin your search to find at least one. Lastly, begin changing your behavior now in small chunks. I think we all know Albert Einstein’s definition of Insanity: doing the same thing over and over again and expecting different results. Together let’s stop the insanity.

All the best,

Kupe

Don’t forget to leave your comments below

Small Projects Drive Me Crazy!

Written by Kupe Kupersmith on January 5, 2010. Posted in Articles.

OK, it is not small projects that drive me crazy. It is what I see project teams doing because a project is classified as a “small” project. Teams get the feeling that there is no need for a BA, no need to follow a process, and/or no need to plan. All of these thoughts just because the project has been labeled as a small project! That’s what drives me bonkers. And what happens on most of these projects? Teams struggle, things are missed, and at the end of this small project, teams scramble to finish up. Of course, no project retrospective is done because; well…it was a small project.

My philosophy is that every project is different, and the team needs to take the steps that add value to the project. This does not mean planning is not important or following a process is not important. It means plan as much as necessary and take the steps in the processes that are needed. You need to analyze each project and determine what makes sense. I know many companies that try to classify projects by size, and then decide if a BA is needed, what techniques to use, how much to document, etc. I have heard people say a small project should have less than 50 pages in a requirements package. So if there are 60 do we no longer classify the project as small? Why try to keep a BA to documenting “x” number of pages? The number of pages should reflect what is needed for that project. The problem with this approach is that projects do not easily fall into buckets. There are too many factors that you need to consider in order to determine what techniques to use, and so on. The type of project, the people on the project, and internal company processes are all high-level factors that need to be considered. Putting projects in buckets opens the team up for failure and focuses the team’s attention on rules in a process. Their attention should be on the customer and the goals of the project.

Teams come up with a process for small projects that are different than large projects because teams try sticking to a prescribed process for every project. Trying to implement every step in a process is overkill for some projects. Coming up with another prescribed process does not solve the problem. In my Going Rogue blog post I think some of you had the impression I do not believe in having a process, or not needing a process as you get more experience. That is not the case. What is true; I don’t believe in a strict prescribed process for everyone and every project. I do believe in a process. It just needs to be fluid and ever-evolving. It has been proven by smarter people than me that having a repeatable process is the key to improvement. A process gives you an anchor to track areas of success and areas for improvement. So, I do believe a process is absolutely necessary.

The only step in a process I can say for sure is needed for every project is planning. For every project the step that must always happen and be taken upfront for a BA is plan the approach for each project. From that plan a determination will be made as to what techniques to use, how much to document, etc. For the techniques chosen, the BA should use the rules or guidelines outlined in the overall process. For example, if use cases are planned to be written for the project, the BA should use the template provided. A BA does not need to complete every step in a process, but if they do perform a step they need to be consistent with the other BAs in the organization.

Projects are not an exact science, so don’t try to place a prescribed process for each and every project. Try to understand the variables of the project, the people, the internal processes, and then plan your approach. I approach projects like I approach my kids. They are each very different, so I treat them in the manner that is best for them. I do not cheer for my oldest daughter at sporting events because she shuts down and stops playing. My son loves when I scream like a raging lunatic at games because he thinks it’s funny. I say it motivates him and he does not want to admit it yet! My youngest daughter, well, I have not figured her out yet!

Happy New Year everyone. I am looking forward to another year of great discussions on the profession we all love!

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected]