Tag: Business Analysis

The 4 Chords of Great Business Analysts

Written by Kupe Kupersmith on February 23, 2016. Posted in Articles.

In our professional community, there is so much confusion or different perspectives on what analysis is and what makes someone a great business analyst. With so many different descriptions of the role, it is difficult to look at job descriptions to get the answer.

I talk to a lot of people, attend conferences, and hear thought leaders in our profession talk, and get to observe people doing analysis work. For this post I want to share what I feel are qualities that the best of the best in our field have.

How I will describe these qualities is based on a great video demonstrating how just 4 chords are used in many popular songs. Check out this funny video by Axis of Awesome to hear all these well-known songs using the same 4 chords. It is all clear to me now why so many songs sound the same.

So, in a not so quite Axis of Awesome way, I came up with a list of the 4 “chords” all great analysts have.

Why do so many great business analysis professionals “sound” the same to me? Here they are:

1. Empathy

The best business analysts have a wave of empathy flowing through them. The way they listen in order to understand. The stakeholders they work with say things like “you really understand my situation. You get my group and me.”

Looking through an empathetic lens they yearn to see how a solution impacts the people, processes, the organization as a whole, and technical impacts.

When people buy a new car, why do they all of sudden see the same car on the road? When someone ends a relationship why does every song on the radio remind them of their lost love and bring them to tears? It’s because it is what is on top of their mind, what they are focused on. A good analyst understands this. They do not assume because everyone says they understand something that that means everyone has the same interpretation.

There are two things going on here. First, the good analyst cares about all the impacted stakeholder groups. They want different perspectives to gain a holistic view. They understand there is a customer, the business, and a technology view to everything. This aids in fully analyzing the situation so that the right problem or opportunity is being addressed and that the solution is desirable. Secondly, they always have their eye on the bigger picture. They want to avoid situations that may create a scenario where solving one problem leads to another problem for a different group.

Related Article: The iTunes Impact on Requirements Analsyis

2. Yearning for learning

Great analysts always want to learn. They never stop. A great analyst will never be perceived as a know-it-all. They will be confident in their skills yet humble. They attend webinars, read books, got to training classes, conferences and love reading blogs like this! They are always searching for new techniques or different ways to use old ones. And when it comes to their process of their teams, they are always analyzing what can be improved.

3. Politely Challenging

This one is easier explained by saying what they are not. They are not note-takers. They are analytical and critical thinkers that search for the facts. They have multiple ways to “roll back” stakeholders to understand the real problem/opportunity that needs to be addressed. They don’t push forward without first making sure there is a shared understanding by the team why a solution was asked to be implemented.

They highlight the elephant in the room. You can sit in a meeting and watch how they gracefully expose the “elephant” to make sure no underlying issue has time to fester. They know it is not about individuals as much it is about results.

That description may sound like a great analyst is a little rough around the edges. A strong person not to be messed with. Actually, they are quite the opposite. They are people everyone wants on their team. They find ways not to put people on the defense. They bring teams along on a journey to uncover the real problem.

{module ad 300×100 Large mobile}

They also know when to move to solutioning when teams are getting stuck. I think sometimes there is almost a black and white view as it relates to problems/opportunities and solutions. There is a view of no solutioning until we are all on the same page of the problem or opportunity. This assumes it’s a simple task to get everyone on the same page related to the problem or opportunity. That is not always the case. Instead of getting stuck in analysis paralysis a great analyst will start down the solutioning path to test a hypothesis and see if they can figure out the problem that way.

4. Value networking

All great business analysts have a knack, a desire, and an understanding of the importance of connecting. Why is connecting with as many individuals important? In this profession you are not paid for what you know, you are paid for who you know and how to find the information. So many people want to find ways to negotiate better, influence better, and get time with the right people to do their job. The way to do it is by building trusting relationships.

How often do you go out and connect with people in and out of your organization? How many new people do you meet a week? How many relationships do you foster in a week? Do you even think of this?

In today’s environment we need to move quickly. When you are working on an initiative, you need to know who the go-to people are. You need to be able to access to them. Just think about your day. You most likely don’t have enough time to do everything you need to do. You don’t have enough time to meet with everyone that needs to meet with you. How do you prioritize who you will talk with? Most likely one factor is people you have a relationship with already.

I’ll end my post now so you can go meet some new people!

All the best,

Kupe

How Can You be a Business Analyst without Knowing the ____?

Written by Yaaqub (Yamo) Mohamed on February 22, 2016. Posted in Articles. 1 Comment on How Can You be a Business Analyst without Knowing the ____?

This is one of my favorite questions to ask whenever I get a chance to talk to a group of business analysts, be it a study group, class or during a presentation.

