Author: Adrian Reed

An Antidote

One of the things which makes being a BA rewarding and frustrating in equal measures are our stakeholders.

Barely a day goes by where we don’t spend time speaking with them, facilitating collaborative workshops with them, or even taking them for coffee. We talk a lot about ‘stakeholder engagement’ on projects, and we spend a lot of time understanding their needs and trying to achieve the ever-elusive ‘buy-in’. We carry out stakeholder identification, categorization and communication planning. We have a broad analysis toolkit, but all of our efforts will amount to nothing if we aren’t able to get the appropriate amount of stakeholder insight and support at the appropriate times. It is people that are at the center of successful change, so it is no wonder we spend a lot of our day seeking to understand and work with them.

Yet in this whirlwind of workshops and caramel macchiato coffee-shop conversations, it’s easy to forget what we actually mean by ‘stakeholder’. Whilst we intuitively know this, it is always worth taking the occasional moment to stop back and reflect. There are many definitions of ‘stakeholder’ out there, but one I particularly like comes from IIBA®’s Business Analysis Body of Knowledge (BABOK®) Guide:

“A group or individual with a relationship to the change, the need or the solution” (IIBA, 2015)

This definition is deliberately broad, and encompasses people that are inside and outside of the organization. There may well be stakeholders who have no power to influence the situation at all—but this doesn’t stop them being relevant. In fact, stakeholders who are highly interested or affected, but have low power or influence are often crucial for us to understand—and there’s a risk that these voices get marginalized.

We have probably all seen stakeholder analysis tools such as the ‘influence/impact’ grid. These useful approaches encourage us to consider the relative positioning of those with an interest, and can be helpful in developing engagement and communication strategies. Yet whilst we talk a lot about stakeholders how often do we talk about stakeholding?

Knowing Why They Care

One of the reasons that we are interested in seeking collaboration and participation with our stakeholders is that they hold a stake in the situation. It is easy to get caught in the trap of thinking about this purely from our perspective. We might think “What is it that they know about the situation that they can tell us?” or “How can they contribute towards the project?”. These are interesting questions to ask—but how often do we seek to understand their stake? How often do we seek to understand why they are a stakeholder in the first place?

If we probe beyond the surface we might find they have a personal as well as an organizational stakeholding. Understanding their professional, as well as personal interests helps us to better empathize with them and understand their perspective. Here is an example:

Here we can see that Natasha is a key stakeholder and she’s tried to initiate her own ‘pet project’ previously, which might well affect her perspective on this project. The way that management bonuses are paid might well also affect her view. The fact that she personally has to deliver the news of any organizational restructure may well give her a useful and different perspective too. Many of these things would have been easy to overlook, but might lead us to conclude that Natasha has a much higher level of interest than we initially thought. It can help us to better plan our engagement and participatory approaches, ensuring we are mindful of our stakeholders’ needs.

Thinking about stakeholding doesn’t have to be a formal activity, it can be as simple as ensuring we think to ourselves “Why do they care? What is their organizational and personal stake here?”. This can lead to us better understanding and empathizing with our stakeholders, and better understanding conflict when it arises. This is time well spent!

Identification and management of risks is a crucial activity at every stage of the business change lifecycle.

Risks come in all shapes and sizes, but generally speaking if we can predict them and spot them early we have a better opportunity to formulate an appropriate response. Many projects will have a centralized risk log that is ‘owned’ by the project manager—and it’s easy to assume that project risk management is entirely within the domain of the PM. After all, they have the log, surely it’s their responsibility? Well, yes and no….

Depending on the organization, the mechanics of keeping the risk log up to date, identifying risk owners and appropriate management action may fall within the remit of the PM. These are crucial activities, yet the reality is that effective management of project risks relies on collaboration. Risk really is everybody’s business.

“The effect of uncertainty on the value of a change, a solution or the enterprise” (IIBA, 2015, p.452)

This definition provides a useful lens through which to discuss risk. As BAs we often have a unique perspective, as we’re able to view the top-level  ‘end-to-end’ macro-view as well as being able to zoom into the detailed micro-view. Whereas a project manager may be best placed to perceive risks to time and budget (as they will look across all streams of work), they may require our input to identify detailed risks that apply to the value of the change. Working as a team, bringing in the relevant stakeholder expertise too, we’ll get a much more holistic view.

