Skip to main content

Author: Aaron Whittenberger

What is your Business Analyst Brand?

Written by Aaron Whittenberger on . Posted in Articles. 1 Comment on What is your Business Analyst Brand?

I give complete credit for this article to Bob “the BA” Prentiss. I had to privilege and pleasure of hearing his keynote address to the Southwest Ohio Business Analysis Regional Conference (SOBARC), hosted by Cincinnati IIBA Chapter. It was a very entertaining and thought provoking presentation. So I invite you to consider “What is your BA Brand?”

Did you know that you had a brand? What is a brand? Many think it is a marketing tool that companies use to sell their products and services in the marketplace. Absolutely correct; don’t you think that Apple, Google, B2T Training, The Solarity Group, Bob the BA, and Watermark Learning have brands?

However did you know that you, an individual Business Analyst in your company, have a brand? What is your brand? The more important question, what do you want your brand to be?

These are the questions that Bob “the BA” Prentiss asked us at the recently concluded SOBARC conference during a very inspirational keynote address. He gave excellent tips on how to brand yourself and make yourself distinguishable among the business analysts in your organization.

whittenberger May26whittenberger May26 IMG002

One thing that impressed me during Bob’s presentation is that he never went up on stage; he delivered his entire presentation walking among the audience. When he asked the audience “What do you think about Bob the BA?” He received the joking answer “pushy”. He did not get upset, but rather took a negative and turned into a positive. He continued to discuss how we from time to time have to change the mindset and the way of thinking of some of our business and technical stakeholders to create that “shared vision”. Ending that thought with “sometimes pushy, yes I can accept that because sometimes that is what it takes to get the job done”.

So, did you know that you create your brand every day at work? So what is your brand, and what do you want it to be? As ‘Bob the BA’ puts it “Be consistent, creative, memorable, have a signature that ‘you’ cocktail…” is how you develop a great brand.

So are you consistent?

Do you consistently deliver your work deliverables on time? Early? Late? Do you “own” your work assignments? How do you want to be remembered? What is the impact to your projects and service work? Can your teammates count on you to deliver? Do you communicate to your Project Manager and other team members to properly set expectations? How is the quality of your work? That will be remembered, possibly most of all. Do you take extra time to put the professional touches, add that craftsmanship, on your work before sharing it with the team? Just a word of caution, don’t allow the professional touches make your work consistently late.

Are you creative?

Do you just take a template for an artifact and fill it out? Have you ever added something to a template? Have you ever questioned why a particular section is in the template, or challenged that it should not be in that place or in the template at all? How creative are you on your business analysis techniques? Do you just do typical individual or group interviews (discussions with business stakeholders)? When is the last time you facilitated a brainstorming or wireframing session?

Are you memorable?

Six months after a project ends, will the business stakeholders remember you as the business analyst that worked on that project? What will they remember about you? Will they say “typical BA”, “nothing special”, “shoddy workmanship”; or will they say “excellent BA”, “knows their stuff”, “kept me engaged”, “enjoyed working with them” or other favorable feedback on your work. How will you be remembered?

Are you passionate?

Do you enjoy your work and does it show in your daily work? Are you passionate about the BA role? Do you look forward to going to work every day? Will feedback come back that you’re a passionate BA? Do you go that extra mile for your business stakeholders and other team members? How will you be remembered?

The Message

I recently attended an IIBA meeting in Dayton, Ohio entitled “Craftsmanship for Analysts” by Terry Wiegmann. The message was the same as Bob the BA’s message: “Cocktail your brand”. Continuously improve, but stay consistent in your message and work. I don’t intend to take anything, or keep anyone, from seeing either of these professionals speak. In fact, I encourage anyone that has the opportunity to go participate in any of Bob or Terry’s presentations, do so; you will receive a lot from the experience.

Did this post get you thinking about your brand, and your daily work? How will you change to make your brand what you want it to be?

Don’t forget to leave your comments below.

Who’s Running the Business?

Written by Aaron Whittenberger on . Posted in Articles.

Case Studies in Stakeholder Engagement and the Business Analyst Role

