Tag: Best Practices

SWOT of Business Analysis

Written by Sharon Bennett on October 31, 2016. Posted in Articles. 1 Comment on SWOT of Business Analysis

Out of curiosity about the future of a career path that I have been on for more than 2 decades, I have decided to create a SWOT outline of business analysis.

SWOT is an acronym for strengths, weaknesses, opportunities, and threats—and is a structured planning method that evaluates those four elements:

Strengths: characteristics of the entity that give it an advantage
Weaknesses: characteristics that place the entity at a disadvantage
Opportunities: elements that the entity could exploit to its advantage
Threats: elements in the environment that could cause trouble for the entity

In creating the SWOT outline, the International Institute of Business Analysis (IIBA) BABOK definition of Business Analysis will be used:

According to the BABOK Guide v3, “Business Analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business Analysis enables an enterprise to articulate needs and the rationale for a change, and to design and describe solutions that can deliver value. “

Let’s get started!

Strengths:

The IIBA has done a great job of promoting and supporting the business analysis profession. It has given it a voice globally. It also supports the recognition of the profession and works to maintain standards for its practice and certification. It has also provided a model for the formation of regional IIBA communities and Business Analysis Community of Practice entities (i.e. BA CoPs) within companies.

Many career options/ paths are often available to business analysts. The nature of business analysis often involves working with the business to identify business needs, problems, and opportunities while also working with Information Technology teams to define, design and implement solutions. Also, they often have to interact with multiple levels of an organization; strategically, tactically and operationally. Therefore, they gain experience in supporting and contributing to corporate direction, the organization’s enterprise architecture, stakeholder needs and business processes. This wealth of access that business analysts have within companies often place them into a position of having a career path choice in the business and/or Information Technology (IT) realm.

Weaknesses:

Even with the formation of the IIBA and the life of the business analysis profession spanning decades, there is still confusion in the business community around the profession of business analysis, even in regards to the basic question of; “What it is?” I consider this lack of knowledge and confusion to be a weakness because in many companies it leads to business analysis not being promoted as a career path but instead business analysts are being encouraged to take other career paths available in the company as a form of promotion. As stated above as a strength, BAs often have many career path options in the realm of business and/or IT, but for those who want to make business analysis a long time career, promotion can be difficult. I will say that things seem to be improving on this front. I think that knowledge is being gained by the uprise of BA CoP (Business Analysis Community of Practice) entities. They give focus to the BA profession within companies and often with this focus comes recognition of the profession as a career path and its value provided to the company.

Opportunities:

Today, more than ever project teams have to deal with customers that are more than likely extremely knowledgeable about technology and their business processes and how they interact. They are also more demanding, wanting more authority and freedom in the decision-making process. This has led to shifts in business models, support provision needs, requirement elicitation methods and solution recommendations. Business analysts have the opportunity to drive accelerated change management in dynamic markets, filling a more strategic role in regards to enterprise architecture, demonstrating value and helping project teams quickly adjust to changing client and market dynamics.

Project organizations also have to ensure project deliverables are validated against both project requirements and the strategic requirements of the business at the business unit and/or corporate levels. This is to ensure a link exists between strategy and execution. The business analyst can be of great value in working with customers and project teams to keep them aligned in regards to business value to be delivered and how.

Threats:

Because threats are elements in the environment that “could” cause trouble for the entity, in this case, business analysis, I am listing agile as a threat. This is “not” in the sense of it eliminating the business analyst functions from the team. The IIBA has added an agile extension to the BABOK guide which provides an outline of how practices, tools, and techniques can be used by business analysts working in agile environments, and I will concur that there is definitely a need for business analysis functions on agile teams. I will say that agile environments often institute changes to the BA functions and/or how they are accomplished. In some cases, the BA functions may be distributed among other members/roles of the agile team. In some cases, the BA could be asked to fill the role of a product owner or coach. Even though the product owner and coach roles may utilize some of the BA core competencies defined in the BABOK, often these roles require more focus on vision/roadmap definition, return-on-investment (ROI), pricing/licensing for the product, which gravitates more toward the use of management competencies rather than BA competencies.

