And that’s why we resist requirements prioritization. If you’ve been told you are “too business oriented,” this is an area you want to focus on – helping your stakeholders get clear about their priorities and what is really, truly important.

For those who like to read instead of watch, here’s the full text of the video:

I’m Laura Brandenburg from Bridging the Gap. We help business analysts start their careers.

Today, I want to simplify requirements prioritization. If your experience is anything like mine, when you ask your stakeholders to prioritize their requirements, you just hear groans of “Nooooo. Everything’s important.”

When you think about even asking them to prioritize their requirements, you probably go, “No.” Maybe you feel like everything is important, or maybe you feel like it’s just hard to ask what’s most important from your business stakeholders.

And if you’ve been told that you’re too business oriented – this is feedback that some business analysts receive when they are kind of a doormat for the business – and just say, okay, you want everything. Let me put everything into the requirements.

If you’ve been told that, that you’re too business-oriented, or something along those lines, prioritization is an area that you need to focus on and get clear on and start adding to your toolkit in how you work with your business team.

Let’s talk about some simple and easy ways. This does not have to be complicated.

Requirements Prioritization Get Easier When You Know What Problem You Are Solving

The first thing to know is what problem are you solving? I say this again and again and again. I’ve been saying it a lot in videos lately, but it’s such a critical part. If you don’t know what problem you’re solving, you don’t know what requirements are most important. It’s simple as that. That is the information you need.

If you know that you’re solving XYZ problem and your business objectives are to increase sales or improve retention, or make a specific thing more efficient, then you know what requirements are most important because you can look at what requirements are in surface to that business need.

As we’re implementing our new learning management system, the most critical business problem for us is to streamline the participant instructor interaction and eliminate the manual pieces in between that are slowing the process down.

They’re also making it difficult to scale that process as we serve more customers. Everything that we’re doing is coming up against that problem. Is this feature helping us solve that problem? Very clear filter.

Requirements Prioritization Gets Easier When You Make It Simple

There are a lot of sophisticated tools out there for prioritizing requirements that you can try and experiment with. We focus on practical real-world simple best practices at Bridging the Gap, and so, the two ways I suggest prioritization are either 1, 2, and 3.

So, you give every requirement a 1, 2, or a 3; 1 being high priority, 2 being medium priority, 3 being low priority or a nice-to-have. That is pretty simple. The challenge is that everybody wants everything to be a 1.

You have to go back to what problem are we solving – 1’s are the things that help us solve this problem in the most impactful way, 2’s might be like they could add to the problem, but they’re not essential to solving the problem, and 3’s are related things that we’d like that came up but probably aren’t going to see the light of day in this project. You’re clear, then, on your 1’s, 2’s, and 3’s.

The other idea is to rank order. So, 1, 2, and 3 would be every requirement is a 1, 2, or 3. Rank ordering would be like there is a 1, a 2, a 3, a 4, a 5, a 6, all the way down the list. You’re saying #1 is more important and #2 is more important than #3 and you’re rank ordering the priorities.

That’s a strong way to prioritize that’s used on agile software development teams to rank the product backlog. There’s no ambiguity about what is more important than what. There’s no sense of like there are 20 things that are #1 and we can only do three things in this sprint. What are the three of those 20? “Oh, we’ll do 1, 2, and 3. And then the next sprint we’ll do 4, 5, and 6.”

I find that combining the techniques works well because if you have a product backlog that has 20, 30, 50 items, ranking 1-50 starts to feel like is there much difference between 45 and 46? Does that matter?

While we’re still working on numbers 1, 2, and 3, using 1, 2, and 3 to chunk out that backlog and then ranking the ones that are our 1 priority can be a way to sift through it and not have to rank everything on that backlog, which would get to be a tedious task that’s adding less and less value as you get further down the backlog.

Requirements Prioritization Gets Easier When You Understand Timelines and Costs

The other final tip I want to share with you in terms of making requirements prioritization easier is that it can help to understand the time and the cost involved in implementing that requirement.

How this is coming up for us in the learning management system is I did the 1, 2, 3 and we had some 3’s; we had some things that were non-essential, but if they weren’t there already that would be great. But if we have to do anything to make them happen, not going to happen.

Then the 2’s, the rule that I set out for the 2’s – the 1’s were essential; they were essential to solving the problem, and they were essential to how we deliver the courses and deliver our business. We had to have the 1’s. They were essential in order to release this product to our community.

The 2’s were really good stuff. They weren’t just like, “Oh, it would be nice to have that.” They were good features that were going to add a lot of value to our business. I wanted to make sure that we could keep the scope of the project tight to get it done in the timeline that we had and use the tools that we had, and to manage the budget that we had available.

With 2’s, I said, “If it’s a configuration,” if it’s just a matter of somebody setting something up and configuring it, or maybe less than an hour of work, let’s do it. If a 2 is going to require custom development or a new tool that we don’t have or not available out of the box, we’re not going to talk about it for the scope of this project.

It made it clear what that 2 meant, and it became easier to prioritize as we understood what was the time and cost available. Then we could look at the 2’s that were potentially in scope based on knowing how they could be implemented. It takes a little bit of analysis, a little bit of collaboration with your team to give a gut check on each of those requirements and say, “How much would this take?” “How much would this cost?”

You can find your stakeholder priorities tend to shift a little bit. Sometimes something you thought was important, like a 1, you’re like, “Oh, that’s two weeks of work?” It’s not a 1; maybe it’s more like a 2 or a 3.

And you see people when they understand the time and the scope and the budget that goes into implementing that requirement, then, they start to get more comfortable with the prioritization because it has more meaning. It has an actual value assigned to it that’s not just, “Hey, as long as I can ask for everything, I’m going to ask for everything until you tell me that I have to pick and choose to fit within a budget.”

Requirements Prioritization: Keep It Simple

Those are my three tips. You’re focused on keeping it simple. It doesn’t have to be a complicated process. More than likely, if you’re trying to make it a complicated process, it’s because you don’t understand what problem you’re solving and it’s not clear who is in charge of making decisions for this project.

You’re using a more complicated technique to try to, under the hood, facilitate between the stakeholders who are just not getting together and agreeing, and instead, we should be focusing on those core conversations that they’re having about what problem they’re solving and what the end result of this project needs to be.

And getting a clear direction and clear decision on that, which is going to make our whole project go easier, and going to make prioritization quite apparent once you get into the details and provide people with the information they need to make a good decision.

I’d love to hear how you prioritize requirements, or what challenges come up for you as you do this. It’s simple, conceptually. In the real world is where the fun happens. I’d love to hear what’s coming up for you on this topic.

Again, this is Laura Brandenburg from Bridging the Gap. We help business analysts start their careers.

>> Get Your Quick Start to Success as a Business Analyst

At Bridging the Gap, we help mid-career professionals build the foundational business analyst skills they need to thrive in a variety of business analyst roles.

If business analysis is a career that you want to excel at, the absolute best next thing to do is to join my free Quick Start to Success workshop. You’ll learn how to avoid the most common pitfalls faced by new business analysts and the step-by-step business analysis process to create predictable, consistent project success.

>> Click here to register for the free workshop today <<

>>How to Learn the Foundational Business Analyst Skills

When you join The Business Analyst Blueprint® training program, you’ll gain real world experience in the industry-standard techniques and business analysis processes. You’ll create work samples with the opportunity to have them vetted by experienced instructors.

>> Click here for more information about The Blueprint <<

But how do you actually make sure your solutions are cost-effective? In this video, you’ll learn 3 ways to use your analysis skills to find more cost-effective solutions.

For those who like to read instead of watch, here’s the full text of the video:

I’m Laura Brandenburg from Bridging the Gap, and we help business analysts start their careers.

One way that business analysts add value is by exploring and finding more cost-effective solutions to business problems which will save their companies time, and resources, and free up energy to work on other projects as well. A lot of times we think we need a really big solution where a small change might be just as effective.

Other times, we really do need to make very substantial systems updates or deploy new systems, but we kind of tend to lop on a bunch of fluff that doesn’t end up serving the business in the most impactful way.

And, so, in both of those situations, good business analysis can help reduce the overall cost of the project and find more cost-effective solutions to the true business problem.

I want to share three ways that we can find more cost-effective solutions as a business analyst.

#1 – Find Cost-Effective Solutions by Solving the Right Problem

One is by focusing on solving the right problem. We take time as business analysts to understand what the problem truly is. That gives us the information we need that sparks creative ideas to finding more effective solutions.

For example, we are updating our learning management system right now at Bridging the Gap. It’s the system we use to deliver course materials to our participants, and that we envision enabling more communication directly between our participants and instructors.

Right now, there’s a middle administrative piece to that that’s creating unnecessary time lags at times and, also, just unnecessary work from an administrative perspective in terms of funneling emails and forwarding them back and forth and assigning them to people. We know that there’s a more cost-effective solution out there, and also, that we can solve some key problems.

The main problem that I was focused on solving when we started this initiative was eliminating that administrative overhead because, honestly, the way that we’re scaling and growing and able to serve more people, we are at our limit for how far we can scale that system. It’s at its breaking point.

