Skip to main content

Tag: Business Analysis

Why You Don’t Need A Certification to be An Effective Business Analyst

A recurring conversation in the business analysis community is whether you should get a certification and if so which one(s) you should get

. The arguments for why you should get a certification tends to be some combination of these three ideas:

  • Studying for a certification helps you learn a lot about business analysis.
  • Acquiring a certification shows that you are dedicated to business analysis.
  • Certifications are useful filters in hiring or promotion decisions.

Certifications aren’t all they are cracked up to be, and most of the arguments for them are based on questionable assumptions. I’d like to look at these three arguments and suggest some different perspectives. As a result, you’ll see that while certifications may have their place they are neither necessary nor sufficient, to ensure that you will be an effective business analyst.

Is Studying for a certification (test) the best way to learn?

A common question I see from people new to business analysis is “I want to become a business analyst, what certification should I get?” There’s an assumption underlying this question that a certification is the best way to break into the field of business analysis.

A better question to ask is how I can learn business analysis?

My answer, born out of my experience, is to find ways to start practicing it in your current situation. You don’t have to have the title business analyst to start using the techniques, and while studying for a test may be one way to learn information, it’s probably not the best. Stop and think about how much you remember from your high school geometry class. I’m willing to bet unless you use geometry on a regular basis, you don’t remember that much. And therein lies the difficulty in the argument that studying for a certification test is going to help you to learn and retain knowledge about business analysis on an ongoing basis.

You can organize learning into two forms: Just in Time, and Just in Case. Studying for a test is the classic example of Just in Case learning. You learn some piece of information just in case you’ll need to know that information sometime in the distant future, and you hope you can recall it.

Except you rarely do.

Just in Time learning is when you come across a specific situation and dig deep into a subject at that point because it’s immediately relevant.

Both forms of learning are helpful and require different depths of exploration. The “Just in Case” is good to build awareness that a concept exists, but there’s no point in digging too deep into that topic. If you aren’t going to use it, you aren’t going to remember it. You then switch to Just in Time learning when that topic becomes relevant.

Studying for certification exams requires you to do deep dives on topics that you may never use in your actual work. You study enough to pass the test, then immediately forget it. Sure, you get the benefit of being aware of the concept, but you also end up wasting an awful lot of time and brain cycles remembering this information, potentially useless in your given situation, to pass a test.

A better use of time is getting very effective at Just in Time learning when the need arises, mixed in with Just in Case learning at a very high level.

The best way to learn something is to use it or try to teach it someone else. In my post How to Learn New Techniques, I describe The Feynman Technique which describes how you can go about learning thoroughly by teaching it to someone else.

Do you have to have a certification to show dedication?

When people acquire a certification, they are showing dedication to something – their career. There’s absolutely nothing wrong with that, but don’t confuse taking steps to advance your own career (I talk more about that below) with showing dedication to an entire profession.

Yes, many people who get certified are also heavily involved in the professional community. I’d be hard pressed to show a causal relationship between acquiring a certification and professional involvement.

There are also just as many people who aren’t certified who are also involved in a professional community and are dedicated to their careers and the profession. I’d count myself in this group.

You show dedication to business analysis when you help out with IIBA or a similar professional association at the local, national, or international level.

You show dedication to business analysis when you share your successes and your lessons learned, either via speaking or writing.

You show dedication to business analysis when you help those who are trying to start practicing business analysis.

You show dedication to your profession when you apply business analysis practices to help your team and your organization be more effective.

To paraphrase Marcus Aurelius, a famous stoic and Roman emperor: Waste no more time arguing what a good Business Analyst should be. Be one.

Are Certifications a Good Filter for Hiring and Promotion decisions?

When organizations use certifications as a filter for hiring decisions there’s an implication that certifications indicate how well you can do the given thing that you are certified in. They don’t. What the certifications do show is that someone met the requirements of the certification which in most cases are not tied to ability.