After I run through a whole bunch of jargon, best practices and, in some instances, inter-relationships between the different business analysis knowledge areas from the BABOK®, I tell them, “So, I have a simple question to ask you all.” It usually is rephrased as:

What do you absolutely need to know to be a business analyst?

At a fundamental level, what makes a business analyst good, or even great?

What do they need to know well to excel in performing effective analysis?

What is the ‘oomph’ factor that’ll starkly distinguish how a business analyst recommends one solution or approach over another?

After some fast thinking on their feet, I usually get the following responses (with smug smiley faces and brightly lit eyes):

The methodology of the organization?

I utter ‘no’ immediately.

BA Techniques?

I smile and say no.

BABOK®?

I raise my eyebrows and say no.

At this point, I make this a simple fill-in-the-blank question and ask them to amp up the thinking up a notch.

How can you be a BA without knowing the ________?

I get the sponsor, organizational structure, enterprise architecture, domain knowledge (I echo “kinda”), etc.

After dropping my shoulders in a bit of disappointment, I proceed to complete the sentence. (Please don’t expect a magical potion answer here!)

How can you be a BA without knowing the BUSINESS?

{module ad 300×100 Large mobile}

Duh!? Apparently, this is not distilled wisdom extracted after meditating under the supreme BA knowledge tree in the Himalayas.

So, why and how is it important to you as an analyst to know the business well?

How can you learn the “business” better?

In this post, I’ll provide some insight on why this is so essential, even though it’s so simple.

Let’s start with a quote from a great man, Leonardo da Vinci.

“Simplicity is the ultimate sophistication.”

Let’s explore the ‘why’ first.

Here are the three reasons why knowing the ‘Business’ is necessary for you to be an excellent business analyst.

Knowing the ‘Business’ is Your Business

As a business analyst, you’re entrusted to know how an organization functions in the complex web of people, processes, tools, and technology. A Systems thinking hat is essential and something to be used at all times. Let’s examine the definition of a business analyst based on BABOK® V3:

“Business analysts are responsible for discovering, synthesizing, and analyzing information from a variety of sources within an enterprise, including tools, processes, documentation, and stakeholders. The business analyst is responsible for eliciting the actual needs of stakeholders—which frequently involves investigating and clarifying their expressed desires—to determine underlying issues and causes.”

The responsibility of knowing the ‘business’ is assumed in this definition. This is essentially the glue that holds all of the discovering, synthesizing and analyzing together. If I had to define what it means to know the ‘business’ to be a better BA, I would define it as follows:

“Having superior knowledge of the inner workings of the business (or a business unit), the value propositions (products & services) that are supported, along with how different components interact with one another to create positive outcomes for the business and its key stakeholders. The components could include, industry positioning of the organization, business processes, customer segments, revenue streams, key stakeholder interactions, current challenges, constraints, and opportunities.”

This is the Secret Sauce of Going from Good to Great

After sitting through hundreds of requirements review sessions and JAD sessions, I have seen a pattern of what contributes to excellent analysis. If someone is conducting a requirements discovery session to map out the As-Is process flow, the quality of questions depends on how well they have prepared for elicitation and how well they understand the underpinnings of the process or inner workings of the organizational unit.

Knowing how a department works from end to end, even if it’s peripheral to your area of analysis, can significantly enhance your analysis outcome. It can improve the quality of your questions and thereby create better deliverables.

Pause and Self-Reflect for a Moment

I’d like you to think back and reflect on your journey as a business analyst and evaluate how you were able to perform better analysis if you had a better understanding of what you were dealing with. Did knowing how one department hands off work to another help you ask better questions? Were you more stoked when you understood and were able to trace EXACTLY how your work would or could improve the lives of over a thousand sales reps across the country? Were you able to create better process flows for an update of live software that you were involved with initially? If you can find at least one example of this from your experience, the simplicity, and importance of knowing the ‘business’ will resonate with you.

Now, let me leave you with three simple and effective tips that will help you learn the ‘business’ better.

‘No Curiosity’ Killed the BA

Be curious about the project that you get on. Ask to job shadow a business user and ask them what value their department brings to the organization. Obtain possession of user manuals or policies and procedures library to understand how their unit operates. Aim to become an expert in the realm of your analysis, because you can’t give expert advice without being an expert. As an analyst, you must be galvanized with the prospect of knowing the constituent parts of the organization or a department and learning how it all comes together both at the micro and macro level.

Understand the Business Model Canvas for this Business

Another great way to look at an organization is to see it through the lens of Business Model Canvas – a tool to map, discuss, design and invent new business models. You can start by reading this Wikipedia article on ‘Business Model Canvas’ and watching the following two-minute video:

https://youtu.be/QoAOzMTLP5s

There is also a blank template that you could download and use for mapping out the canvas for the organization that you’re working in. Additionally, you can also zoom in a little bit and create one even for an organizational unit.

Zoom Out and In

In my first book, The Five Pillars of a Great Business Analyst, I underscore the importance of recursive systems thinking. If systems thinking is about having a big picture view of your analysis in the context of the domain, recursive systems thinking is having multiple big picture snapshots, and zooming out each time until you see how it all ties into the overall business. As you go through the analysis of a piece of a problem domain, think of what people are involved, what processes have an impact on their work and workflows, and what systems they use including IT and Non-IT. Repeat this process by zooming out to relate it to the next level up in the organization until you’re able to understand how this aligns with the overall objectives and value propositions offered by the organization (e.g. how a change in billing system to enable online statements impacts the billing department, and then to sales and marketing department and then how it affects the organization’s overall objective to go green).

I wish you luck with your ‘business’!

Please use the space below to provide further comments or questions on the theme of ‘knowing the business’ or to provide more suggestions of how to learn the ‘business’ better.

A Day in the Life of a Business Analyst

Written by Vaishnavi Agrawal on February 16, 2016. Posted in Articles. 2 Comments on A Day in the Life of a Business Analyst

Business Analysis is the responsibility of knowing when a business’s needs change, assessing the business impact of those changes, obtaining, examining and recording requirements, and maintaining the communication and delivery of the requirements to relevant stakeholders.

Being a Business Analyst is a little like being an architect. Instead of producing plans, the Business Analyst provides requirements which clearly state the business needs and align with business processes. The requirements are then used by the team or an external supplier to build or modify the product.

A typical day may look like this:

The Business Analyst arrives in the office with a goal in mind of what they expect to accomplish that day. This plan may include spending greater than 50% of the time in meetings or workshops where they will be gathering information or seeking agreement on the contents of the project artifacts that they produce. The rest of the time, they will be performing original review, crunching through spreadsheets of data and traceability patterns, analyzing or writing documentation or working out the optimum way to define a particular need, requirement or process.

A Business Analyst’s everyday work duties can vary considerably, depending on the variety of the current business and project. Despite this, there are some activities that the Business Analyst will usually do in the plan of every project.

They include:

Investigating goals and issues
Analyzing information
Communicating with a broad range of people
Documenting findings
Evaluating solutions
Implementation

For an assigned project, the Business Analyst will regularly try to define and supervise a sequence of carefully structured assignments aimed at obtaining the common goals of review, constructing, planning, and evaluation. Of course, these functions are bound to require a flexible approach matching the circumstances.

Let’s have a look at the responsibilities based on the project phase:

1. Investigating Goals and Issues

Business Analysts spend a great deal of time asking questions. To explain the project and feasible clarifications, a BA might conduct interviews, read, and observe work in progress. Business Analysts do analysis and look for solution alternatives, both inside and outside the organization.

2. Analyzing Information

The analysis phase is the phase during which the Business Analyst explains the elements in detail, affirming clearly and unambiguously what the business needs to do in order solve its issue.

During this stage the BA will also interact with the development team and, if appropriate, an architect, to design the layout and define accurately what the solution should look like.

3. Communicating with a Broad Range of People

Good Business Analysts contribute countless hours actively communicating. More than only speaking, this means hearing and recognizing verbal and non-verbal information, building an open conversation, verifying you’ve understood what you heard, and communicating what you learn to those who will create the actual solution.

4. Documenting Findings

Business Analysts spend a decent amount of time recording what they learn and observe, and recording the results of their analysis.

During this phase, the Business Analyst should consider the best ways to record particular kinds of information, either in text or visual form, i.e., charts, graphs, illustrations, etc.

5. Evaluating Solutions

A Business Analyst must also spend time identifying options for solving particular difficulties, then help choose the best one. The preferred solution is then estimated throughout the layout and planning to assure that it meets the business requirements.

6. Implementation

The implementation phase is not the conclusion for the Business Analyst. It’s the riskiest time for things to go amiss and for objectives to be missed. It’s during this stage a BA should be aware of how clients are utilizing the framework.

Do they see the benefits envisaged in the business case? Do the training materials support the business case?

In essence, a Business Analyst is a navigator, responsible for reaching the end destination, which means a satisfying resolution of a business problem. The BA always knows what the end destination is, how to get there and is capable of handling course adjustments as they arise.

Business Analysis Profession on its Path to Maturity