I’m sure you’ve seen processes that worked really well when the business was at one level, but then as you grow and expand, you realize this process doesn’t scale super well. That’s where we are with that process.

As we started exploring that problem, we realized there was also a huge opportunity to deliver more value to our customers. A lot of our instructors, because they’re full-time business analysts, actually do their coursework, support our participants over the weekend.

Our customer service team, because they’re customer service, is their full-time or their main job with Bridging the Gap. They work Monday-Friday. Requests would come in on Saturday morning, and the instructor would be checking in to answer them, but that email hadn’t been forwarded yet, so they didn’t know that work was there. There could have been an immediate response and feedback loop, if we didn’t have that manual step in place.

We realized we could solve both problems at once, both delivering more value to our customers, and eliminating an administrative process that wasn’t scalable.

That’s what I mean. Focus on, “What problem are we trying to solve?” That became the guiding light as we started this learning management system.

#2 – Find Cost-Effective Solutions by Exploring Business Process Changes

The second way that you explore more cost-effective solutions is to explore business process changes. You know your problem that you’re trying to solve. That often triggers new ideas. We had some brainstorming and came up with some ideas of how we could solve that problem.

Along the way, we explored business process changes as well. We knew it didn’t have to take a lot of technology, even though we started looking at how we could use technology to solve that problem.

Our customer service team had already implemented some spreadsheets to do some tracking and some ways that she adjusted the emails when she forwarded them to instructors to make that more streamlined.

We could have also gone down the road of hiring a different support person who would have checked the email box over the weekend to funnel along anything that came over the weekend. That would have been a manual solution to serve that goal of quicker turnaround time.

As we started exploring the features, it was interesting. We were talking through what the workflow would be and we ended up going down the road of a very customized solution on top of a course delivery platform. We were talking about, “Oh, we could do this,” “We could make this forwarding feature. We could do this.” We had to dial it back to what are the core things that we need. This is when you understand the problem that you’re solving, you can eliminate that fluff.

We took this big system and we made sure that we were honing in on just the requirements we needed from the beginning. That’s what we do as business analysts is focus on the problem we’re solving, and the business processes that can solve that problem. That meant, in some cases, that we were keeping manual processes even though we could “automate.”

One of the examples is issuing the certificate of completion. We’re still evaluating, to the degree to which that will be automated vs. manual. It might mean that an instructor has a task for the administrator to go in and check that off and deliver that certificate of completion.

It could mean there are ways that we could automate the whole process, but it’s pretty technically complex and it would cost a lot more money, and that’s not where the pain point is right now. We understand the problem that we’re trying to solve. That piece isn’t necessarily critical to solving our current problem.

It might be a problem we have to solve a year or two down the road as we scale even further. But right now, I could see how we could get around that through a manual business process.

And, so, being open to not having to have the technology solve every single part of the workflow in order to deliver value. That’s how you eliminate that extra fluff that weighs your project down and gets you off focus.

We’re doing that now, but I could see if we decided to do that, it could be months from now. We haven’t even implemented the solution because we’re still trying to figure out the certificate of completion requirement, or something like that.

That’s what happens to technology projects that just kind of go on and on and on.

#3 – Find Cost-Effective Solutions by Leveraging Available Tools

The third way is by leveraging available tools. Always want to look around in your business, like, do we have a tool that can do this now or even partially do this now?

It doesn’t always have to be building something new, and it doesn’t always have to be licensing or buying something new. Often, you can use the tools you have to add on.

One of the ways this is coming up for us in this same project is we realize after going down through all the different aspects of the project that, a help desk or a support ticketing system was going to be the best system to manage this instructor/participant interaction and help us manage that workflow in a more automated way.

We had been going down the road of a course delivery platform thinking that was going to give us those messaging capabilities, and it didn’t. So, we’re looking at how can we integrate that help desk system into our current course delivery platform to solve this very specific problem first while we simultaneously look at upgrading the course delivery platform as well.

It’s not to say we’re not going to do that, but we might be able to approach those two parts of the project separately. We’re going to leverage the existing tool we have in our way of communicating/add on a different way of communicating.

The other piece about the help desk is as I started looking at those tools, there is other functionality that they have like chat features and we can use them for all of our customer support, not just the course participant piece.

I started to see how this one investment in a tool now, even though we’re going to focus, still, on our main problem to be solved, will not work everywhere. But I could see how this one tool we could leverage it in the future to add additional value to our business and streamline other areas of our business.

And, so that got me excited thinking about this tool as being an investment that we could build upon. It makes projects in the future more cost-effective. Not because we’re implementing those requirements now, but because we’re thinking about them as we choose this tool.

Those are just some ways as business analysts, that we could explore more cost-effective solutions. That is going to help us achieve a better ROI in our project. It pays our salaries. If you can think of it that way.

Every time you eliminate a big chunk of software that’s needed, or a big chunk of solution implementation that’s needed, and replace that with something that’s more simple and elegant, that has just paid your salary and then some.

That’s how you establish your reputation as somebody everybody wants on their project because I know that they’re going to help me get the most possible value out of the investment I have to make.

We’re going to free up resources for the next set of changes, and the next project and be able to move more quickly and in more agile ways in the organization.

Again, I’m Laura Brandenburg from Bridging the Gap. We help business analysts start their careers.

Be thinking about how you can explore more cost-effective solutions in your projects. I’d love to hear your suggestions. Go ahead and leave a comment below.

Here are a few key points:

• Re-frame what the developer means by “that’s impossible”…everything is possible, given unlimited time and budget.
• Be sure to understand the true business need, and not present a business solution.
• Collaborate to find possible solutions to the real problem, which may not even involve technology changes.

To learn more about the business analysis process and handling sticky requirements challenges like this, check out the BA Essentials Master Class.

For those who like to read instead of watch, here’s the full text of the video:

I wanted to jump in and talk to you today about what to do when we hear from the development team, “That’s impossible.”  I know I’ve heard that my career.  We actually just had it come up with a course participant last week that she had this beautiful business need that had come out, a really exciting way to help the business.  She brought it to the developer and he’s like, “No, we can’t do that.  It would require re-engineering the whole database. It’s way too big.”  “Impossible” is what he said.

In the reframe on that, we’re going to talk about three steps that you can take and three things to think about when that happens.  The reframe is that everything is possible. It just maybe isn’t feasible given the budget that you have, the timeline that you have, and the current technology you have.

#1 – Define “Impossible”

“Impossible” really means we may have to spend three months reworking the database to solve the problem in the way that she presented the solution to that developer.  That could be true.  That developer may be thinking, “I know I have 10 other things on my list and nobody is going to approve this.” And that really is what impossible often means.

The first thing you want to do is unpack what does “Impossible” mean?  It’s never that it’s not possible; it’s usually that it’s not feasible given a certain set of assumptions.  The more you understand that, the better that you can do as a business analyst to come up with a feasible solution to the true business need.

#2 – Clarify the True Business Need

That’s the second thing you want to do is clarify what the true business need is.  In this case, it’s not so easy to do.  The business came up with a solution.  They say, “We want these specific data elements removed from our process.”

The developer responds, “We can’t do that.  Those data elements are connected to all kinds of other things and it has an impact on reporting, and it has an impact on other parts of the application that aren’t even touched by those business stakeholders.”  It has this broader impact when they were just saying, “Well, let’s just remove those three fields on the screen and then our problem is solved.”  That isn’t really the business need.

What was the business need driving the removal of those fields?  That was how they were setting goals with the clients.  There’s a deeper need there.  Their work performance was being tracked based on something that they couldn’t control.  That’s a huge thing.  There are a lot of factors that go into resolving that, not just the technology.

That is the first lesson. Look at the true business need so that you can understand the true scope of the solution which may or may not be just the technology.

#3 – Reframe What Impossible Means

The third piece we talked about, reframing what impossible means.  First, you find out that true business need so you can go back to the developer with a business need instead of a business solution to the problem.  The next piece is to figure out a way to collaborate to move forward.

What needed to happen from there is to get a couple of the key business stakeholders together with that technology stakeholder.

• Maybe there are some other people to be involved and talk about that business need and brainstorm together possible solutions to this problem that aren’t, necessarily, to remove those fields completely.
• Maybe they can be disabled.
• Maybe different content can be captured in those fields.
• Maybe they can be made optional.

All kinds of different possibilities exist.  At least give the group the benefit of having some time to talk through that and to come up with possible solutions that may or may not be what the business originally presented.

Oftentimes, our best developers are going to come up with creative solutions once they understand that true business need.  Our jobs as BAs is to be in the middle of that process so that we’re communicating, helping our business stakeholders understand what their true need is and not just what they see the solution as.  Then helping the technical stakeholders come up with solutions that meet those underlying needs.  This is what we do as a business analyst.

“That’s Impossible” is an opportunity to step up as a business analyst

When that example came up in class, I was so excited.  I was like, okay, this is where the juicy stuff happens that we get to deal with as BAs.  This is a normal thing to have happen.  The course participant was a little frustrated.  “Why did this happen?  I finally had this great idea and it just got brushed aside.”