Several organizations also expect that consultants or contractors they bring in have a certification in a specific framework they would like to implement. Those organizations have bought into the same line of thinking that organizations that use certifications for hiring decisions have accepted. It’s as unreliable in the case of consultants as it is for full-time employees.

Many organizations require their employees to get a certification within a certain time, give raises, or promotions to those that do. Their reason for doing that is generally one or both reasons I described above.

While I don’t agree with the reasons, many organizations have chosen to tie hiring or promotion decisions to whether you have a certification. The pragmatist in me advises you if there is a job out there that you’re interested in and it requires a certification, then it’s probably worth it to get the certification. If your current employer gives people raises or promotions when they get a certification, then it’s probably worth it to get the certification. Just be honest with yourself as to why you’re getting the certification.

A Pragmatic View of Certifications.

I have chosen to learn business analysis by practicing it and helping others learn it. I’ve shown my dedication to business analysis through involvement with the IIBA at a variety of levels and through sharing my ideas via my blog and at conferences. I have chosen not to get a CBAP or the PMI-ACP because I don’t believe they are helpful to my career.

I have acquired a couple of framework based certifications, but there were very specific reasons. In 2005, I got my Certified Scrum Master (CSM) because I took a 2-day class. I didn’t do it for the certification; I did it because, at that time, the class was a great introduction to Scrum. I also got my SAFe Program Consultant (SPC) certification a couple of years ago because my clients required people who worked with them to have it.

While you don’t need a certification to be an effective business analyst, you may find that having one may be helpful to your career in some situations. It’s important to know the difference.

For those of you without a certification, do you think you’ve been negatively impacted? For those of you with a certification, why did you choose to get it? Leave your thoughts in the comments.

Strategy Spotlight: 5 Design and Decision Thoughts that Impact Your Business Success

I believe you can design your business, career and life for your success. You and your business are the architects of your existence.

The total sum of all the decisions you have made. With that in mind, I think you have no choice but to accept or reject the present situation or state of your organization.

Related Article:  8 Things You Must Do to Make Better Decisions

From a business analysis perspective design is rational with explicit reason behind decisions for creating a system, a solution, an artifact. It is the augmented-base that is meant to be a collaborative process addressing problems and providing solutions.

Interestingly design happens in many ways, from what’s perceived to be haphazard, to the intentional. There are many design styles that we can apply to our business. The question, which one is being applied to your business.

Build It and They Will Come Design

Right from the movie Field of Dreams. This sometimes works. There is a vision of success, someone has a gut instinct, they build something and it sells, solves a problem or satisfies a dream. At one point in my career I spent five years within the entrepreneurial incubator space helping business leaders take ideas and determine the feasibility and success likelihood. I witnessed a lot of designs go nowhere. Some were brought to market only to discover that no-one wanted the product. One such business made a 500K error and it hurt. Most of these mistakes are made due to ego and with no one fact checking to see if there is a market for the product. Always check to see if the solution makes sense.

Feather on the Wind Design

This is another movie reference, this time from Forest Gump. We are like a feather in the wind, floating around, we might choose our destiny or maybe it’s a bit of both. I think this is like the unintentional design thinking. You build something or take some action without consideration of what will happen when people try your solution. This is a roll of the dice and maybe you get snake-eyes or things work out. It is all chance – like the feather on the wind. You just never know where you will end up.

It’s Mine NOT Yours Design

I consider this one selfish. You are working in your team and you create a database to track maintenance schedules. A bunch of low level decisions were made. Other teams could use it, but it’s yours and you won’t share. We see this with the endless amount of data that end up in spreadsheets. There are many systems in a business that were created out of a self design need. Generally they solve a perceived isolated problem that really exists with other teams. The key is to get a team using it to improve it.

Creative Innovative Design