Diagram 1:

Strategy Spotlight: 11 steps to strategic analysis, planning and implementation success

Written by Richard Lannon on October 11, 2016. Posted in Articles.

Strategic analysis, planning, and management involves the formulation and implementation of the major goals and initiatives taken by a company’s top

management on behalf of the organization.

It is based on consideration of resources and an assessment of the internal and external environments in which the organization competes. The strategic business analyst has an important role to play in this process.

To be strategic means to provide overall direction to the enterprise and involves specifying the organization’s objectives, developing policies and plans designed to achieve these objectives, and then allocating resources to implement the plans. All of this needs to be analyzed and the requirements clearly defined.

I think this gets missed by organizations when they are seeking to have their strategic plans translated into requirement reality.

Imperative to implementation success is a proven approach to developing your strategy, management, and transformation needs. This must be in alignment with the strategic business analyst needs for current and future state understanding, assessing the risks components and defining the change strategy to make it all happen. But strategy all starts with knowing the steps you need to take.

Here are 11 steps that are imperative to your strategic analysis, planning, and implementation success.

1. Select the planning model and approach you will use.

This is imperative. I have witnessed many situations where the model and approach were never defined or were highly theoretical negatively impacting the stakeholder’s comprehension and participation willingness. Don’t make this mistake.

2. Identify your key stakeholders.

Proper stakeholder analysis is a must whether you are facilitating strategic planning sessions or reviewing and analyzing presented plans to determine their viability or build business cases for better business decisions.

3. Establish the questions you need to be answered.

There are at least seven key questions that must be asked and answered (see Question Everything About Your Business – 7 Candid Questions That Need To Be Asked), but that is not all. Find out what the outcome requirements are and host a ‘Questions to Ask’ session with your team to create a list of the questions you need to be answered. Categorize those questions by business impact and importance and identify the stakeholder source.

4. Determine where it is you and your team need to go.

This is all about your company’s ‘Vision of Success.’ It includes key strategic business information of vision and mission, values and guiding principles, and goals and objectives. This information should not be fluff. As a strategic business analyst, you need to know what is on the strategic agenda (goals and objectives) and why. Then you need to help translate that into tactical requirements (if you were not part of the initial planning). This is one place where you bridge the gap from the strategic to the tactical.

5. Focus on the business impact zones.

I have spoken about this for years, written articles about it and a book on the topic. Still, it amazes me that organizations and professionals (I mean business analysts) miss this point. There are generally four business impact zones (process and productivity, tools and technology, business development, and people and culture) with very specific requirements. Each impact zone affects the others through the decision-making process and actions taken. If you push on one you create ripples that impact the others. For example, recently a professional service company was forced to let go 120 of its employees. Externally the market changed (external) and the organization did not adjust quickly enough (internal), revenue declined (business development) and they were forced to let people go (people and culture) and adjust their working parameters (process and productivity) and renegotiate contracts on their working assets (tools and technology) to decrease costs.

6. Create a strategy map outlining focus areas.

Business leaders and teams lose focus, often caused by an external event (market shift, lost client) or people challenges (poor management, lack of communications, not asking the right questions, no alignment). A strategy map provides a visual of the key decisions and focus areas and is an important business artifact for the business analyst. As business requirements go, a strategy map can be translated strategically, tactically and operationally. This is Business Analysis 101.

7. Build an action roadmap to guide your business.

A strategy roadmap is a high-level implementation plan that displays the strategic agenda (goals and objectives), the strategic initiatives (programs), the business champion (the leader or sponsor), the work elements (projects), an alignment path (to keep things aligned), and time and milestone requirements. The best part is it can be a Gantt chart that can be translated and implemented.