No, it’s an opportunity for us to step up, for us to engage, for us to really facilitate solving the true problem to be solved there.  It’s not the time to step back, it’s the time to step in, but to step in in a much different way than, “Really, you can’t do this?”  Let me show you how it’s possible. It’s not stepping in or forcing the developer to a specific solution.  It’s stepping in to facilitate that collaboration process so that the most possible value can be delivered from the technology in the best possible way.

That’s a lot of what we do as business analysts.

To learn more about the business analysis process and handling sticky requirements challenges like this, check out the BA Essentials Master Class.

Business processes are everywhere and most of any typical organization’s processes are largely unmapped. And that means there are many BA opportunities ripe for the plucking, whether you are employed as a business analyst or not.

But what processes should you or could you map? Let’s look at five processes that are almost always worth documenting.

#1 – Process to Implement Software Changes

You might think that if you come from the IT side, you don’t have much in the way of business processes. However, the business includes the information technology team, and there are many processes within the technology team that could often benefit from being documented and clarified.

One of the most valuable processes to get a handle on tends to be how software changes are implemented. The Implement Software Changes process could include the following steps:

• Identify and approve the change, which could involve many decision-makers with varying levels of influence and authority. 
• Create the software code to implement the change.
• Test the change and validate the new code works as expected.
• Fix any defects or deployment issues.
• Release the change to a test and/or production environment. Again, this can often involve many decision-makers and gate-keepers and include sub-processes for each system component involved in the release package.

At a high-level, you could capture your entire release as is process. Alternatively, any one of these steps could be a process in and of itself, which leads us to our next opportunity – the process to test a software system.

#2 – Process to Test a Software System

This one happens to be my personal favorite – the test process – and that’s because this is the process I conquered before moving into my business analyst role. Typically the test process is documented in a test plan. If you are in QA and look closely at your test plan, you might be surprised to find the seeds of a process flow within it. When I was a QA engineer, my test process included:

• A set of preconditions determining that the system was ready to test.
• The business users to get involved in the test process and the criteria for identifying them on a new project.
• Specific areas of the software application I needed each business user to evaluate.
• The steps for anyone testing to submit a defect for resolution.
• The communication path from me to the development team about the defect (and then back to the business user as a resolution was found and made).

Whether or not you have the title of Quality Assurance Engineer, if you are involved in the validation of software (or any other validation process for that matter), the process you use to test the system, communicate the issues you find, and follow up to ensure those issues are resolved is worthy of a business process model.

And if you are not part of the technology team (which is the case for many of our Business Process Analysis participants), I think you’ll find processes to map everywhere you look. Let’s look at a couple of the most common processes for which mapping efforts can be particularly valuable.

#3 – Process to Resolve Support Issues

Do customers, clients, users, or even members other departments send you issues that need to be resolved? How are these handled? Issue resolution is one of the most troublesome processes for nearly any organization or team. And that’s because issues often need to be bounced around between team members and departments until all the right information related to the issue is discovered, organized, and acted upon.

This process might be called Support Customers, Resolve User Queries, Deliver on Service Level Agreements, or Manage Support Requests. It could involve any of the following complexities:

• How issues are escalated from one department to the next.
• Who is responsible for what type of issue.
• Who screens the issues as they come in and assigns them for resolution.
• How issues are monitored for timely resolution.
• What the communication path is throughout the life of an issue.

The benefits of clarifying this process are significant. Issues represent “time suck” and issues that fall off everyone’s radar can represent significant risks to the business – losing a top client or failing to meet a public commitment. By clarifying the hand-offs, escalations, and expectations, you can often introduce simple changes to improve the process and gain significant operational efficiencies.

#4 – Process to Create Reports

Reports are everywhere in today’s organizations. Monthly financial reports. Weekly reports on unresolved issues. Technology stability reports. Customer activity reports. Sales reports. Past due reports. Marketing campaign effectiveness reports.

And creating all of these reports takes real time from dedicated employees like you.

But often the process of report creating is not as streamlined as we’d like. Perhaps we need to gather data from multiple different systems and compile it together. Perhaps we need others to gather some of that data for us, and that other person never seems to have the time and waits until the 11th hour.

And once the report is done, we might not even know who looks at it and what insight they glean from it.

There is a lot of value to be gained from evaluating the reporting requirements and process.

• Are there opportunities to streamline the creation and reconciliation process?
• What is the business purpose of the report? Is all the data needed?
• Is the timeframe and frequency correct?
• Could this report or parts of it be created in an automated fashion?
• Could we combine reports and alleviate some overhead?

Answering questions could save you and your organization significant time and could even be the first step to a more formal reporting system or a business intelligence project.

And while all of the processes above could definitely be relevant in a non-profit organization, there is one process area we’ve seen multiple participants tackle when volunteering their time to work with non-profits organizations. We’ll cover that next.

#5 – Process to Manage Volunteers

Volunteers are often the lifeblood of a non-profit organization. But they offer up many challenges. They must be found, screened, convinced of the value of donating their time, assigned to an appropriate activity, oriented, trained, scheduled, and monitored. Because if you don’t do these things, the volunteer’s time ends up being wasted.

But often this process is ad hoc and that detracts from the volunteer’s experience and puts the brakes on growth. That makes it a perfect process to be mapped.

Other common processes in a non-profit organization would include Accepting Donations, Managing Sponsors, and Organizing Events.

Find a Process to Map

Interested in learning more about how to take these processes and turn them into a formalized business process model? In Business Process Analysis, we’ll walk through a step-by-step process for mapping and documenting a business process. You’ll also have the option to receive individual instructor feedback on your model and 8 PDs or CDUs towards your IIBA certification or re-certification, and/or 8 PDUs or Contact Hours towards PMI certification or re-certification.

Click here to learn more about Business Process Analysis.

In my travels away from Bridging the Gap, I think that I’ve learned something new about what might be the second most important ingredient for an analyst. Analytical thinking. In reality, I combine this with critical thinking, even though they are two distinct things.

It’s been difficult for me to spot this trait in people; one cannot necessarily notice good thinking like a nice tie or bad body odor. It’s there, but just under the surface. One really has to observe people working in order to spot good thinking.

So what am I talking about? Let’s look at some definitions first.

analytical thinking

noun
the abstract separation of a whole into its constituent parts in order to study the parts and their relations

and

critical thinking 
noun
disciplined thinking that is clear, rational, open-minded, and informed by evidence

It’s almost like I’ve found some old friends in discovering these definitions. For me, these are the missing pieces that I haven’t been able to put my finger on when I’ve seen something missing in an analyst’s ability. Conversely, these are also the things that I cannot identify as distinguishing factors when I see an analyst who has “got it”. I know we have all been talking about these skills for years as a collective, but I’m bringing them up now again because I’ve seen the light.

Analytical Thinking

The “…abstract separation of a whole into its constituent parts…” Yes! What could be more clear? When analysts engage on a project, this is the step, or series of steps, that are critical to taking a problem domain and deconstructing it for analysis and reconstruction. Without this, one cannot see all the many facets of a problem or opportunity nor be able to explore it on all sides.

Why? Because without deconstruction, one can only see the four sides and the top of the box. Deconstruction allows us to pick the box up, open it, take out its “stuff” and look at all the sides of said “stuff”. This is where the questions start to get asked and where thought begins to roam and wander into the “what-if” zone. This is where we test our theories and spitball about possibilities both positive and negative. This is where we separate what is critical to a project and begin the reassembly process that results in a viable solution.

Critical Thinking

The key piece for me here in the above definition is “…informed by evidence…”  This falls right in line with a thought I often express as, “Prove it!” Without the existence of evidence, analysts who employ critical thinking will be compelled to start asking questions about the validity of what is being told or shown to them. They might not understand why they believe whatever it is that they believe, but there is a gut instinct that makes them ask questions that others might not. Something is missing that prevents satisfaction of their curiosity for the truth in whole.

Critical thinking, for me, is similar to the checks-and-balances system we learned in school about government. It is just that — a governance mechanism over analytical thinking that seeks enforcement of thorough thought. When analysis has not been performed nor resulted in the “proper” answers, then critical thinking gets triggered to ensure that the analysis is completed. For an analyst with these two capabilities, it’s almost a compulsion that kicks into place to drive answers home.

Where Can I Buy that?

You can stay up as late as you like after the cheesy movies are over and wait on the infomercials to sell you analytical thinking promos with a bonus of critical thinking, but all you’re going to come away with is a set of Ginzu knives and a SHAMWOW! moisture suckerupperthing. These two characteristics are inherent in many people, but they can be taught. Those seeking to develop these skills don’t have to live a life of misery without them, but attaining them might require learning and practicing some thought exercises that get the brain to engage in new ways. There are many, many resources available in books and on the internet, as well as seminars and courses that teach both qualities of thought.

Fortunately, this is great news for the analyst community, because once we each learn these capabilities, we are able to encounter new challenges and conquer them without as much blood, sweat and tears. So the question is really about how we learn these skills. It starts very simply, and that is the good news.

Start the practice of asking questions that you would not normally ask about things. My favorite questions is, “Why?”  That is because in order to answer it I have to think about the question in different ways, so I can answer it the best way. For instance, if I’m looking at a box on the ground in bright sunlight, I might ask myself why the shadow on one side of the cardboard is obviously darker than that on another side. Only through discovery and inquiry will I find out that the brighter side of the box is picking up reflected light of the ground. This is analytical deconstruction in which I break down the problem into smaller bits or questions.