I am wondering how many people, after reading that title and my biography, think that I am going to suggest that business analysts should run the business. If you think that is the path that I will take here, you will be sadly disappointed. The Business Analyst’s task is to identify the business problem and get the group of involved stakeholders to collaborate on a solution to that problem. The business analyst is rarely the owner of the solution.

First let me give you some background. I was a developer in the early part of my career and transitioned to a business analyst as the discipline was forming in many companies. The profession of business analysis continues to mature. I have 15 years of consulting experience and have been in many organizations. I have seen how they operate and utilize their business analysts, project managers, architects, developers and quality assurance teams on software development projects to help the business operate more smoothly. In most organizations where I have been, business analysts report to the information technology side of the house. However, I have been in organizations where they reported to the business side or reported to a separate entity within the organization (such as an enterprise PMO), and had business analysts on the business and technical sides of the house. So this article will come from a heavy IT perspective with empathy to the business stakeholder.

One thing I have noticed quite often is that business analysts, project managers and the entire technical team seem to forget that the main duty of business stakeholders is to run the business. You will hear technical team members complain about not being able to get needed time with a key business stakeholder to keep the project going, or that project business sponsors are disengaged. Whereas, the main duty of the technical team is to the project and delivering the solution of that project; let’s remember that the business stakeholder has a different priority. Business stakeholders, in particular subject matter experts (SMEs), are needed on projects to lend their business knowledge and collaborate on a solution. If the technical team was left to design the solution in a silo with no business input, the risk becomes that the solution delivered will be rejected by the business users. The technical team wasted their time delivering a solution that will never be utilized because there was no input, buy-in or ownership from the business. This doesn’t happen in every case, but it would happen at even more alarming rates if the technical team designed the solution without business input. At the same time you can’t get all the business stakeholders as fully dedicated to the project as the technical team is because there would be nobody left to run the business.

This is one of the reasons that the agile approach to software development has taken hold in many companies. By placing one business stakeholder, the product owner, completely dedicated to the IT project, it leaves business management in the engine room to run the business. It is important to the success of the solution that this project owner represents the desires of the business stakeholders well.

So let’s take a look at some case studies in the different organizational structures and the business analyst role in each. Which one is in use in your company? Is it optimal for business success?

Business Analyst reports to Information Technology In this structure the business analyst is viewed as a member of the technical team. From the business stakeholders’ perspective it is difficult to remove the “Us vs. Them” mindset that exists in many organizations because you are part of “Them”. In one organization I was at they talked about a business analyst that literally camped outside a key business stakeholder’s office door all day and still could not get their attention. However, in many organizations this structure works because the business analyst, just like the project manager, is seen as a key member of the project team that helps drive to the needed solution.

Business Analyst reports to the Business Organization

In this structure the “Us vs. Them” mindset works in the opposite direction; where the technical team sees the business analyst as a business stakeholder. I have seen this in two different scenarios; 1) where the business analyst is used as a proxy for other business stakeholders, and 2) where the business analyst is joined on project teams with additional business stakeholders. The perceived value of this structure is to reduce or remove the business stakeholders’ time involvement on software development projects leaving more time to run the business. In the scenario where the business analyst is a proxy for other business stakeholders, the business analyst better be tightly coupled with the business management of the line(s) of business that they are representing or it could spell disaster for the solution delivered. It is the business analyst’s neck that is on the line. The risk in this structure is that the business analyst is not tightly coupled with the technical team to help drive to the best solution to solve the business need.

Business Analyst reports to a Separate Entity within the Organization

This may be the best structure to remove the “Us vs. Them” mindset, as the business analyst is neither “Us” nor “Them”. The business analyst is often seen as a consultant to assist the project team, both business and technical, to come up with the best solution to solve the business problem. The outcome of this structure is often that even though the business analyst is an internal employee, they are seen as an outsider from both sides of the team. This can make it harder to have opinions heard, get recommendations accepted, and drive to consensus. In the situation where it is a PMO that the business analyst reports to, the project manager is likely in the same boat. The side effect of this structure is that it does not reduce the time commitment of the business stakeholders to the project, therefore leaves the question…Who’s Running the Business?

Business Analysts on the Technical Team and Business Analysts in the Business Organization