8. Establish work plans with key activities.

This is another one of those steps that organizations and senior teams skip because they say they do not have time to do it. Then they wonder why no one is focused on what needs to be done. Simple rule, you don’t work-plan to fail, you fail to work-plan. Can you imagine what would happen if you hired a company to build you a new house and there were not work-plans from the drawings that were created? If the strategy and roadmap are the blueprints, then the work-plans are the tasks and activities, the resources, timelines and costs of making it happen with someone in charge of implementation. Still, someone needs to establish the work-plans solution requirements.

9. Identify the risks through risk analysis.

There is always risk and if you are going to have work-plans to implement the strategic initiatives, then you need to do risk analysis. The level at which you do your risk analysis will be dependent on your role. You will need the standard inputs – objectives, risk results, external and internal influences, future state solution value and requirements priority. There are a lot of factors that play into risk analysis.

10. Create a communication plan to engage people.

This is another activity that is often skilled or misunderstood, or there is a communication plan but no one has communicated that it exists and someone else starts to create a new one. There should be a strategic communication plan for the organization that gets translated into tactical and operational requirements. The communication plan is used in transformations, change and implementation.

11. Go the distance through implementation.

You have gone through the strategic planning and analysis process using a proven approach, and you have created all the supporting requirements, but nothing is going anywhere. This is one of those things that sometimes happens. You need to put a process in place to make things happen whether it is through quarterly reviews, metric dashboards, timeline reviews and status meetings, progress audits and touch points, next level work-plans and resource assignments, communication implementation – the list goes on. The strategic business analyst can have an important role to play in this as does the project manager.

At the senior levels, I have been asked to facilitate ‘Go the Distance’ meetings with the executive teams to help keep them on track and do point audits with project and operational managers who have been tasked with getting things done with report backs to the executives. I guess this is a career development thing for the junior and intermediate business analyst. Still, you need to support the strategic implementation of the key strategic initiatives in the organization.

Final Thoughts

There are many steps to be taken in the strategic business analysis world to shape the direction of an organization. Over the course of my career, I have been privileged to have worked on initiatives that have allowed me to explore each step stated here both horizontally (mile wide, inch deep) and vertically (inch wide, mile deep). It takes a lot of work to define and action an organization’s direction. Unfortunately, the amount of effort is often misunderstood or put aside for bandage solutions. No matter the circumstance strategic business analysis, planning and implementation is important to the success of any organization. Good luck.

Projects Tend to be Described in Terms of Solutions

Written by Kent McDonald on October 4, 2016. Posted in Articles. 1 Comment on Projects Tend to be Described in Terms of Solutions

In my last article 5 Things I Wish I’d Known When I Started As A Business Analyst I said I wished that I knew that projects are often described in terms of solutions.

I actually realized this fairly quickly, but it didn’t occur to me to do something about it until a couple of years into my business analyst career.

I thought I was set when I started on a new project and was given a solution that just needed the specifics filled in. It was only after working on a few projects that I began to realize things were not as clear cut as they sometimes seem. I didn’t realize that people have a tendency to hang on to the first solution they think of when they face a problem and fail to question whether that first solution is the best one. As a result, when sponsors are asked to describe a project they inevitably describe that first solution they came up with.

One of your primary responsibilities as a business analyst is to dig into that solution and discover the underlying need. I’ve found a simple approach to accomplish this is to guide a conversation with the sponsor of the project and the team working on it around a problem statement.

Explicitly Discuss the Problem

I was working with a team in the middle of a commission system revision project. There were 11 people involved, including the sponsor, a couple of subject matter experts, and the majority of the delivery team. I wanted to get a better understanding of what the project was all about, and I wanted to find out if the team had a shared understanding of why they were doing the project.

I asked everyone to grab four index cards and a marker.

On the first card, I asked each person to finish this phrase: The problem of… [Describe the problem]

On the second card, I asked each person to finish this phrase: affects… [Who are the stakeholders affected by the problem]