I think this is something in business analysis that we seek to use a system to do. Part of business analysis is to answer the question where have we been. It is about documenting and analyzing the past to explore creative innovative solutions for the present and future. From my perspective, it is the fun. For example, in the short news feature, “A Deep Dive” a design company uses on-site observation to watch how people shop in a grocery store. Their purpose is to create an innovative new shopping cart design. An experienced team took on the task. The interesting lesson learned is it’s all about the process. A process that can be used step by step to create a solution based on a business problem to be solved and information from the business worlds’ stakeholders.

Tasks that People Do but No Activities for You Design

Years ago I taught a course in process and model development. The students always wanted to learn how to do a work flow diagram right away. Rarely did the learner know anything about where process modeling came from or process levels and the way systems connect in an organization from a structural perspective. In a basic 5 level organization structure you would learn that there are different process levels and maps used at each level that must link to create an organizational whole. The telecom industry’s business process framework, e-TOM explains this well. In level thinking there is a distinction that can be made between tasks and activities. A team should embrace an understanding of process levels and designs using a combination of models to ensure they are gaining important systems insight to make better decisions and designs.

Facilitated Focus Group Design

In my 3 Day Gathering and Documenting Requirements course I cover some common important skills for the business analyst (Facilitation, Documentation, Integration and Presentation). I spend time on the different methods of gaining insight into the stakeholder’s perspective. Stakeholder focused groups are a great way to generate discussions and a lot of great primary research information for user-based design. I like the terms used in the Atlantic Systems Guild’s Volere Template that addresses the importance of understanding the goals, needs and contexts of the stakeholders (users) to drive design decisions. During a group session you might discover that people use a system to routinely review other’s work to determine how they might do their work. Recently I experienced this myself. I was asked to provide a program outline for a new client using their outline requirements. I needed to see someone else’s work and outline to deliver what they needed. Unfortunately the client did not make it easy since the information was not readily available. During a focus group the issue was raised and we were able to address an improvement we could make. A new function within the system was created from the input of the users.

Final Thoughts

Design and decision making are entangled. You literally can’t have one without the other. I do believe there are different levels of design and the way that items get integrated into the fabric of an organization. I have stopped counting the number of bottom-up projects that I have been involved in where a user created something for their use and over a course of a decade it ended up on the strategic or tactical agenda of the organization. I do think there is a better way to design and make decisions but I also know that people and culture are a big part of the system, the process. Finding standards that work in your team and your organization goes a long way to helping you solve business problems and coming up with great design solutions. If you can identify the design approach that is being taken by an individual, team or organization maybe you can help slide the organization along the continuum of creating better designs and decisions.

Good luck.

Remember; do you best, invest in the success of others and make your journey count, Richard

Adventures in Opportunity Canvasing, Part 3 of 3

The big day had finally arrived! Thanks to my earlier preparation (see parts two and three), I set up in record time and could sit and worry before everyone got there.

Apart from having the canvas up on the wall, I also decided to print off my template. I placed a few templates on each table so participants could get a closer look and read the prompt questions themselves. I also put pens, sheets of paper, and sticky notes on each table in the event people thought of something to contribute and wanted to write it down before forgetting. Alternately, if we decided to have them fill out the sticky notes and place them on the board themselves, they would need these materials. I wanted to make sure I was ready for a few variations to the meeting as I find once you are in a group you realize you have to change your approach. For instance, if no one was participating out loud, I could ask them to fill out some sticky notes on their own and then place them on the canvas as they talked about them.

To start things off, I had my key stakeholder give an introduction of the opportunity at hand and some background on why we wanted to explore it. Since he was from the business area the others operated in, I felt that he could tell a better story. Once he finished with his introduction, I then presented the Opportunity Canvas as well as some housekeeping rules such as not using laptops, when we will take breaks, and the Jellyfish rule. No one had questions about the approach so, we were off!

Here we go!