On rare occasions I witnessed a company going so far as having business analysts on the information technology side and on the business units of the organization. I have seen this structure work efficiently. The ‘business’ business analyst can do the enterprise analysis work to help business management identify business need, develop the business case for a solution to that need, and work the proposal through the project approval process to become an official project. Then there can be a hand-off from the enterprise business analyst to the technical analyst as the project initiates.The technical analyst will see the project through to deliver the expected value to the business. The enterprise business analyst can also serve as the business SME throughout the project to reduce the time commitment of other business stakeholders, thereby leaving someone at the helm to run the business.

So the lessons learned are that the technical team must remember that the business stakeholders’ main duties do not lie with the technical project, as theirs do. When it is difficult to get on the calendars of your business stakeholders, remember they are doing their job. Likewise, as a business stakeholder being asked to participate in a software development project, remember that without your proper level of engagement and dedication to the project the solution delivered may not be the best solution to deliver the greatest value to the organization.Your business team may be stuck with that solution for some time. There is no greater example of the need to collaborate to arrive at the best solution for all concerned.

Don’t forget to leave your comments below.

The Value of Business Analysis: Identifying Business Need

Written by Aaron Whittenberger on . Posted in Articles.

One of the critical roles of the Business Analyst (BA), or Enterprise Analyst (EA), in the area of Enterprise Analysis is to identify business need. Many business professionals make the mistake of thinking that since it is named Enterprise Analysis, that identifying business need can happen only at the enterprise level. Nothing could be further from the truth; Enterprise Analysis and identifying business need, can happen at the enterprise level, involve multiple lines of business within the organization but not the entire enterprise, and at the business unit level.

There are many factors, or many ways that the business analyst can identify business needs. It can be a result of market research or an identified new opportunity brought about by actions of a vendor or competitor. It could be derived from a strategic goal or initiative of the organization. It could have come from a business user complaint about a current system issue and/or the subsequent Root Cause Analysis. It could also be derived from an Enterprise Analysis activity that the BA performed, such as Capability Gap Analysis, SWOT Analysis or Product Feasibility Analysis.

If this vital role is not performed than the organization would not realize the benefits of identifying some business needs that need to be addressed, possibly gaining greater competitive advantage, possibly achieving strategic goals or taking advantage of an opportunity presented in the market. As you can see this can have a direct effect on the strategic success, and bottom line, of the organization.

Define Business Need

Once identified, the business need should be documented in the Business Case to initiate a project to develop a solution for this business need. This solution may, or may not, involve information technology software development; some solutions are completely a business solution. The business need defines the problem for which the business analyst is attempting to find a solution. The way the business need is defined determines which alternative solutions will be considered, which stakeholders will be consulted and which solution approaches will be evaluated.

Define Problem

Defining business need and defining the problem are two different things. The business need leads to the problem, but both the business need and problem statement needs to be defined and documented. Take for example that you have identified that sales have been decreasing for the past three years. So your business need statement could be “Need increased sales”. What is your problem statement? A root cause analysis uncovered an aging sales force using archaic sales techniques, no new products introduced to the marketplace in three years, competitors introducing products with innovative features, no new marketing campaigns in the last two years, rising costs, and production equipment in need of repair and upgrade.

Leads to the Solution

Now that the true problems have been identified, the enterprise can now initiate separate projects to find solutions for the sales problem, product problem, marketing problem, and production problems; rising costs and production equipment. The team assigned the sales problem can determine if they need to hire younger salespeople, provide sales training on newer techniques, provide better sales support, or implement a new Customer Relationship Management (CRM) system. Likewise, the other project teams will determine proper solutions to their defined problem statement.

One pitfall that many business analysts and project teams fall into is trying to define the business need by the solution. In practice, quite often the business stakeholders define the solution at the start of the project instead of defining the problem statement first. They start with the solution first instead of the problem first. This reduces the solution alternatives that receive consideration and may bring a lesser valuable solution to deployment than what could have been achieved. So starting with the business need, problem statement, and solution scope; then developing alternative solutions will bring the most valuable solution to the organization, and the business analyst’s recommendation, to light.
In our sales problem example above, the organization may have identified slumping sales for three years. Without proper problem statement identification the business team may decide to simply hire more salespeople to increase sales. Without proper root cause analysis, they may hire older salespeople, just like the rest of the sales force they have. None of the true root cause problems get resolved because the team jumped to the solution with identifying the true problems needing addressed.