PROVE IT!…comes next. The critical thinking part. How can I prove that my answer or hypothesis is THE ANSWER? Hmmm…what if I took some non-reflective cloth and laid it on the ground to block the light? Would the shadow still appear brighter? Again, I am asking questions about what I had previously taken for granted or assumed.

To continue your education, there are some REALLY good courses online and at local universities in critical thinking, less so in analytical thinking. However, combine a critical thinking class with some business analysis discipline, and you just might be on your way.

There are a number of blogs about critical thinking. (You can check out a list of my favorite critical thinking blogs.) Most have nothing to do with business analysis in any way, but in every way they do. Read a few posts on each one and pay attention to the line of questioning and the drivers for answers that these people bring forward. It’s the same when you apply critical thinking in another domain, just a different subject.

I wish you all well…

(Before I forget, be sure to download our free business process template, which incorporates a host of best practices when it comes to process modeling.)

1 – Identify Your Start Point and End Point

In all likelihood, you’ve got a name for your process. Perhaps it’s “Process Monthly Reports” or “Release New Software Changes.” Names begin to narrow our focus, but they tend to be ambiguous. You get stuck because you don’t really know what’s included and what’s not.

In addition to a process name, identify the discrete starting point and ending point of your process. Now every activity that comes to mind will clearly fit in scope of the process you are capturing or fall outside that start/end point boundary and can be safely captured for another process to be documented on another day.

2 – Work on Paper First

Yes, we live in a digital age and yes it’s very likely that your process will eventually need to make it into electronic form. But that doesn’t mean it needs to start in electronic form. While it can feel like an extra step to draw things out on paper and then to capture it electronically, this practice can save you time.  The simplicity of pen and paper as a tool allows you to focus all of your mental energies on what matters – capturing the key elements of the process and how they relate to one another.

3 – Know Your Audience

Not all process documentation is created for the same reason. You might need approval from an executive team, input from those who will use the process, or validation from those who will support it. If you are stuck, it might be because you don’t know who your audience is or because you are trying to use one document to meet the needs of several stakeholders.

Clarify your audience and their expectations and often the most appropriate level of abstraction will become self-apparent. Which leads us to the next practice.

4 – Keep It High-Level

In our Business Process Analysis course, the biggest mistake I see people make is to dig into the details too quickly. Once you are in the details of the process, more often including the step-by-step procedural tasks, it’s difficult to step back and see the big picture.

Instead, start high-level. Confine yourself to one page or 5-7 workflow boxes. When your thinking exceeds these artificial constraints, look for ways to abstract the information you are putting into your model by combining boxes or streamlining parts of the flow. Identify workflow elements that can be further defined by their own sub-processes.

Keeping it simple takes disciplined thinking and it doesn’t mean you’ll never get to the detailed analysis. It means you’ll be sure to understand the big picture process first before digging into the details, and be less likely to get stuck when you do elaborate on those details.

5 – Let Go of Perfect Expectations and Expect to Iterate

Another reason we get stuck is because we don’t just want to document a business process, we want to document a process perfectly. If you are using a new technique or learning a new domain, that’s an unrealistic expectation. Instead, expect to iterate and improve your documentation with feedback from your stakeholders.

This does require that you develop a healthy sense of separation from yourself and your work. Consider Adriana Beal’s advice left in recent post comment:

I recommend using strategic wording to prevent criticism from getting to you:

“Hi, everyone! I realize it’s too soon for us to be able to capture with any level of precision what sort of business process we need, but just to jump start the conversation, please find attached a very early draft of a process flow. Any feedback is very welcome, you can either send it by email before our next meeting, or provide your recommendations during our next requirements session. Thanks!”

Alternatively, seeking out a trusted mentor or a particularly kind stakeholder to provide a first pass review can help you iterate privately before you share your work publicly.

>>Download Your Free Business Process Template

Get started analyzing a business process today, with our complimentary business process template.

• Help business users from multiple departments clarify their actual step-by-step workflow;
• Avoid wasting money on software solutions that don’t solve the right business problems;
• And even helping new business analysts figure out what questions to ask when starting on a new project or domain.

Business process analysis is often the very first technique used by business analysts when we start learning a new domain or analyze the scope of a project.

Click here to download your free business process template today

As I’ve been thinking about eggs, it got me revisiting the chicken-and-egg scenario for aspiring BAs. You know the dilemma: I can’t get a BA job without experience but I can’t get experience without a BA job.

So, what comes first the business analyst or the business analysis experience?

My answer: They both happen at once.

Let me explain. Being a business analyst is 80% mindset. It’s more about how you approach a problem or an opportunity than what your title is or even what responsibilities you have at work.

This reality empowers you because while you can’t control what your boss asks you to do or what your job title is, you can control your mindset.

• When your boss asks you to add a new field to the database, do you take the time to understand what business process requires this?
• When a customer calls to complain that your product “doesn’t work,” do you look at things from their perspective and how the tool you support works within their process (i.e. using a few elicitation techniques) or do you rattle off product specifications and claim the product works “as designed.”
• When a co-worker complains about the input they receive from your department, do you put up a wall of defense or jump in and discover how the hand-off works between your respective departments?

(By the way, if you are looking for more helping stepping through this process of looking at problems, building a BA mindset, and even racking up some valuable business analysis experience along the way, the virtual courses in our professional development series are designed to help you apply BA techniques whether or not you are employed as a BA.)

By focusing on the business process and the root cause of the problem, you can be a self-proclaimed business analyst doing business analysis work before anyone ever anoints you with the business analyst job title. By reframing the opportunities right in front of you, you can cultivate the mindset of a business analyst and at the same time build a business analyst work experience worthy of adding to your resume or chatting with your boss about come performance review time.

It’s time to break the egg.

>>Looking for More Opportunities?

Here are some articles to help you cultivate your business analyst mindset:

53 Tips for Discovering All the Requirements

How to Expand the Work History Section of Your Resume

5 Processes Worth Mapping

And you won’t want to overlook How to Start a Business Analyst Career, the most comprehensive guidebook available to help you craft a plan to get started as a business analyst.

But if we look a little closer, we might just learn a thing or two from Dwight about business process improvement.

(Before I forget, be sure to download our free business process template which incorporates a host of best practices on process modeling.)

Be Ruthless With Your Co-Workers

See employees as friends? Not Dwight! To him they are mostly slackers who would better be fired. While strong stakeholder relationships are key to great business analysis, sometimes to simplify a business process, we have to temporarily put business objectives over those relationships while we analyze the process and determine possible ways to improve the process. The best solution might not be the most popular or people-friendly at first.

Test the Process

Who could forget the episode when Dwight simulates a fire, causing office-wide panic? He proves without question that people do not know the emergency process. We might disapprove of his tactics, but we love one sliver of his mindset. The only way to determine if people are truly prepared to use a new and improved process is to simulate it in action.

Get It In Writing

We might not appreciate the spirit of Dwight’s “mating” relationship with Angela, but the fact that the two of them fully think through the implications of their relationship, negotiate the terms in detail, and close the deal in writing resonates. When dealing with sticky issues, high profile projects, or risky relationships it can be best to dot your Is and cross your Ts.

Negative Reinforcement Doesn’t Work

Remember the time when Dwight set up a series of punishments for mistakes culminating in an automated email to the CEO with everything questionable anyone had ever written about him in a personal email? Dwight learns the hard way that threats of punishment do inspire others to do their best work. He learns his lesson so you don’t have to.

(While I’m thinking about it, you might be interested in my Business Process Analysis virtual course. It will help you learn the business process analysis basics, use process analysis techniques at work, and put some momentum behind your business analysis career change. In addition to individual feedback on your work, it includes live webinar sessions to discuss your real-world business process analysis experiences.)

Play It Safe

Dwight’s favorite seat in the car is the backseat right behind the driver. In the event of a crash, the driver is most likely to protect themselves and by default protect the person behind them. When there’s no reason to take a risk, why take it? This is a good reminder for improving our business processes. Whenever possible minimize taking on risks and establish checks and balances. For example, if you can validate input, eliminate redundant data entry, or incorporate a review process, you reduce the risk of bad data making it into your information system.

Knowledge is Power

When Michael takes to the wilderness, we learn that Dwight has extensive knowledge of how to survive. In other episodes, Dwight proves himself knowledgeable of various crafts, animals, and other esoteric knowledge areas. While often as a business analyst you are the self-proclaimed “least informed person in the room”, through the process of elicitation and analysis we quickly become the most informed and often the most knowledgeable. This temporary focus and knowledge, even of seemingly esoteric and seemingly irrelevant details, can help us fully understand the problem and surface solution ideas that no one else is seeing.

Know Your Usual Suspects

Dwight gets duped again and again by Jim’s crazy pranks, but you’ll notice that once he’s caught on he always suspects Jim. Similarly, business analysts rely on their cast of usual suspects when looking to improve a business process, such as inconsistent hand-offs between departments, exception loops that are never closed, and gathering the same information multiple times.

Don’t Forget the Beets