Written by Aaron Whittenberger on February 16, 2016. Posted in Articles.

Often at the beginning of a new year, many people like to reflect upon the prior year and make plans for the upcoming year. Not only people but organizations often take on these activities of measuring the success of the past and making strategic plans for the future. A component of strategic planning is to recognize trends in the industry and to leverage those trends to the organization’s sustainability.

Since 2009, the folks at Watermark Learning have looked at the trends in business analysis and project management. Read here to see their latest reflections. In 2013, the Senior Leadership Team of the International Institute of Business Analysis (IIBA®) reflected upon predictions in the profession of 2011 and then looked at what the profession may look like in 2016. Read more here to see how they did.

Not to be outdone, two years ago I threw my hat into the ring. There were some very definite trends that were in their infancy in 2014 that prompted me to recognize them. You can read what I felt was just beginning back then and see how those areas have grown and affected the business analysis profession.

So if you have read both articles who would you say is better at predicting the future, Julian Sammy or me?

I won’t go through the ten trends I identified two years ago and see how far they have come in two years. I will leave that to your assessment. However, much of the same trends from back then I would reiterate again this year—Agile, Collaboration, Product Vision, Strategy, Training, Abundance of business analysis jobs and Business Analysis Centers of Excellence.
As some of these trends continue to be identified year after year by the folks at Watermark Learning, IIBA and myself, it just goes to show that these trends continue to grow and affect the business analysis profession. As I said two years ago “Agile is here to stay.” It is not only here to stay, but it also continues to grow. It may continue to face its challenges of organizations adopting the Agile approach, but we will increasingly see organizations that previously “tried” Agile find more methodical ways to adopt the principals. This should see an increased demand for Agile coaches, certified Scrum Masters, and product owners.

Instead of reiterating these trends and possibly adding a couple to the list. I want to do what any good business analyst does and get to the root cause of the intertwining fabric of these trends.

Business Analysts Work Feverishly to Deliver Value to the Organization

Value is a concept mentioned in this year’s trends identified by the folks at Watermark Learning. It is also the intertwining concept I noticed that many of the presentations from this past Building Business Capability Conference, the official conference of the IIBA. Whether the discussion topic was Business Architecture, Business Relationship Management, Collaboration, Organizational Change, Strategy, Critical Thinking or Agile; each presentation drove back to delivering value to the organization.

IT Business Analysts, or Business Systems Analysts, will need to be innovative to find new ways and new partners with which to collaborate to deliver faster and ensure solutions that deliver greater value to the organization. Even if not adopting Agile principals, IT Business Analysts will find innovative ways to show agility in their work.

{module ad 300×100 Large mobile}

Business Process Analysts will also be innovative in their models they use to help all stakeholders understand business processes and impact of proposed changes to those processes.
Business Intelligence Analysts will work to make data more predictive and prescriptive to deliver greater value to the organization. They will find new tools to make their use and interpretation of data more innovative.

Organizations will utilize business architecture so that key decision makers within the organization can understand the business and all its components, products, and services. Business architectures will become more complete and utilize multiple views and models to aid in that understanding.

Enterprise-level business analysis practice will aid Business Analysts, in whatever role, within the organization become more agile and deliver value to the organization. Delivering value will become a key objective of Business Analysis Centers of Excellences (BACoE) and Enterprise level business analysis practices. This trend I mentioned two years ago may be slower in developing than some of the others, but it will receive refined focus in upcoming years that will aide its maturity.

The International Institute of Business Analysis will continue to support the profession and the global business analysis community. New products and services will be introduced to this end. IIBA has announced that they will revamp their certification program to a multi-level competency-based program; recognizing practitioners at progressive stages of their business analysis career. This new certification program is slated to be launched in September of this year.

Recently, IIBA announced a new Enterprise Business Analysis Core Competency Assessment Framework (EBACC) to aid organizations to assess the maturity of their business analysis practice. Then new tools, products, and services will be introduced to help mature that practice at the enterprise level. This new focus on the enterprise level will cause an increase in BACoEs.

In 2014, the IIBA was just over ten years old, and the business analysis profession was in its infancy. Two years later it might have grown to its toddler stage. Certainly in comparison with PMI, at 46 years old and ASQ at 65 years old, you can certainly see that the business analysis profession is just starting out, but in its young life, it has made some great advances. I can’t wait to see where it goes in the next ten years.

Why Everyone Needs a Business Analyst on the Project

Written by Brad Egeland on December 29, 2015. Posted in Articles. 9 Comments on Why Everyone Needs a Business Analyst on the Project

I’m a Project Manager and a consultant. I’ve never been a Business Analyst. I’ve been an Application Developer, but never a Business Analyst.