We all learn from our mistakes, what pitfalls to developing the Business Case have you encountered in your career?

Don’t forget to leave your comments below.

The Value of Business Analysis: Creating Shared Vision

Written by Aaron Whittenberger on . Posted in Articles.

One of the greatest skills a business analyst can learn and utilize to add value to business stakeholders and the organization is the ability to Create a Shared Vision. This, in fact, should be the goal of the business analyst in every task or project that they undertake. This can be done at any level of the organization; with executive management, business management, business stakeholders, staff or end users, technical stakeholders and, yes even with, the newest hire in the organization.

Creating Shared Vision

Creating a shared vision is much like painting a picture. You are painting a picture in everybody’s mind and heart so clear that everybody can see and understand the picture. No, painting is not one of the tasks or skills of business analysis. You paint a picture with your words and documentation. Text documents, flow diagrams, use cases, storyboards, user stories, activity diagrams, business process models, wireframes and other mockups can all be used in paint a picture. These can be used in combination to paint an even more vivid picture for your audience. How you communicate using these pictorial tools can bring clarity to the vision. I will talk about targeting your vision to the audience in a minute. Sometimes, as in requirements elicitation, it may mean that you gain the vision of the stakeholder. If in a requirements workshop, focus group discussion or one-on-one interview, drawings on paper or a whiteboard can facilitate shared vision and understanding. Often, it may be that you have the business stakeholders paint the “as-is” picture for you, and then you help them paint the “to-be” picture. By painting a picture so vivid that all stakeholders share the same vision of it, this is how we build the bridge to understanding and ensure that all involve understand the same vision.

Start from the Problem Statement

As most business analysts will tell you many projects, business or technical, are initiated with a solution in mind instead a problem. Adrian Reed, CBAP of the United Kingdom articulated this issue in a Podcast interview with Yaaqub (Yamo) Mohamed, CBAP. As James Szuch suggests every project should start with the problem statement. If the business stakeholders already have the solution in mind, then ask them why this is the solution and what problem is it going to solve for us. Get all the stakeholders back to the problem, and make sure everybody understands the problem that you are trying to solve.

Gaining Shared Vision

As I mentioned earlier sometimes it is best to have the business stakeholders share their vision of the current state of the system or process you are considering changing with you and the other stakeholders. This is particularly effective if you are investigating a system or process that you personally are unfamiliar with; however, I use this technique with every new project, task or when I work with a new group of stakeholders. It starts to build the relationship, gain trust, and shows them that I value their expertise in their domain. This also helps reduce errors and omissions. I was once engaged to help a client gain video capability on their website. When I began the first few groups of stakeholders I spoke with said they had no videos currently on their websites. When I got to the marketing department, they said that there were a couple of videos already on their website. So I investigated the platform that was used to embed the videos on the website. If I had not continued my investigation of the current state with each department I spoke with we would have started the project thinking that there was no current state from which to start.

Extending the Vision

Once you have that vision of the current state now you make sure all concerned have the same vision. This is what Kupe Kupersmith, CBAP refers to when he discusses creating Vivid Descriptions. With my client that wanted video capability, I was able to inform the other business units that we indeed did have some videos already on our website. Each business unit had a platform in mind that they wanted to see implemented. The fact, the organization already had a platform in use played into the decision making of the business stakeholders. We did not go with that platform, but this allowed them to open their minds to other possibilities other than the one they had walked into the project already in mind.
Extending the vision works with both the current state and the future state of the system or process under investigation. You build the future state vision together with the stakeholders, business and technical, using the pictorial tools I mentioned above.

Target the Vision to the Audience

In order for your audience to gain a vision, they must not only see the picture, but understand it. The picture must be painted in a way that facilitates understanding; it must be presented in a way that the audience can comprehend. You may use flow diagrams, use cases, story boards and/or activity diagrams when painting the vision to a business audience. You may use text documents, flow diagrams, use cases and/or activity diagrams to paint the picture for a technical team. You may use very short summary text documents and/or flow diagrams to present to management. You would use more detailed documents and diagrams when presenting to business users; and even more detailed documentation when presenting to a technical audience. To create a shared vision the picture must be presented in a way that facilitates quick comprehension from the audience to whom it is being presented.