On the third card, I asked each person to finish this phrase: the impact of which is… [What is the impact of the problem]

On the fourth card, I asked each person to finish this phrase: A successful solution would… [List the key characteristics that the solution, however implemented must have to be successful]

One set of cards looked like this:

The problem of: completing the monthly commission process in a timely manner affects: agents, commissions staff

The impact of which is: there is a delay for agents to get paid, commissions staff are constantly harassed by agents right at the time when they are the busiest (running the commissions process)

A successful solution would: speed up the commission process, decrease the number of times agents bother commissions staff

The team member actually states a problem, but then identifies multiple stakeholders who are affected, multiple impacts, and multiple characteristics of a good solution. That’s ok because you are primarily trying to generate information at this point.

Once everyone wrote their cards, I asked each team member to read their statement in order and place their cards on four parts of a table, each part corresponding to a section of the problem statement. If you are using sticky notes, you can have people put the sticky notes on four separate sheets of paper hanging on a wall.

When I had the group build their individual problem statements we ended up with 11 different perceptions of what the project was about, ranging from making some changes to the commission system to make it easier to maintain, to completely overhauling how the organization paid its agents. Needless to say, the team was a bit surprised about the differences in perspectives considering that the project had been underway for a few months. Everyone just assumed that they were “all on the same page” regarding what the project was all about until they did this exercise.

We had already gained value from the exercise because it exposed the disconnect between the group on the real need the project was trying to satisfy. We still needed to take the disparate items and condense them together into a single, consistent, agreed upon statement. I had the group start at the “The problem of” set of cards and agree upon a specific problem. Once the team came to an agreement on the problem, and only then, I had them move to the next the set of cards and repeat the process.

The end result was a consistent statement they all agreed to and could use as a guide to refer to when they were trying to remember, or fill someone else in on, what the project was all about. I didn’t keep track of what the actual statement was – the most important outcome of the exercise was the shared understanding between the team members.

That said, the output from the exercise was useful. The stakeholders identified in the “affects” group provided a hint at whose needs you want to satisfy. The “Impact of” identifies specific things you can look to eliminate, and the “characteristics of a successful solution” hint at potential acceptance criteria.

By working through each of the different portions of the problem statement, we were able to converge to a shared understanding of the purpose of the project. Later, the team members were able to use this as one way of deciding what they should and shouldn’t focus on.

Things to Consider

I did this exercise after the team had already started the project because that’s when I started working with them. Ideally, you’d like to have this conversation when the team is finding out about a new project. I’ve started a project with this conversation several times and found the teams are much better aligned with what they are trying to accomplish from the beginning.

The discussions that occur when formulating a consistent problem statement can also help the team focus. When your team crafts individual problem statements and then looks at all the pieces together, you identify several different problems, stakeholders, impacts, and characteristics of a successful solution. The discussions that occur in the effort to go from many problem statements to one raises issues, risks, and assumptions that everyone on the team may not have been aware of. Talking through those issues, risks, and assumptions helps your team build a shared understanding of the problem to solve and things to consider when picking the appropriate solution.

That’s just one approach I’ve used to extract a problem from a solution. I’m curious to hear what techniques you’ve found useful when you are in the same situation. Please share them in the comments.

Lean Business Analysis: More About Decision Making

Written by Kupe Kupersmith on September 22, 2016. Posted in Articles.

There are many discussions, theories, and great debates over different kinds of BAs.

There are people that perform business analysis in IT environments; there are ones that are not in IT environments. There are process BAs, waterfall BAs, agile BAs, data BAs, and teams that have multiple people doing analysis. Regardless of when and where team members perform business analysis, they need to perform lean business analysis. To explain what “Lean Business Analysis” is, let’s look at the definition of Lean. From the Lean Enterprise Institute, Lean is defined as such, “The core idea is to maximize customer value while minimizing waste. Simply, lean means creating more value for customers with fewer resources.” So, I define Lean Business Analysis as creating more value for customers with fewer resources.