I’ve helped the Business Analyst do their job on many of my projects and the BA is usually the one that I work most closely with on the projects that I manage. But I’ve never had sole responsibility for the business analyst function on a project. And I truly believe that my project management success rate can be directly tied to working with some great, experienced Business Analysts on some of my most technical and complex projects. There is no substitute, in my opinion. I will sing their praises from the rooftops.

Why does everyone need a Business Analyst on their project? That may be a bit of an overstatement…there are those smaller and less complex projects where a Project Manager or Business aAnalyst can likely cover both roles. But for longer term, higher profile and more technically complex projects, I strongly suggest that both roles are absolutely necessary. I am going to present my own five-point argument here as to why that is the case. I welcome your thoughts and input and discussion to either support or refute this concept.

Here are my five reasons why every (most?) projects – at least complex, technical ones – need a Business Analyst:

1. The Project Manager needs to focus on the project management tasks.

There are enough administrative tasks on most projects to justify a full-time Project Manager, in my opinion. This is especially true for longer, more complex technical projects. In recent years, I can’t imagine not having a Business Analyst assigned to most of the projects I’ve run as they have often tended to be at least 6-12 months long and worth around $1 million with fairly complex technical solutions, interfaces, and implementations. Asking a Project Manager to cover both roles is asking too much because managing a project like that – depending on the customer’s needs and complexity of the project – can be a full-time job.

2. The Tech Lead needs a good liaison heading into design work on the project.

On most technical projects of any degree of complexity, the project can benefit greatly from having that good liaison between the administrative and customer side of the project and the technical development side. Having the BA in place to help translate those business requirements into functional requirements with and for the Tech Lead on the project is of tremendous value and helps keep that planning portion of the project under control in terms of time and dollars. It can often definitely be money well spent on the Business Analyst position. If it isn’t spent on that position on complex, technical projects, then it likely will be spent on a longer planning and design portion of the project.

3. The Customer needs a technical interface to create complete, detailed requirements.

Customers rarely come to the project table with detailed requirements and if they think that’s what they have then those requirements need to be questioned heavily. To get to usable, detailed, complete requirements is no small effort and the Business Analyst provides the best means of getting the project to the point of that detailed requirements definition. On most complex tech projects, it’s going to be impossible for the Project Manager to be the sole facilitator of that process.

4. A Business Analyst provides key assistance with user acceptance testing (UAT).

User acceptance testing is critical to the project’s success. So much so that the UAT signoff is almost like a signoff on the entire project. But so many UATs can and do go poorly as many project clients lack the time, experience, and expertise to dutifully prepare for and conduct proper user acceptance testing. While the delivery organization can’t do the testing for them, a good, experienced BA – sometimes along with the Tech Lead’s and/or Project Manager’s help – can show them how to prepare properly and conduct UAT by assisting the customer with test cases and test scenarios. This way both sides can be certain that the solution has been fully and properly tested prior to signoff and that the end solution is nearly certain of meeting the customer’s end user needs upon rollout.

5. Business analysts provide critical oversight at project implementation time.

Is the project complete? Is it really ready for roll-out? Probably, but have you gone through a project checklist to ensure that is the case? Have you reviewed the project schedule to ensure all tasks are complete, that all sign-offs and approvals have been obtained along the way, and all documentation is there to prove it? The Business Analyst – if you have one – has been involved in many of the key deliverables and heavily involved in requirements, functional design, reviews, user acceptance testing, and other testing as the solution moves toward implementation. When the time does come for go-live, the Business Analyst can likely be the best interface with the project client – working closely with the Project Manager and the tech team to ensure the solution is rolled out smoothly to the customer and end users, that training needs have been identified and addressed and that the proper handoff to support has been achieved.

Summary / call for input

I’m a better Project Manager with a Business Analyst on board for the project. Likewise, my projects are better equipped for success when I’m not splitting myself too thin as both the Project Manager and Business Analyst. I realize that it is a luxury to accommodate both roles on the project as it can be a matter of budget, complexity and customer agreement. Both roles need to be funded. I still stand by the notion that every project is better off if you can have both roles filled separately, even if the Business Analyst or Project Manager role is very limited in terms of hours, dollars, and involvement. Better to have a few hours here and there as needed as opposed to none. So, if you can’t price both in full time, then price one in part time and strategically use those hours wisely where they are most needed – like early planning and design and then again around user acceptance testing where business analyst involvement can really help that often customer-challenged phase of the project go much more smoothly.

Readers – what are your thoughts? How necessary do you see both roles as being on the projects in your organization? How often does on or the other role cover both position on a project? Please share and discuss.