I was fortunate to have an active group of people who were willing to talk and share their ideas. I was able to write out sticky notes as they talked and placed them on the canvas. Some areas did require a little prodding, such as users and customers. I got them started with some example users and customers that I had generated during my dry run. From there, they were able to introduce other customers I had not considered, and we found a couple of segments with different problems.

Overall, we came away with many ideas for how to solve customers’ problems. We even had time to do a small exercise to order them in a way that we thought would provide the most value initially (those are the arrows in the Solution Ideas section). We also identified a customer segment that would be good to experiment with. Here is what our board looked like after:

haglof 021317

Would I do it again? What would I do differently?

I would use the Opportunity Canvas again. This technique, in particular, was a good way to focus a discussion, establish a flow, and make sure to hit the important points. There are still a few things I would do differently:

  1. Narrow the scope of the opportunity and present that scope at the beginning of the meeting. I knew this opportunity was large to start with, and I should have picked the part of it to focus on. I found people straying to other topics that were closely related, but not in scope.
  2. Tie the solutions you have today with the problems to help identify additional problems for your users or customers. For instance, if one solution today is calling the company, and you have limited call hours, a problem for customers is finding time during their work day to contact you.
  3. When completing your user and business metrics sections, try your best to put them in the form of a hypothesis. This makes it easier to setup measurable goals in the future when you start to gather data. In fact, having people set up the hypotheses with specific time frames and measurements is even better. Teresa Torres has a good, measurable hypothesis format, you can find it here.
  4. Gather any initial data, statistics, or research you can prior to performing the Opportunity Canvas discussion. There were a few times participants asked about specifics like “How many customers do this?” or “How long does this process take?” I believe having answers could have resulted in identifying more problems or solutions.

More broadly, I have convinced myself to practice new techniques or methods more often, even if it means barricading myself in a small conference room. I read a lot of articles and books every week about lean methods, requirements gathering practices, how to build a roadmap, etc. For everything I read, I lose about half of the knowledge, because I do not try it right away. This was the first time I was able to try something, with a large group, shortly after reading it. Practicing it helped cement the learning.

3 Reasons Why the BA/PM Hybrid Role is So Difficult

There are many variations of the BA Hybrid role, but the Business Analyst/Project Manager hybrid is the most widely discussed.

While there may be disagreement on whether there should be a blended BA/PM role and where the two roles differ and overlap, I think we can all agree on one thing: this hybrid role can be very challenging. It is also a hybrid that is gaining popularity as organizations look for ways to become leaner and more flexible. In this article, I will highlight the top three reasons why this hybrid role can be difficult for many and some suggestions to overcome the challenges.

1. The BA/PM role requires expertise in both disciplines.

The BA/PM role requires highly developed competencies across both disciplines which require education and experience across both to execute well. The problem is, many organizations, whether intentionally or circumstantially, assume that a good BA can quite naturally take on project management responsibilities and the same goes for PMs being able to take on business analysis tasks. The reality is that while one person could do both, there will most likely be a marked difference in the level at which they execute if they are experienced in one and not the other. For example, an excellent PM with limited BA experience will likely get the project done but the value delivered may be less than initially expected by the stakeholders. Why? Because project management focuses on delivering the project according to the project requirements, but business analysis looks deeper at the meaning of the requirements and how the solution will be best implemented. A PM who is inexperienced in business analysis may take the requirements as stated by the stakeholders at face value, something that a more experienced BA would look deeper at and inquire more about. A BA with little or no PM experience may produce well-defined requirements but would likely struggle when it comes to managing multiple project constraints because they do not have the experience needed to make professional judgments that will keep the project on track.

2. This role only works well with small changes.

The IIBA Competency Model states this concerning hybrid roles, “The dual hybrid role is typically associated with small or less complex work efforts, where it is possible for a single person to perform both roles effectively.” This is true when it comes to the BA/PM hybrid and those performing these roles are certainly aware of this reality. This becomes an issue when an organization is immature in either discipline or is undergoing organizational restructuring. While it may be well understood that smaller is better with this kind of role, when an organization is not mature in performing project management and business analysis, the cost of failure and the loss of value is not easily identified. When an organization is undergoing organizational realignment, they often take an “all hands on” approach to getting things done, which may leave one person managing large or risky efforts while holding multiple responsibilities. From the outside, it can appear as a great way to maximize resources because no one truly understands the real costs of having one person doing both.