How do you accomplish this? Some may say you do it by spreading the BA work to other team members therefore eliminating a person on the team. The problem with that solution is it only addresses half of the definition…with fewer resources. You need a solution that completes both halves…more value for the customer and fewer resources. This brings me back to my old friend, Decision Making.

I have written about Decision Making before in the following posts, Decision Making: An Underlying Competency or What A Business Analyst Does and It’s All About Decision Making. If you think about business analysis as the activities done to help others make decisions, you have started on your path to Lean Business Analysis. By first looking at your project as a series of decisions, you can then determine what just enough analysis is for each decision. When a decision is made, you are done and can move to the next one. For example, one key decision is what problem are we trying to address. Another can be prioritizing features or user stories. Another is a developer determining how to best design a solution.

There are three key components to decision making that I want to highlight.

You need to define all the decisions to be made.
You need to know who the decision maker is for each decision. This may be one person; it may be many.
You need to know the criteria, or information, the decision maker(s) will use to make the decision.

Knowing the criteria, each decision maker has for each decision to be made is how you determine what information you need to elicit, analyze, and communicate. Once the decision is made, stop analyzing. Once a decision is made you have done enough analysis. Then you have created value for a customer and did it with the right amount of resources.

There is more on this process in my previous blogs, so I won’t repeat myself here. I do want to address a consistent concern I hear about this approach. When I talk about this with people over coffee, during or after a seminar or workshop there is a consistent pushback. “What if bad decisions keep getting made?” It’s a great point. You need to facilitate good decision making! My first response is the process needs to include decision evaluation points to make sure the decisions being made are helping your team meet the overall objectives of the initiative. The other thing is you need to help your customers avoid the four villains of decision making.

In their book, Decisive, Chip and Dan Heath, describe the 4 villains as:

Narrow framing
Confirmation bias
Short-term emotion
Overconfidence in the future

For this post, I want to cover the first two because they focus on how you present or communicate information to decision makers.

Narrow framing is the belief that you have two choices. Either you go out dinner, or you stay in. Do you take a job or not take it? Do we implement a project to go after an opportunity or not? You either do it “this” way or “that” way. There is no in between. People often talk about creativity in business analysis. By expanding the frame and looking at multiple alternatives is a way to get creative. Make sure you provide the decision makers with more than a this or that option. A way to check yourself is looking at the information you are presenting and seeing if one option looks like it really leaves the decision maker with no other choice then choosing the other option.

The second is confirmation bias. This is when you are evaluating options. Many people lean towards gathering information or listening to information that supports their view. Have you ever had a person come to you with the solution they wanted to be implemented? I know, silly question. People have ideas, thoughts and even look for information to help them make a decision. That information just happens to support their belief. The rest of the project team including you fall into the trap of confirmation bias. You are on the project you want it to succeed. It is a hard villain to combat.
One way to help combat this confirmation bias is to find a Red Team. A Red Team’s job is to poke holes in your thinking and/or your decision. They are used by the CIA, Army, news organizations, and businesses around the world. In our environment, we say stakeholders for a project are those impacted or can impact your project. A Red Team is a group of people that don’t have a stake in the project. They have no emotional connection. They have nothing to win or lose by your project. Your Red Team needs to poke holes in your logic and ensure you avoid confirmation bias.
The decision-making process is how you can do just enough business analysis or perform lean business analysis. Try it today and share your stories here!

All the best,

Kupe

Your Job Is Not to Elicit and Document Requirements

Written by Kent McDonald on September 14, 2016. Posted in Articles. 1 Comment on Your Job Is Not to Elicit and Document Requirements

In my last article, 5 Things I Wish I’d Known When I started As A Business Analyst I said I wish I knew is that my job was not to elicit and document requirements when I first started out.

Why did I say that? It comes down to the difference between outcome and output.