Conclusion

So as you work on your tasks, whether it is a small task, business process improvement project, software development project, architecture project or enterprise initiative remember to always Create a Shared Vision with and among the stakeholders with which you are working. In this way you can be assured to implement the best solution for the organization. As Kupe put it:

“You need to help them get clarity around the problem or opportunity they are trying to solve and more importantly the outcomes or results they want.”

Don’t forget to leave your comments below.

Business Analysis: Sharing Your Knowledge: Why and How

Written by Aaron Whittenberger on . Posted in Articles.

Often, through their normal daily work the business analyst learns new knowledge about systems, business processes or the organization as a whole. In doing business analysis tasks on a daily basis, a business analyst investigates systems; whether through documentation analysis, interface analysis or interviews with system users or subject matter experts (SME), they learn how systems operate and how the business uses the system(s). Business Analysts are often called upon to document business processes, so they investigate those business processes through interviews or surveys of those involved in the process. Through Situation Analysis, Capability Gap Analysis, Feasibility Studies, SWOT Analysis, Market Research or Organizational Change Readiness assessment to implement a new project solution the business analyst learns about their organization and the business environment in which it operates.

All too often what happens when the business analyst leaves the team or organization is all that learned, and now tacit, knowledge leaves with them. Then comes the unpalatable task of replacing the business analyst and bringing the new person up to speed with the team. What can never be regained is that knowledge that left with the previous business analyst. Wouldn’t it be great to keep that tacit knowledge?

As the exiting business analyst how can you leave that knowledge with the team as you move on to other opportunities, especially when those opportunities are outside the organization? Do you want to spend the last two weeks on the team trying to hurriedly document all your tacit knowledge? Where do you store it; in what format? Let’s look at a better way.

An Internal Body of Knowledge

An internal Business Analysis Body of Knowledge is a centralized, electronic knowledge repository from which the entire business analysis team may draw knowledge. Centralized to one business analysis team or across the organization; who is this knowledge base to serve. Once you determine who your customers are, you can determine where to store this knowledge base to be centralized; and you can consider such things as security and access. You can determine if this should be stored on a shared network drive, SharePoint or another document repository.

Start from the beginning

Don’t wait until your final week or two in this role to try to leave all your knowledge with your co-workers. Start from your first weeks on the job. As you investigate and learn these systems, business processes and the organization start documenting what you learn about things. It is very difficult to document years of knowledge in your final week(s) on the team; so start soon after you join the team. Document as you learn. This also helps to ensure that important items don’t get forgotten.

Start Small and Grow

Egypt wasn’t built in a day, so don’t feel that you have to build an entire knowledge base in a week. If you start soon after you join the team then you won’t be rushed to build your internal body of knowledge in a week or two. You can build it over years of learning. Start from the first system or business process that you investigate. Document one system or business process and store that in your centralized place. There is your start. Add each system, business process or piece of organizational knowledge you learn while you are in this role and watch your body of knowledge grow. As the knowledge repository grows, you build the structure of the repository.

Start Yourself

You can bring the idea of a centralized knowledge base to your team and try to get buy-in; or you can just start yourself. You may have to determine what the team or corporate culture is to determine if you ask for permission or beg for forgiveness. As a consultant, it is my ‘value-add’ that I provide my clients. I build my internal body of knowledge and as I leave the team I show the team the knowledge I am leaving them.

Invite Others to Join In

Once you have the knowledge base started and others can see the value, invite them to add their knowledge to yours. This can grow the knowledge exponentially. Obtaining their buy-in is much easier when you can show them the value.

Get Started

So now you know what an internal business analysis body of knowledge is and have a concept of how to build one…get started. Determine who you wish the knowledge base to serve, determine where to store it and get started building it.

By building an internal business analysis body of knowledge for a team or organization that you will eventually leave; face it we all leave at some point whether by choice, retirement or other forces, you can leave behind business, systems and tacit knowledge you have built up over time. The great advantage of starting early is that you don’t have to hurry up, remember everything and build it all in a short timespan as you prepare to leave the team. For a consultant leaving a team, this is a great ‘value-add’ to provide for your clients.

Don’t forget to leave your comments below.