Although almost manical in his dedication to selling paper, Dwight also owns a beet farm. At the end of the day, we need something to go home to. It might be  family, friends, sports, games or leisure reading. Taking time to take care of yourself ensures you have the energy to give business process improvement your all. Don’t forget your beets.

>>Download Your Free Business Process Template

Get started analyzing a business process today, with our complimentary business process template.

• Help business users from multiple departments clarify their actual step-by-step workflow;
• Avoid wasting money on software solutions that don’t solve the right business problems;
• And even helping new business analysts figure out what questions to ask when starting on a new project or domain.

Business process analysis is often the very first technique used by business analysts when we start learning a new domain or analyze the scope of a project.

Click here to download your free business process template today

Of course, the BA is not responsible for delivering the solution or implementing the solution or ensuring the solution is made available on time or on schedule. But in the task called “Assess Proposed Solution,” it’s clear that we do not get a Get Out of Jail Free card when it comes to the solution, not even the technical solution to our detailed requirements.

Nope.

Assess Proposed Solution. There is a lot buried in those words: assess – to critically evaluate; proposed – an idea that’s “on the table”; solution – meeting a business need by resolving a problem.

But really, the definition of this task in the BABOK is quite simple.

“To assess proposed solutions in order to determine how closely they meet stakeholder and solution requirements (121).”

You may assess a single solution or multiple solutions. With multiple solution options, this may involve ranking the options.

This task is all about making a decision and solving the problem. Like many tasks in the BABOK, at first glance it might appear that this is something you haven’t done. I would contest it’s more likely you haven’t done it formally, but you’ve participated in this process.

Early in my career, we held these meetings called “use case reviews” where we did a combination of elicitation, analysis, verification, and validation. Part of verifying the requirements involves ensuring they are feasible. With the implementation lead in the room (on a technology project this would usually be your architect or lead developer) often this is a quick assessment. But sometimes the technical solution to a set of requirements is more complex and requires more analysis and discussion. It’s not an immediate decision as to whether or not the requirement is feasible.

In these instances we’d schedule what I called “problem solving meetings” to review the selected “troublesome” requirements and identify potential solutions. We’d bat around ideas, debate the options (sometimes hotly), get multiple developers with varying areas of system expertise involved, and have one or two drag out meetings until we came up with a solution that met the requirements.

My role as BA in these meetings was two-fold: facilitator and watch cop. I helped facilitate the discussion about the solutions and I was the watch cop for the stakeholder and solution requirements. I can’t tell you how many times a solution would be presented and discussed, the developers would be ready to call it a day, and I’d step in and ask, what about this requirement? It ended up that didn’t meet the requirements. Back to the drawing board!

(In fact, I feel so strongly about the value these meetings added to these projects that I designed step 7 of the business analyst process around accommodating this type of work, in a variety of different forms.)

These meetings are some of the most fun I remember having in my BA career and  are an example of the task Assess Proposed Solution. While I didn’t have the BABOK to guide me way back when, I felt responsible that the final solution meet the key stakeholder requirements…because that is how we achieved the business objectives of our project and kept the sponsor happy. With a project manager, several technical developers, and potential a QA engineer in the room, I was the only one without another agenda to fulfill and so I stood up for our project sponsor.

This post is an installment in our Journey Through the BABOK with BA Stories series.

>>Define Your Business Analyst Process

Join us for the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations.

Click here to learn more about the BA Essentials Master Class

The purpose of Assess Capability Gaps is:

“To identify new capabilities required by the enterprise to meet the business need.”

Simple enough, huh?

This task involves analyzing current capabilities, creating an assessment of new capability requirements (aka business requirements) and documenting assumptions about how these new requirements will help us achieve the business need.

Starting this task with analyzing current capabilities is critical, because oftentimes, organizations have existing capabilities that are not being leveraged and a business need can be met by small change. For example, after understanding the current capabilities of the 5 organizations, we realized that one organization had a means of serving advertisements that could relatively easily be leveraged by all the organizations. Every organization had expressed this business need, and one of our first projects was to scale this capability so it could be leveraged by all.

If existing capabilities are inadequate, a project will be launched to create the capabilities. Change can be created in any of the following areas:

• Business processes
• Features of a software application
• Tasks performed by end users
• Products that an organization creates
• Services delivered
• Etc.

This is our more “typical” world as business analysts – defining the capabilities needed to solve a business problem. Note that this task is part of enterprise analysis and enterprise analysis creates business requirements. So at this point, we’re not talking about the detailed, step-by-step requirements that might go into a functional requirements document or software requirements specification, but the higher-level business requirements you might find in a short version of the Business Requirements Document (I say short version because many BRD templates I’ve seen in practice are actually very detailed, but that’s a topic for another post).

In my experience consolidating those 5 software systems, our capabilities analysis revealed about 30 or so features that needed to be enabled in a centralized way – some of these were common amongst the existing technology systems, some were unique, and some were new. To meet the business need and consolidate the systems, we needed to be able to deliver these 30+ features.

On another more typical project where we were building a new customer-facing web portal for an internal application, the capabilities assessment involved articulating the key features to be enabled for the customers and the new business processes the support staff needed to be capable of to support customer self-service.

Share some examples. When have you conducted a capabilities assessment? Do you have an example of being able to leverage current capabilities to achieve a business need?

This post is an installment in our Journey Through the BABOK with BA Stories series.

According to the BABOK, the purpose of defining the business need is to:

Identify and define why a change to an organizational system or capabilities is required.

Ah, yes, the infamous question: “Why?”

There are 3 elements of “why” referenced in the BABOK:

• Business Goals and Objectives – the ends that the organization is seeking to achieve. Goals being longer term and often qualitative statements. Objectives being more granular and objectively measurable statements.
• Business Problem or Opportunity – this is the crux of what we hear about most in BA circles, the problem to be solved. The BABOK empasizes that in order for there to be a business need, there must be an opportunity for improvement if the problem is actually solved. This is something I don’t think about often, because it seems so intuitive, but I suppose you could solve a problem but not really improve anything worthwhile.
• Desired Outcome – specifically “not a solution,” an outcome identifies the benefits resulting from meeting the business need.

All of these elements wrap together to define the business need, which is used as an input by more than 11 tasks in the BABOK. Obviously, discovering the right business need is of the utmost importance.

Do you consider yourself part of defining the business need? Many BAs do not. They might be recipients of the business need, but not active in this aspect of enterprise analysis.  However, I’ve rarely met a BA that did not ask why (as well as a host of other requirements-related questions) and did not at least clarify the business need or participate in defining lower-level business needs to support larger business objectives.

If you read through the above 3 bullet points carefully, you’ll see that the BABOK is not specific about the scale of the need. A business need could result in millions in revenue or cost-savings or it could save your favorite stakeholder in accounting a frustrating 5 minutes of manual work each week.

One of the best representations of the criticality of the business need, is the syntax of a user story:

As a {user}, I need {to do something} so that {I can achieve some benefit}.

In agile, each and every component of work is tied to a business need. And this enables the team and the product owner to be clear about what success looks like and how to rank individual stories. Say what you will about agile development strategies, in the user story syntax, there is something deeply right going on.

I know when I worked on an agile project, the syntax brought clarity to the rationale behind each and every requirement and this diligence helped us stay focused and on track. Each story met a business need and each of these small benefits wrapped up into the larger business goals of the project. This sort of relationship is something I’ve brought with me from agile even as I tackle projects leveraging different methodologies.

A document full of “system shalls” (without a corresponding column for “benefits”) does not have this same rigor and leads us to think of the business need as something big and complex that lurks behind the conference room walls where only the special people get to understand what’s really going on. And this is sometimes true. Sometimes the goals and objectives behind the big programs and projects are held in secret and, even if public, they are delivered from above and you as the BA on a piece of that project might not have much to do in analyzing or confirming that need. But this does not give you permission to ignore the need or to become loose in your thinking on the more granular aspects of your requirements.

Do you define the business need? If so, at what level? Has this changed throughout your BA career?

This post is one installment in our Journey Through the BABOK with BA Stories series.

>> Learn How to Ask the Right Questions to Clarify the Business Need

Interested in receiving a comprehensive set of questions you can ask in almost any project context? Want to feel more confident asking questions in a new domain? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.

Click here to learn more about the Requirements Discovery Checklist Pack

“Evaluate functioning solutions to understand the value they deliver and identify opportunities for improvement.”

This task involves understanding the business value devlivered by the solution and whether it is over- or under-performing, validating that value with metrics, and deciding whether the elimination or replacement of the solution is necessary.

Many BAs read this and think, “I’ve never done that. As soon as I’m done with the requirements, I’m assigned to another project. I never have time to go back and evaluate the performance of the solution.” And you might be right.

I read it and think, “I do this all the time, just rarely at the end of a project; always at the beginning.”

Let me share an example with you from my real-world experience:

When I started working as the first true BA at a company that had recently purchased, but not yet consolidated, 5 smaller companies, the first thing we did was complete an assessment of each company’s business processes and systems. After weeks of work and lots of travel, the result was 5 individual reports and one consolidated report showing overlapping functionality, strengths, and issues. This report contained a whole lot more than a solution assessment (much of it would be considered enterprise architecture by the BABOK) and was not quite so formal as the BABOK describes because I don’t recall including too many metrics, but it did begin to make a case for replacing the 5 independent technology stacks with a single consolidated technology stack. By learning about the key challenges each organization faced and the limitations of their technology systems, we had the seeds of a plan to begin enterprise analysis for a multi-million dollar initiative.