This definition also makes the important (but often forgotten) point that there are risks that affect the ongoing operation of the enterprise as well as those that affect the efficiency or effectiveness of the change initiative itself. Take the following examples:

Here we can see that the first risk affects project delivery. A cutting-edge process is being designed, so there is little knowledge of how long it will actually take to build. There are many ways this risk might be managed, including looking at an incremental delivery style that will enable us to test and learn as we progress. However, a key point here is that when the project is complete, this risk evaporates. It no longer needs to be actively managed.

This is in contrast to the second risk, which will need attention throughout the project but will also need to be managed once the process moves into a ‘business as usual’ state. Throughout the project we’ll need to be considering whether there are associated processes or requirements which can help to minimize the ongoing risk (for example, it’s likely that there are a set of implied ‘monitoring’ requirements, and a set of disaster recovery processes that need to be captured). It’ll be important to find someone to ‘own’ this risk once the project has launched. With our ability to ‘zoom out’ to examine the macro level, and ‘zoom in’ to see the detail, we have a lot to contribute.

These are all areas where we can help. As with so many topics, risk can be viewed from multiple perspectives, and when we take a collaborative approach we see much more.

References:

IIBA® (2015) A Guide to the Business Analysis Body of Knowledge® v3, Toronto, International Institute of Business Analysis

It’s often said that we live in a fast moving world.

The external environment that our organizations operate within appear to be in a constant state of flux and it is more important than ever that we have the ability to quickly spot and respond to environmental changes.   As someone who lives in the UK this feels especially relevant right now. As you may be aware, the UK is scheduled to exit from the European Union in just a couple of weeks, yet there is a lack of clarity on exactly how this will work or what it will mean for business. What is certain is that ‘Brexit’ will have a major impact on many projects that are in flight, but more importantly, on the ongoing processes and operations for many organizations. Wherever you are in the world, I am sure there are many external uncertainties that are relevant for your organization, and it’s likely that this leads to additional demands and pressures on your projects too. It’s crucial that we identify and respond to these factors.

External factors can be examined at many levels. When planning organizational strategy, it is crucial that they are considered and the chosen strategy either aligns with or seeks to influence them. It is equally crucial to consider them when deciding upon a change strategy for a project, and it is important that attention is paid to them throughout the project execution. At a project level, we can consider external environment analysis to be our ‘radar screen’ which enables us to see enablers or constraints that are beyond our immediate control. The earlier we can see them, the more time we have to consider how (or whether) to respond. Perhaps we spot a new emerging trend, enabling us to ‘pivot’ our project and deliver a prototype early to test the trends relevance for our product. Organizational agility hinges on our ability to detect these changes and have the capability to seize them when appropriate, and this is an area where business analysis can really help.

Looking Outside: The ‘STEEPLE’ Technique

There are many analysis techniques out there that can help us understand our external environment. One that is particularly helpful at both a strategic and project level is ‘STEEPLE’. I always think calling ‘STEEPLE’ a technique is a bit of a misnomer; it is really just a mnemonic. We can consider it a useful checklist of potential topics that we should pay attention to. STEEPLE stands for:

• Social
• Technological
• Economic
• Environmental
• Political
• Legal
• Ethical

When conducting a STEEPLE analysis, it’s important to focus on factors outside of the immediate sphere of control of the project/organization.   Each of the categories is ultimately a trigger for discussion—it can help us to elicit information from stakeholders, or give us a direction in which to carry out document analysis, benchmarking and other types of research. There will inevitably be some factors that straddle more than one category, and depending on the context we might even decide to add other categories. As with any technique, its success relies upon its flexible application.

Items that appear on the STEEPLE list might help us ask questions that influence our requirements (e.g. ‘there’s an emerging trend for mobile payments—do we need to consider this for our product?’), might constrain requirements (e.g. ‘I notice that there’s a new piece of data legislation due to come into force soon—do we need to ‘future proof’ ourselves now?’), or even enable us to think about new solutions (e.g. ‘There’s a new type of technology that might be suitable, shall we compare it against our requirements to see if it’s an option?’).