What is the Difference between Outcome and Output?

Before I go much further, I should probably explain what I mean when I use the words outcome and output in a context relevant to business analysts:

Outcome is the change in the organization and changes in the behavior of stakeholders as a result of a project.

Output is anything that your team delivers as part of your project. This could include requirements, documentation, processes, software, tests and other things that tend to be measured in order to gauge how the project is going.

The goal of every well-defined project is not to produce output; it’s to reach a specific outcome. A successful project seeks to maximize outcome with minimal output. Why do you want to do that? Well, you want to get as close to desired change in your organization and your stakeholders’ behavior with the least amount of initial and ongoing work as possible.

Requirements are (not the final) Output

To look at it another way, satisfying the needs of your stakeholders is the outcome you seek, and the solution you deliver to satisfy those needs is the output you use to reach your desired outcome. Requirements are outputs in that process, but they aren’t the final output that drives the desired outcome. They tend to be an interim output on the way to getting to the solution.

When you view the purpose of analysis as eliciting and documenting requirements you most likely have a couple of assumptions: 1) the best way to reduce uncertainty about the solution is to write everything down at the beginning of the project and 2) it’s possible to know what those things are. Those two assumptions generally end up false, so I’d rather work according to this assumption: we’re better off creating a shared understanding of the problem we’re trying to solve first, and let the specifics of the solution emerge as we get things underway and learn more about the problem space.

Changing those assumptions means looking at analysis as problem-solving and building shared understanding. Along with that comes a substantial change in how your team views requirements and designs. They are no longer deliverables that get tossed over the wall to the people performing the next step in the process. Now both requirements and designs are tools that teams can use to build a shared understanding of the solution they seek to deliver in order to reach the desired outcome.

How do you focus more on Outcome than Output?

Here’s a recent experience that shows how to maximize outcome while minimizing output.

For a little over a year, I’ve been the product owner for the initiative to revise the Agile Alliance website, membership and conference registration systems. When it came time to do a deep dive into the membership aspects of the system, I took it upon myself to write up all the specifics about membership – what information we wanted to track about members, what rules were relevant, and what types of memberships we had. It was a fairly short, yet comprehensive set of requirements. I was admittedly quite happy with them.

I was happy with them until the delivery team started developing functionality and they didn’t seem to pay much attention to the requirements. At first, I was perplexed, did I not clearly tell the team where the requirements were? Then I was irritated. Why weren’t they paying any attention to them?

Then it occurred to me that what I had done wrong was that I had focused on the requirements as an output, without considering how it contributed to our desired outcome, to increase membership. I didn’t talk with the delivery team to find out what was the best way to share information with them along the way as they built the various aspects of the membership functionality. We didn’t have conversations as we went along to specifically point out the relevant rules and pieces of information for the specific backlog item that they were working on at the time.

Once I came to that realization, we changed how we communicated. We still used the rules and data element information, but we used them more as reference points in the frequent conversations we had. We also started using examples on a more regular basis to talk through the specifics of a given backlog item. We found that me simply writing those examples down was not sufficient. In many cases the real advantage was through talking through them as the delivery team was getting started on a backlog item.

Lessons Learned

I should have known better to start the way we did. I realized it is easy to forget good practices when you’re in the midst of a project and the pressure is on. Here are some of those good practices I hope you don’t forget when you run into the same situation:

Take time to talk with your team about how you want to work, and the best way to communicate information in order to build and maintain a shared understanding. When you have those discussions, don’t be afraid to suggest approaches that your team is not familiar with if they are applicable for your project.
Document requirements collaboratively during your discussions with the team to build and maintain a shared understanding.
Stop thinking of analysis in terms of gathering and capturing requirements and instead think of it as solving problems and building a shared understanding.

I hope this story gives you some ideas on to focus on outcome over output. I’d love to hear some of your stories on how you’ve focused more on the outcome while minimizing your output.