A Business Analyst’s Approach to Lean Strategy Execution

Business stakeholders want projects to deliver fast. They often come to the project team with a clear view of the solution, expecting a quick start and not leaving much room or time for challenging and proposing alternatives. However, this mindset carries an important risk: building the solution does not guarantee business value.

As a business analyst, we have the analytical skills and corporate overview to put the proposed solution in perspective and identify potential pitfalls hindering us from delivering value. Acting as the bridge between stakeholders and implementation, we have the responsibility of making stakeholders aware of this. It is our job to mitigate these risks.

How can we go about this?

First listen, really listen.

Suppose you are working on a school project. The school intends to introduce tablets.

 “We need you to introduce tablets in class. Every student must have a tablet containing a PDF version of the books and an app for exercises.”

If you ask why, the answer is obvious:

“This will help our students achieve better academic results.”

What we have here is a very detailed solution and a very high level goal. The solution is very restrictive and leaves little room for alternatives. The goal is very abstract and difficult to act upon. It’s not providing much guidance. So we are inclined to start questioning. Don’t.

In your stakeholder’s mind, this makes perfect sense. The goal is relevant, perhaps even strategic, and the solution could very well be a useful improvement:

“We need tablets because they will help us improve academic results.”

So stop your thinking and start really listening to your stakeholder. You can try to find out several things:

• Is academic improvement the trigger for the idea, or is there another trigger?
• How does your stakeholder see electronic books and exercises improve academic results? Which books and exercises? Where and when does he expect the students to use their tablets?

By asking open questions and testing your understanding of your stakeholder’s reasoning, you will bring new insights to the surface. For example:

• Students will be more engaged for certain types of schoolwork when they can use tablets rather than paper or computers.
• Tablets enable students to collaborate without being physically together.
• When students work together more frequently, explaining each other how they understand the lesson material, academic results will improve.

So accept the initial requirements and proposed solution as the starting point of an interesting conversation. A conversation in which you do most of the listening, trying to find out both the underlying concerns and how the stakeholder believes his solution suggestion will contribute to tackling these concerns.

When you talk, you are only repeating what you know.
But if you listen, you may learn something new.

— Dalai Lama

Tangible goals to link solution and strategy

The above conversation gives you a clearer view on the goals your stakeholder is trying to achieve with his solution suggestion. What value is the solution supposed to create? What changes is your stakeholder aiming for?

In the school example, the stakeholder wants to improve academic results by increasing the amount of collaborative learning. This outcome, “increase collaborative learning”, is more tangible than the very abstract “improve academic results”. High-level goals are fine to start with, but more tangible goals are important for several reasons.

• They define when a change project will be considered a success.
• They help us discover, define, compare and select specific solutions.
• They give team members a tangible purpose to work towards.

The first point is important: a project delivers some output (like tablets with some lesson material and an app with exercises), but this output is not the reason we do the project. We do the project because we want to make a change. So it is essential to define this change explicitly: what do you want to change, by when and by how much? The goal of the project is the change you aim to achieve, specified as a SMART target (specific, measurable, attainable, relevant, time-bound). The project output is only a means to realise this change.

The goal of a project can never be the output produced by the project.

In this step, you specify a tangible link between the change project and the overall strategy. Introducing tablets (proposed solution) is supposed to increase collaborative learning (project goal), which contributes to improving academic results (strategic goal). By making this link explicit and SMART, you define an objective way of measuring success and adjust the solution approach if needed.

So, when will your stakeholder consider the change a success? It’s up to the stakeholder to set the goals, but it’s up to you to make the conversation happen and get the right information out of it.

The benefits map below shows how refined goals and solutions can fit together in the school example (including an additional goal and measure of success that popped up during the conversation with our stakeholder).

Expose the link between goals and solutions

During our conversations, we not only refined the goals of the project. We also learned how different aspects of the solution will contribute to these goals:

• Students will be more likely to work on a tablet than on paper or computer. Tablets will engage students, leading to better academic results.
• When students can collaborate online, they will collaborate more because they don’t need to be physically together outside of school hours.

By rephrasing these requirements, you can separate what your stakeholder wants from how he wants to do it:

• We want to increase student engagement (goal) by letting them use their preferred tools (what). Introducing tablets is one such tool, and thus one of the many possible solutions (how).
• We want to increase collaboration (goal) by enabling students to collaborate outside the classroom (what) using an online tablet app (how).

I like to call the “what” between goals and solutions enablers: they outline what enables us to achieve our goals, without giving away implementation choices. It’s essential to describe them in a solution independent manner, so it becomes clear the initial solution suggestion is only one of many possibilities.

Carefully specifying these enablers between the goals and the solutions on the benefits map highlights why we believe our solution is a good one, helps identify gaps and creates room for alternative solution options (like smartphones or WhatsApp).

First test, then invest

We now have a view on how different parts of the solution and different alternatives will contribute to our goals. However, if you carefully look at the interconnections between solutions, enablers and goals, you will discover some important assumptions. For example:

• We believe that collaborative learning will help improve academic results.
• We believe that students will collaborate more intensively and more frequently if we facilitate or trigger out-of-classroom collaboration.
• We believe that students like to use tablets in their daily life, and that we can leverage this to increase their engagement for schoolwork.

It’s clear that, while our trail of thought (as visualised in the benefits map) makes a lot of sense, it contains quite a number of assumptions. Implementing (part of) a solution before validating at least some of these assumptions could be a costly investment based solely on our beliefs. This is where lean thinking comes in.

The big question of our time is not Can it be built? but Should it be built?

— Eric Ries

Essentially, lean thinking is about reducing waste. Lean start-up techniques are focused on learning at maximum speed with minimum investments during product or service development: you are doing the least amount of work needed to test assumptions about your product or service and its customers. What can we do, in our case, to test our assumptions with as little up front investment as possible? We should rephrase our assumptions as falsifiable hypotheses: describe them as a test that will give you a clear true or false. For example:

• Does research significantly demonstrate collaborative learning improves academic results?
• Do students find it cumbersome to pull out their laptop for doing schoolwork? Do students with a tablet have more spontaneous conversations about their schoolwork?

Performing these tests will let you find out if your assumptions hold, and thus if your solution is fit for its purpose.

Summary: four steps to lean strategy execution

In summary, making some time for the four steps outlined here will give you a better starting point for any change project:

• Really listen to your stakeholders. Before challenging them, make sure you understand their reasoning on how the proposed solution will work and create value.
• Clearly describe the goals of the change initiative: when will your stakeholders consider it a success? Make sure the goals are specific enough to act upon.
• Specify how to proposed solution will enable your stakeholders to achieve their goals. Describe these enablers in a solution independent manner, in order to create room for alternative options.
• Highlight the assumptions on how the solution contributes to the goals. Turn these assumptions into falsifiable hypotheses and specify how you will validate them.

I find the benefits map a powerful tool to support these steps in an iterative process. It’s a very visual way to highlight the links between solutions and goals, including potential gaps. It’s even more effective when you create or refine it together with your stakeholders, for example using post-its. This will trigger further exploration of both the solution and the problem space before starting project execution.

Feel free to comment below and let me know how this approach worked for you! And if you want to know more on how to do this in practice, get in touch through LinkedIn or email.

References

• This is an article I originally wrote early 2016 that I have reposted here for easy access. I may revisit and update it in the future, but I think it’s still relevant. 🙂