Ideally, you’ll evaluate the performance of the solution before the project is declared “done” (something we talk about in the business analysis process), but it doesn’t always work out that way. This is another good reminder that the BABOK is not a methodology, or a process, so it’s perfectly OK to start at the end.

This post is one installment in our Journey Through the BABOK with BA Stories series.

>> Learn the Business Analysis Process

An essential element of succeeding in a business analyst job role is understanding the business analysis process. We walk you through an 8-step business analysis process in the 4-week self-study session of the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations, how to create a timeline for a new business analyst assignment, and be prepared to handle the more common issues BAs face on new projects.

Click here to learn more about the BA Essentials Master Class

It is critical that business process owners be involved with this process and can work with the actual script to validate the requirements.  You as a BA cannot sign off for the business owner – the risk if you do the sign off can be high if a critical requirement was interpreted incorrectly.  The business owner would then have every right to put a halt to any roll out of the process or system.

Currently, I am writing UAT scripts with the business owners for our team.  Three other BAs are writing UAT scripts for this large and complex project.  So how do we keep this fun, keep the motivation high and keep smiles on people’s faces?

I have employed the following tools throughout the process:

1. The rapport I have developed with the business process owners is critical here and I have talked about this before.  The relationships require trust and understanding.
2. Laugh – when you are through a difficult negotiation or a tough patch of scripting – joke!  Make people laugh.  Find a way to inject humour into this tense time.
3. Feed them – lunch is a good start, but snacks are important too.  When you are locked in a room for 5 days from 8 am to 4 pm – treat people as you would want to be treated!  What’s a little sugar or salt to keep people moving forward…
4. Take breaks – my team looked at me in amazement when I forced them to take a 20 minutes break.  We went outside, for a walk, answered some email – whatever worked but we all came back fresh and with less tension in our shoulders.
5. Thank them very much for their ideas along the way, for their contribution at the end of each day, for all that.
6. Have some jokes – email jokes work well – handy to share.  Even the cute ones will work depending on the audience.

For something as serious as UAT scripting – keep it light where you can and you will be successful!

New to Business Analysis?

Learn more about getting started in a business analyst career. Click the link below to sign-up for our free step-by-step BA career planning course:

http://www.bridging-the-gap.com/free-email-course-for-business-analysts/

Editor’s Note: This relationship started when I queried on Twitter for some help planning a usability study. Leslie Shearer led me to Patrick Quattlebaum, Chief Experience Officer at Macquarium. Patrick graciously suggested a few books. It turned out that Patrick was speaking about BA/UX roles at a Charlotte IIBA Chapter meeting and I thought that would also be a great topic to address here at Bridging the Gap. I was surprised to learn about how much UX and BA roles have in common and have officially found a new profession from which I’ll seek to unapologetically steal as many tools for my professional tool belt as possible, especially when it comes to enterprise analysis.

Laura: Tell me a bit about what you do at Macquarium.

Patrick: As a User Experience (UX) consultancy, we provide strategy, research, and design services primarily to Fortune 1000 companies across a wide range of industries. Our portfolio is equally divided between IT and business customers, such as marketing and product management. This focus on both business and IT customers is somewhat unique in our space, as most user experience firms tend to gravitate towards one side or other, or on a specific genre of work like ecommerce, or a specific technology like SharePoint. This means we tend to compete with web development shops, system integrators, and interactive agencies of all shapes and sizes.

At Macquarium, we believe user experience is an enabler of business strategy and not merely the front-end work of a technology deployment because we view UX as a holistic approach to designing the interactions between people and products/services. With some clients, we help them shape strategic roadmaps at an initiative or feature level. For others we’re helping nail down the detailed requirements and designing the user interface. It really depends on when and why we’re brought in by the specific client. The earlier UX firms or teams like ours are involved in the process, the better.

Laura: I feel a bit uneducated about the UX profession. Can you share a bit more about it?

Patrick: User experience is a very broad field with many disciplines – information architecture, interaction design, graphic design, content strategy, research, and even front-end development. In terms of digital work, like web applications and web sites, we are still very early in maturation of many of these fields, and “user experience” as unifying field for these professions is relatively nascent.

A decade ago, much of the focus was on information architecture, graphic design, and usability. We were inventing best practices for structuring information spaces and giving the web a user interface. We stole methods and lessons learned from software design, user-centered design, library science, and architecture.  As the web has evolved to afford more responsive interfaces, interaction design has become a recognized field for applying an understanding of psychology and human behavior to user experience design.  To put it simply, the growth and specialization of different user experience roles has mirrored the increased use of digital technologies in our culture.

My view of user experience is representative of many of us who see incredible value in applying design to business strategy. A lot of us have moved into leadership positions and have done a lot of thinking about our field and where it is going. Like many professions, we have focused on how to add value earlier and earlier in the solution lifecycle. Today, we see it as a best practice, not a nice to have, to use methods such as user interviews, contextual inquiry, card sorting and usability testing to understand human behavior and apply it to product and service strategy and design. We advocate user experience should have a seat at the table from Day 1 to spur innovation and create human-centered solutions. Essentially, user experience professionals recognize that while there is a lot of discussion about business requirements and technology, eventually a person needs to do something with what we build in order for the business to achieve its goals. Baking into strategy an understanding of the user as well as clear design principles for the solution can make a huge difference.

A greater focus on design and human behavior is not unique to UX. In business schools today, they are teaching design thinking, for example. It’s about understanding people and empathy. It’s about how to create business value holistically by staging experiences instead of an atomistic approach that focuses on individual features and functions only. This is where the UX profession lives.

Laura: This is really interesting. I must admit, my idea of the UX profession was definitely in the user interface “design” box.

Patrick: That’s not uncommon. But truly, design is an entire process. It’s not something that happens at one part of the product or software development lifecycle.

Laura: Let’s talk about that a bit more. Given that BAs and UX professionals are tackling business problems, what examples have you seen of how they can best work together?

Patrick: I coach my team and clients on first embracing a teamwork approach, not a partnership approach. (Pardon the semantics; I’m an information architect by training.) Organizations sometimes place our two disciplines in the same department, such as IT, but I’ve seen UX on the business side or, in Macquarium’s case, as consultants coming in from the outside. Good teams have trust and understanding of one another’s skills at their base, and org structures don’t create or prevent teamwork.

While the nature of most projects necessitates a “divide and conquer” approach, it is important that BAs and UX professionals understand the inputs they are both collecting to define and design the solution. Early in my career, I was working as a user experience architect with a BA on an intranet project. The BA was primarily responsible for eliciting business requirements. I was responsible for understanding the user segments in the hospital and creating personas to represent their goals, tasks and needs. We helped one another by being notetakers in each other’s sessions. I even taught the BA card sorting. She got to see what information I was collecting and its value, and I was able to witness her help a collection of business stakeholders collapse a set of ideas into clear business requirements and gain buy-in. That’s an art too! Our empathy for one another’s role was vital and came through in the work.

Laura: That makes good sense. So you both developed a shared view including each other’s perspective but your work was not competing. Tell me a bit more about what a UX professional does in the upfront part of the project process.

Patrick: UX professionals provide key input into the product or software development process. They are concerned with aligning the strategy with end users. In most solution definition processes, the end user is often overlooked, but for the UX professional, the end users’ collective voice in the process is a must have.

Say we want to build a product. A typical process would elicit requirements from business stakeholders, looking at the competitive landscape, and marketing research. The IT team or technology partner might also provide a list of the features that can be built given the project constraints, such as budget or available technology. The BA is left with quite a long list and the project team is facing the realities of time and budget. What features do you build? How do you sequence these features in releases?

The value of UX early in the process is to introduce the user lens to this upfront work. At a minimum, user research has also brought some feature ideas to the table, and feature prioritization involves finding the sweet spot of features that align business with user value and can be built and maintained within the technology constraints. Ideally, UX has helped frame the design problem around business goals and user goals, not technology. We bring our understanding of human behavior to the process because we see users as the key integration point.

Laura: How do you learn what users want?

Patrick: Much of the focus is on user goals and needs, both functional and emotional. If I’m working on a product for a user internal to a company, I’ll go in and watch people work. We always find gaps between what stakeholders believe people do and what employees actually do and need. Through this process, we often find critical features or design requirements to include that help user adoption rates go up. A lot of times we also find things that stakeholders ask for that users simply don’t need. In this way we’re able to cut scope and increase the value of the project.

Laura: As a BA, I’ve often tried to blend these two perspectives and found that the perspective of the project sponsor and the actual users or subject matter experts can be quite separate. For some projects, I’ve used what in business analysis we call “observation” to find this out. Is that similar?

Yes! In UX, the method you were using is also called observation or sometimes contextual inquiry – essentially you watch someone use an application and look for things in their environment, like sticky notes and work-arounds, that provided insight into their context of use. Context is a critical input to design because your goal is to have the product or service fit into a person’s life or to make it easy and desirable for a person to change their behavior.