3. The role may not be well-defined or adequately supported.

Any role that is undefined or poorly defined is likely to cause problems. With the BA/PM role it can be even more evident. Many BA roles already have a lot of presumed tasks that impact the nature of their work. Many PMs have roles loaded with other responsibilities outside of project management. When the two roles are combined into a BA/PM role that is ambiguous and undefined, it can produce a lot of issues, not only for the individual in the role, but also for the organization. Many times, the BA/PM hybrid role is not even officially acknowledged as a hybrid role and appears out of necessity where the person keeps the same job title but assumes more responsibility in the other domain. These situations can also make it hard to find the right person for the role. It is not enough to simply take two full-time job descriptions and merge them together into a double job description. There must be much thought given to what they will be asked to do and what they will not be asked to do. If this boundary is not created, it will set up the BA/PM to manage their work by urgency only, because there won’t be enough time to do everything they are assigned.

Increasing the Odds of Success

To ensure that the BA/PM role is successful, organizations must pay attention to the role and what is needed to increase the odds of success. It is not enough to merely assign additional responsibilities to an existing role. Organizations must take the time to define the role considering the value they expect to receive and the inherent limitations of the role. Once the job is defined, there must be a concerted effort to keep assignments within the size and complexity that will best enable success and have mechanisms in place to measure that.

Additionally, there must be some consideration given to what will be needed to support the BA/PM. Are there other team members who can assist with tasks that would normally be associated with one or the other function? I have been successful in BA/PM hybrid roles where I had an oversight role on the business analysis side and was expected to review and guide the work of other BAs, rather than do everything myself. A successful support structure will also include access to the education, training and mentoring needed to allow those performing the role to sharpen their skills. All of these will increase the odds for success in the BA/PM hybrid role.

Top 6 Critical BA Skills for the Future (and today!) – Part 2

When I wrote part one of this article series, I wanted to go deeper and have heard from many that deeper is where part 2 needs to go!

You’ll see the original six critical BA skills below with additional details and questions to help your team think about how to apply these valuable skills. 

1. Data Insights: Analyzing Data to Identify Customer Behavior Patterns

What does this look like for BAs in practice? It’s about BAs getting comfortable analyzing and applying customer/user data throughout the project lifecycle. Data insight skills include a continuous process of modifying system behavior based on an understanding of what is valuable to the user.

BAs with great data insight skills understand how customer behavior data can be used to boost the customer’s experience. Here are a few questions you can ask yourself or your team to develop new data insights:

  • How can you use customer data to drive and prioritize your backlog items?
  • What insights does the data give to prioritizing sprints and release goals?
  • What does customer behavior data teach us about how the system should respond to users?
  • What system data can we use to use to adapt (in real time) to user experiences?
  • What data is too large in numbers and complexity for the human brain to process and how can we simplify it for our customers?
  • What value is the customer hoping to receive from the system and which data provides this value? (Are you providing more data than needed to provide user value?)

2. Requirements Anthropology: Observing and Empathizing to Boost Value and Improve the Life of the User

Data insights are critical, but it can be difficult to elicit user/customer behavior data from our typical stakeholders. The difficulty comes because customer needs change faster than we can write a requirements document!

Here’s an example: I signed up for a Spotify account so I could listen to music while working out. On day two, after carrying my phone from machine to machine, I hopped on the treadmill and discovered an immediate NEED: A treadmill with Spotify login capabilities! I wanted the treadmill at the gym to let me access my Spotify running playlist, rather than carrying my phone. A week ago I would not have had that requirements, and now it is something I want bad! I would prioritize it over many other ideas for the gym.