Of course, external environment analysis is most useful when it is a collaborative activity—it is much less useful when done in a vacuum. We might find that this analysis has been undertaken by an executive or product owner. This is extremely positive, as we can ‘tap into’ that knowledge and perhaps add anything else that we discover. Whether we own it or facilitate it is less important than ensuring that the thinking takes place. As BAs we have so much to add to this thinking, involving ourselves in it pays dividends.

I suspect most people reading this article would agree that business analysis is hugely valuable throughout the business change lifecycle.

Whilst some stakeholders might perceive business analysis as primarily being related to the definition of ‘requirements’, the reality is that the discipline is much, much wider than this. As well as being involved in the important detail of defining requirements, there is much valuable BA work to be done before the project starts.

In fact, in my experience it is often the embryonic ‘pre-project’ phase where initiatives start to show problems and start to go off the rails. It is very easy for stakeholders to push ahead without a full understanding of the problem or opportunity that they are looking to address, often being blindsided by a solution that looks so perfect! Of course, without having undertaken sufficient analysis we’ll be unable to determine whether that expensive and shiny solution will actually achieve the outcomes that the stakeholders desire. We risk getting caught up in the perfect storm where a project becomes about delivering a particular solution or IT system rather than focusing on achieving a set of business outcomes.

Pre-project problem analysis is a crucial discipline to help avoid these situations occurring, and there are a range of useful tools in our toolkit to enable us to engage with, and understand, ‘messy’ problem situations. From rich pictures, to multiple cause diagrams, fishbone diagrams and many, many, more—we can work with stakeholders to understand root causes prior to shortlisting potential solution options. This work needn’t slow things down—in fact, if it is done well it is often an excellent way of clarifying scope so that the detailed work can accelerate off on the right track (as opposed to stalling at the start line).

Of course saying pre-project problem analysis is useful is one thing, getting the remit to actually do it is quite another. This can be exacerbated by organizational structures and processes that do not necessarily (yet) recognize the value of early BA engagement. However, if there is one thing about us BAs, we are very tenacious! Given the right tools and forethought no brick wall is completely insurmountable.

Earning the Right

One relevant expression that I’ve heard some practitioners say is “credibility comes through delivery”. This succinct statement is at the root of our early engagement challenge—if people haven’t seen the benefit of having a BA engaged up-front, then why should they believe it? This creates a ‘chicken-and-egg’ scenario—without up-front engagement, we can’t prove its value. Without proving its value, we can’t get the engagement. However, with some stakeholder rapport and some selective risk-taking, this is a situation that we can build upon.

Firstly, it’s really important that we get our foot in the door during those early discussions. One way of approaching this is to put ourselves in our stakeholders’ shoes: Ask “what would worry me?”, and “what type of service would help me?”. Often, executive stakeholders are busy, and they’ll find meetings a real bind (they might even have a mug which says ‘I survived another meeting that should have been an e-mail!’). This is one area where analysts can really help: We can offer facilitation as a service for their ideation and strategic meetings. Imagine this from the stakeholders’ perspective: They get an expert facilitator who lightens the load, works with them to come up with a compelling agenda and brings a ‘scribe’ along to write up the output of the session. They get a high quality meeting output with very little outlay. From our perspective, we get to use our facilitation skills (which, let’s face it, is really fun), but more importantly we are there when early pre-project discussions are being had. We can introduce a range of techniques throughout the workshop to encourage both ‘divergent’ as well as ‘convergent’ thinking so that there isn’t an early fixation on a single solution.

If the initiative goes ahead, we then have the relationships with the key stakeholders and we’re the natural change partners to help our stakeholders accelerate forward. We’ve shown them the value of utilizing BA skills in a single meeting—if we’ve ‘wowed’ them there, imagine what we can do in a whole project. Over time, the reputation of the BA team will grow internally and more and more people will see the benefit, and early engagement will eventually become the norm.

Of course, this is a long-term game, but it can start with a single conversation and a single meeting. And it’s well worth while considering!