Personally, I’m intellectually drawn to formative research like observation. Exploring how people use technology is one of my favorite branches of UX, and makes a huge difference in serving our customers. For example, Macquarium once worked on a project where the goal was to find more efficiencies in the call center without degrading the customer service experience. The company’s brand was very white glove, and the customer service center was handling claims calls for insurance holders whose homes had burned down or who had lost valuables in a burglary. There is a lot of emotion in those calls. In observing several customer service representatives doing their work, the team realized that inexperienced reps were following a very linear process dictated by the system, while the experienced reps had learned to write notes on paper and then to do data entry after the call. This workaround meant they could focus on the customer and have a more fluid, compassionate conversation. Redesigning the data entry forms to be non-linear seems like an obvious solution, but the insights from the observations was the information that showed our clients the value of investing in that design approach.

Laura: Interesting. I could see myself doing something similar as a BA. But I might be more “linear” about it, so focusing on the business objectives within achieving the desired customer experience and then working with the customer experience rep to try to uncover the root causes of those problems. It seems that UX approaches the same problem space in a different way. It’s more fluid and is bringing in all kinds of information to look for possibilities.

Patrick: Yes, that’s a good way to put it. We are looking for possibilities through the lens of the user.

Laura: Interesting. Well, I’m convinced that I should be looking to UX for a few new tools to add to my BA tool belt.

Patrick: The UX profession keeps expanding the toolbox, especially tools used early in the project lifecycle. There are some great tools for BAs to steal there.

On a side note, I’m all about building a tool belt as part of your career strategy. I am always looking to expand the tool kit of my firm and myself. There are some basic core process building blocks of the profession that you need to learn early on. But as you go to different companies throughout your career, you will see different processes or flavors of processes, so it’s important to be flexible and creative. Every project has a different set of challenges and opportunities and therefore the tools you pull out of your kit, or invent, are very contextual.

Laura: 100% agree. Anything you’d like to share with Bridging the Gap readers?

Patrick: If you asked a group of UX professionals what they do and built a word cloud from their answers (I’ve done this), always at the heart of it is design. The nuance is that this is not just technical or user interface design. It is experience design. Experience design is what we all do in one way or another. I believe that BAs are also designers; it’s just a different role in the process. For some reason, design has become synonymous with aesthetics and “look and feel”. This is starting to change where we are repositioning design to mean big-D design. At this level we’re talking about applying design methodology to business strategy.

Laura: What are some resources you’d recommend for learning about user experience and big-D design?

Patrick: I’m a big book guy, so here are a few of my favorites:

• The Elements of User Experience – great overview of the breadth and depth of the concerns of user experience and our process.
• Subject to Change – great summary of our field’s view of the value of design-driven product and service development
• Sketching User Experiences – the importance of visualizing our ideas throughout the software development lifecycle
• Observing the User Experience: A Practitioner’s Guide to User Research – great methods for your toolkit, like user interviews, contextual inquiry, usability testing, and card sorting.
• Design Is How It Works: How the Smartest Companies Turn Products into Icons – case studies in applying design holistically to companies, products and services
• Design of Business – highlights how organizations can use design thinking for a competitive advantage;
• The Experience Economy – this book is over 10 years old but still very current. It’s about staging experiences that are focused on people.

Laura: Thanks for your time today Patrick. I’m really glad I had this opportunity to learn more about the UX profession and I’m excited to share these insights with my readers.

Patrick: I appreciate the opportunity to talk about UX to your readership. We work side by side every day, and it is important for our communities to actively discuss our fields’ views, goals, trends, and how we can better collaborate to design the best user experiences that we can.

It is important to ask the right questions early on. This encourages our stakeholders to approach the problem-space in a thoughtful and creative way hopefully working around any presuppositions, prejudices and assumptions. Asking a balance of logical and also deliberately provocative questions can help us to get a better understanding of our stakeholders’ worldviews, and help us to understand what they value as well as ideas or requirements.

Provocative questions are those that encourage a stakeholder to think creatively and laterally.  They help to uncover any perceived constraints, and can help to evaluate whether those perceived constraints are real or imaginary.  They can help to confirm or uncover the business driver behind a project/requirement, and they promote a level of creative thinking which might not be obtained through purely straight forward questioning.

Thesequestions help to challenge our stakeholder’s preconceptions, and ensure that we understand the business driver behind the project/requirement.  By explicitly externalising these ideas and constraints early in a project’s lifecycle, it is also an opportunity to spot any conflicts or areas of disconnect between stakeholder groups.  This also provides the opportunity to debate and gain consensus on the objective of the project, before moving into discussions over potential solution options.

Here are some examples of some provocative questions you might find useful:

1.  “If there were no constraints (budget/time), what would your ideal solution/outcome look like?”: This is often seen as a dangerous question, as it opens up scope. It certainly needs to be used alongside clear expectation management, however it can get us closer to the real business problem or opportunity that is being addressed by the project.

2. “What is the worst possible project outcome from your perspective, and why?” : This might sound like an abrasive and counter-intuitive question, so it’s essential that you are sure you have built good rapport with a stakeholder before using it. This question is valuable as it helps to elicit values, constraints and tolerances.  For example, if the worst possible outcome is “Late delivery, because the regulator will shut us down”, then you know that time is the key constraint.

3. “Imagine nothing changes. What would happen, and where would the organisation be in 12 months time?”: This question helps to understand the relative urgency of the project, and is also likely to uncover any environmental factors.  It also helps to confirm the business drivers for the project.

4. “If you had to articulate the project objectives in a single short sentence, what would it be. And how will these objectives help the project to deliver financial benefit?”: It can be enlightening to ask stakeholders to succinctly state the purpose of a project, stating how this is of financial benefit.  Often, different stakeholders have subtly different worldviews, and therefore perceive projects differently. For example, an operational stakeholder may focus on efficiencies, a marketing stakeholder may focus on increased revenue. Even when a business case has been drafted, stakeholders tend to have slightly different views on what benefits will be realised (and how they will be realised). This is extremely useful to know, as it will uncover any areas of disconnect early so that they can be resolved.

5. “Imagine if we fast-forward to 2 years after the implementation of this project, what will the organisation look like?”: This question helps gain an understanding of the future state of the organisation, and what it means for the people and processes that run it.  It can be used to get a sense for the size of the change that is envisaged.  For example, does it involve significant organisational restructure? Or is this out of scope?

6. “How do our competitors handle this? Do we want to be the same, or different from them?”: Often, business stakeholders will look to see how a competitor has solved a particular problem, and will initiate a project to replicate this.  In some circumstances, this will be a completely valid approach.  However, a better solution might be to differentiate from competitors, and solve the problem in a new way that increases value to customers.

8. “Is there any other way your business objectives could be met? If not, can you explain why this is the case?”: It is extremely useful to know whether delivering a particular project is genuinely the only way to address the business problem/opportunity that has been identified.  There might be others, and it’s useful to know whether they have been ruled out.  Other options might include:

• Process (rather than IT) changes
• Organisational changes
• Outsourcing work
• Manual workarounds

In summary, using provocative questions is a great way to encourage lateral thinking amongst your project stakeholders.  This will help to surface ideas, values, issues and perceived constraints.  Once these thoughts have been explicitly surfaced, they can be discussed and re-evaluated.

Encouraging lateral thinking helps to uncover imaginary constraints, and helps us challenge the business objectives to ensure they are sound.  I hope that the questions above help you engage with your stakeholders and understand what their projects mean for them.

>> Learn to Ask More Questions

Interested in receiving a comprehensive set of questions you can ask in almost any project context? Want to feel more confident asking questions in a new domain? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.

Click here to learn more about the Requirements Discovery Checklist Pack

Here is how the walkthrough works.

• Each of the departments will work independently, as they will in the new process.
• The project manager puts together a customer package of a closed project – this is the full construction package that gives us the details we need to do our jobs as we walk this through the process.  (This would include maps, drawings, requirements, customer information, approval documents).
• We also have the new process maps, the documentation and an idea of how we want the tools to perform.  This is difficult at this stage as the new systems do not have requirements yet and everyone is wondering what they will look like.

The first team starts out with the customer and gathers information.  As we all wait for the order to arrive in our work queue, we realize how much time is actually spent with the customer – gathering information, using tools to detail maps.  We have a conference bridge set up – and we hear ‘ customer group calling design’ and design answering.

The business analysts are looking for gaps in the process.

• What has stopped the workflow?
• Can we move it again?
• What system trigger do we need?
• Do we need the CRM system to tell us that all customer information is complete and the quote can be created?

Once the status changes to quote accepted by the customer, then the next team is engaged.  They receive their detailed package from the Customer group but once they examine it they are missing key maps of the customer site.  At this point, the run through grinds to a halt and phone conversations start and questions are recorded by the BAs.  This gap is highlighted and logged and the team moves the process on to the next team.

Conversations ebb and flow on the conference bridge.   We find that it is very easy to slip back into current process as the pressure to deliver your piece increases.  Some team members realize that the process is now in current state and try to bring everyone into the future state but it is difficult.  There are a lot of variables and no systems to work with.