That’s where requirements anthropology skills come into play. BAs borrow the mindset of an anthropologist to keep pace with the changing needs and behaviors of their end users.

Data gathered from customer observations six months ago is out of date. Requirements anthropology encourages real time observations and continuous delivery to meet those changing needs.

How can we observe and evaluate the customer experience AND deliver changes in days? For some BAs, this is easier with agile cadences that include continuous delivery prioritized by end user value. If observations generate system or process change requests with higher end user value than current backlog/roadmap items, they move to the top of the “to-do” list.

For all BAs, agile or not, requirements anthropology calls you to act on what you see when observing users and customers, especially when you can add immediate value. On a recent project, I observed users for 10 minutes and found four quick fixes that were not logged as defects. Once fixed, these simple changes dramatically improved user experience and business operation metrics.

3. Visualization: Using images to explore and learn.

I am not a visual genius and it is pretty hard to find those with the rare talent. But we don’t need perfect, formal, elaborate visuals. Get up from that chair in meetings and sketch on the whiteboard! Draw concepts and connect the dots. In virtual meetings, use that virtual whiteboard! Use basic shapes like stick figures, boxes, circles, arrows, etc.

Visuals create deep, shared understanding that’s more effective than detailed requirements documents; creativity and engagement skyrocket as well. Experiment with various high level models and diagrams and tools connect concepts or data visually.

Did you know the brain engages deeper for the person doing the drawing? Give other people ownership by handing off the marker (or the screen control) and encourage them to add or modify. There is something magical about creating visuals that cannot be duplicated by pure dialog. Our brains crave visuals to enhance the verbal part of the conversation.

4. Forensic Thinking: Evaluating Assumptions and Perceptions to Uncover Facts

Forensic thinking encourages BAs to expand their definition of elicitation and explore techniques beyond stakeholder interviews and requirements workshops. An elicitation approach that includes both collaborative and research-oriented techniques helps BAs fill gaps and connect dots that are not obvious with a single technique.

Use techniques like collaborative games and create workshops that use multiple techniques in the workshop to gather insights. Then, use the questions that come out of these workshops to research, analyze and prioritize the next steps in your requirements approach. Also, use experiments with users, data and/or rules to test out assumptions rather than simply listing assumptions at the end of a document.

5. Data Security: Balancing Risk and Value

This is where our favorite non-functional requirements pop up! Unlike the past, BAs use value to analyze and prioritize non-functional requirements like data security. The primary goal is to get the right level of quality without compromising value, and it is so tough! The trade-offs between user experience and data security risks usually creates uncomfortable dialog.

If you’re ready to start the conversation, here are a few tips:

  • Challenge yourself and the team to really think about how data security impacts the user and the business.
  • Find the balance between fear and user experience impact. This may mean doing some A/B testing and seeing the difference in user behavior on two different security models.
  • Respect data security needs while also embracing the reality that less security can improve the user experience in ways that might outweigh the risk.
  • Debate where to draw the line. Where are you comfortable trading data security for user experience?

6. UX – User Experience: Collaborating in Short, Informal Iterations to Build an Integrated Experience

Let go of the concept of a UX “phase” with distinct start and end dates. Don’t jump into screen updates and formal mock ups. Instead, encourage your team to let UX evolve as the team collaborates and learns.

  • Start with quick hand drawn screens.
  • Build, and iterate, and iterate more to get to the right balance and experience for the user.
  • Approach UX with an integrated mindset. Look at the user experience and all of the screens as a whole rather than perfecting a single screen.
  • Map screens to user-focused process models. Identify the critical parts of the process that impact the value the user gets.
  • Walk the walk of the user, in real time in a team meeting, rather perfecting a document.

Are these skills on your radar in 2017? I would love to know how your team is integrating value, customer behavior and visuals into your daily routines. Please leave your comments below.