The entire day works like this.  We start and stop as gaps are identified.  What really works is having the business owners discuss their handoff process between each other.  They discuss and negotiate to determine what they both need to see.  This becomes the most valuable part of the entire exercise – and what proves to bring the teams together to start understanding each other’s process and have a vested interest in the entire process.  At the end we gather together and talk about the day and what went well and what could be done better. You can feel the positive energy in the room and the beginnings of understanding.

The gaps include the lack of systems, the lack of documents and information to work with, and staying in the future state.  The most successful part of the walk through is the conversations started with each business owner as they look at the hand off documents to the next team and realize the impact they have on each other.  Do their inputs and outputs flow and match?  What would be more effective?  The greatest value is seeing the teams working together and reasoning out how the new process would and should work.  Those conversations are the gems from the day.

>>Learn About Other Requirements Validation Techniques

There are many ways to validate requirements. Read these articles for some variations:

• How to Conduct a Requirements Review
• Have You Experienced Your Customer’s Perspective on Your Business Process?
• How to Get Meaningful Sign-Off on Requirements Without a Walk-Through

 “If a project is approved, do I still need to do enterprise analysis as defined in the BABOK? Do I need to do a business case?”

This question got me thinking about the distinction between creating a deliverable and facilitating the understanding that the deliverable is intended to produce. We’re not always brought in on a project when we “should” be and we aren’t always formally assigned to each step of the business analysis process. And we may or may not have the flexibility to start the project exactly the way we’d like. Oftentimes our management expects us to get started on requirements and would perceive work on a business case as backward momentum for a project that has already been approved.

At the same time, to be effective as a business analyst, you must understand the business case of the project in question. What is the scope? What is the budget? What are the key risks? How does the organization see the value of the project?

So, let’s consider some questions around the when, what, and how of the business case. When do you need it? What should you do? How can you approach business case work without creating a business case? And when should your ethics as a business analyst tell you that you should refuse to start in on the detailed requirements until you have one? These are all very different questions. But oftentimes our answers muddy the waters because we feel we need to answer all of these questions in one consistent way.

When do you need a business case?

A business case can serve many needs, but most often it is the document you use to help the project secure funding.  Funding might come in the form of a specific budget to deliver a project or an allocation of resources. The business case will justify the project spend and help the executive team make an informed decision about funding the project.

When should you do business case work?

You should always do a simple business case because you always need to understand the business needs and objectives driving your project. Even a one page statement of scope, goals, risks, and potential cost does wonders to align a team of people around what needs to be accomplished. A meeting to discuss these points moves things in the right direction. Meeting notes can serve as a business case in disguise for a particularly process-wary organization.

But common sense also says you should invest more time in your business case as the potential costs  and risks of the project increase. The more money you intend to spend, the more time you should invest in figuring out why to spend that money and what a successful project looks like.

What are the alternatives to a formal business case?

Any experienced BA will tell you they’ve been doing business case work for a long time even if it’s been called something else. In my career, we’ve done what have been called project scope documents, project charters, project “service requests”, and project proposals. These were all variations on the business case as prescribed by the organization I was working in at the time.

If your organization has no such document that is used to get a project started, there is a style to elicitation that allows you to answer some of the key questions. Taking time to understand what problem will be solved is part of enterprise analysis. As is a project kick-off meeting that discusses scope, benefits, and timeline. You can approach the business case in many ways, some formal, others very informal.

When in doubt, lead your teams toward a common understanding of the benefits, costs, and risks of a project as part of beginning your requirements efforts. You may not need to call this a business case, but you can be sure that you will be leading business case work.

>> Define Your Business Analyst Process

Join us for the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations.

Click here to learn more about the BA Essentials Master Class

It’s elegant.

It’s simple.

It’s even got a hint of beauty about it.

When you get ready to present it to your technical team for implementation, you get the answer you least expect…”that’s impossible” or it’s close equivalent “that will take us months” (when the budget is weeks).

As the business analyst, what can you do?

Well, one option is to let the project manager deal with it. After all, you did “your part” in figuring out the problem and the requirements. You can sit back on your laurels knowing you’ve provided a solution that the customer wants and stay out of the fray. But that’s not what you will do because it’s in your DNA to handle these things differently.

The best BAs do not simply define requirements, they create change and solve problems.

Now there are many ways to handle this situation and how you proceed will depend as much on the individuals on your team as your history with these people.

First of all…breathe. I mean take a really deep breath and relax. Let the tension of the situation out and focus on what you want. You want to help the business solve this problem, right? What’s the best way forward?

One tactic I like to use at a cross-roads between requirements and design is to take a couple of steps back. Oftentimes we get so excited about our own ideas and those of our customer that we forget to get the implementation team involved early enough. So by the time we’ve got it all worked out, they feel like all the intellectual challenge is gone. They push back because it’s easy to find issues with another person’s solutions when you have no ownership in them. Think about it, you’d probably do it if you were in their shoes too, just to spite you and your difficult BA self.

So, take a few steps back. Go back to the problem you are solving and get crystal clear on it as an implementation team. Encourage them to ask questions and help you clarify your thinking. It’s important you go into this activity with a truly open mind. You have to trust your implementation team, but also respect their intellects and believe that there is most likely a better solution.

Then start collaborating on solutions. Brainstorming sessions can work. List out 10 ideas. Pick 3 and dive a bit deeper. Be open to hearing what they have to say. Facilitate active discussion amongst them.

Only chime in if the solution is far off track from a real business requirement. And then say something like “I see the value of this idea, but I’m not sure how XYZ would be accomplished.”

Oftentimes after these sessions you’ll be surprised how close the team’s solution is to your own. It will be tempting to point this out. Don’t.

Remember, it’s never important that you know how to solve a problem. As a BA your hands are most often tied when it comes to implementation. What’s important is that your implementation team is confident they can solve a problem within the constraints of time and budget.

You can’t force people to code your solution.

You can lead them there.

You can facilitate discussions.

You can help find good solutions.

But you can’t force them. In the end, they have to own it or it’s simply not going to work.

>>Looking for More Support?

Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.

Click here to learn more about the Effective Conversations Template Collection

But your work as a business analyst is only half-way done – you are at step 5 of the 8-step business analysis process. The task at hand is to engage the technology team in actually solving the problem.  Without a focused and engaged IT team you’ve got a well-defined problem that may never be solved.

I hold a firm belief that everyone deserves the opportunity to understand the larger context of the work they are doing. This doesn’t mean that everyone will get it or even care, but the opportunity should be there.  It simply does not make sense to close off information about the value a project provides to an organization or the real problem you are trying to solve.

In even the smallest of projects, you will probably engage multiple people at different stages of the project…think about it…development leads, quality assurance, developers, database administrators, infrastructure folks.  While a project kick-off meeting is valuable and important, it won’t get the whole job done. Providing business context should become part of your DNA when talking with an implementer.

I am passionate about this today, because I stumbled over myself on this one last week.  A new member was added to the team to complete a relatively discrete data task.  I had nearly perfectly detailed requirements documentation about what needed to be done and we talked through them.  I completely forgot to step it up a level and communicate why we were doing this and what I knew about the data and users. As a result, the new team member spent a few hours wrestling with what he rightfully assumed was a real issue which, once we talked through it, had a simple solution. 

So, don’t get task oriented and forget to share your knowledge. Before walking through detailed requirements, take a moment to consider the perspective of the other person.  Are they new to the project?  Are they already engaged in a piece of the project to which this can be related?  What would you want to know if you were in their shoes?

>> Work Better With Technical Stakeholders

Here are some articles from the archive about working more effectively on the technical aspect of a project:

What To Do When a Developer Says “That’s Impossible”

Why Do We See Technical Skills in BA Jobs?

How to Help Stakeholders See What’s Possible

>> Learn the Business Analysis Process

An essential element of succeeding in a new business analyst job role is understanding the business analysis process. We walk you through an 8-step business analysis process in the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations, how to create a timeline for a new business analyst assignment, and be prepared to handle the more common issues BAs face on new projects.

Click here to learn more about the BA Essentials Master Class

Two questions to frame up the project:

1. What problem does this solve? Be careful not to describe the solution, but to fully articulate the problem or opportunity.  For a humorous read on this subject, try Are Your Lights On?: How to Figure Out What the Problem Really Is by Donald C. Gause and Gerald Weinberg.
2. What does the solution look like? Describe the potential solution to the problem in as much detail as possible.  It can also be a good idea to get together a small team of people who understand the problem (or better yet live with it everyday) and ask them what they think the solution looks like.

Three questions to evaluate the project.

1. What is the potential upside of solving this problem? What do you stand to gain or save as a result of a successful project implementation?
2. What are the risks? There are many ways to think about risks, so think about what will happen if you can’t implement this project successfully and what will happen if you do.  Could this project have an unanticipated side effect?
3. How much will it cost me to solve this problem? There are a variety of ways to find this answer (sending out an RFP, having internal staff provide estimates, etc). Be sure you think through the costs of managing any changes required to implement the new solution.  For example, upgrading your accounting system will involve revising a few business processes and retraining staff members.

Now, ask yourself, is the potential upside greater than how much it will cost you to implement? And is the project worth the potential risks? And is there anything better we could be investing in?