Author: Adrian Reed

Like many business analysts, I absolutely love structure.  I have particular favorite notations, and nothing is more satisfying than that feeling of creating an absolutely beautiful model where all the lines are completely straight and every part of it is neatly lined up.

I’ve been known to zoom in to 250% just to line up all of those arrows, right angles and connectors and I know I’m not the only one who does this!

Stakeholders are often taken aback at how something seemed so complicated when it was discussed verbally can be neatly articulated on a single set of diagrams (although they’ll never see the toil and sweat in the background!).

Whilst this kind of structure is extremely useful in the right situations, there’s something liberating about simultaneously embracing the unstructured.  It’s important that we note that structured models and diagrams are excellent at depicting particular things, they are like a ‘lens’ on the situation, but they deliberately omit other things.  A BPMN process model will show how work flows through and between organizations.  A system use case diagram will show the functional interactions between actors and an IT system.  Neither of these will show less tangible, messier but often equally important factors like culture, personalities, historical conflict and so forth.  This isn’t a deficiency of any of the models; it’s just that they weren’t designed for this.

Visualize the Mess

One approach that I am particularly fond of is the rich picture. I often find myself making sense of a situation by drawing it, and I find it even more valuable to get together with other stakeholders and ‘draw the situation’.  I find this often uncovers varying perspectives on what is happening, and even more importantly, what each stakeholder thinks ought to happen.  One stakeholder might bemoan that the IT systems aren’t fast enough, whilst another observes that there’s conflict between different departments because of the way that targets are set.  Another might make an observation that people are rarely trained, and in their view the IT system is fine, it’s just that people don’t know how to use it.  Layering on all of these different perspectives helps move us closer to a collective understanding of the situation we’re trying to improve.  Creating, or even better co-creating with stakeholders, a drawing representing the situation can cultivate a broad set of conversations which increase shared understanding. If you need some inspiration, do a Google image search for ‘rich pictures’, although mine are often very scrappy to start with!

One thing that can cause reluctance with approaches like this is that there is a complete absence of structure.  With a blank canvas, where should we start?  Yet this is the beauty, it doesn’t pre-suppose that anything is more relevant than anything else.  When using other types of models we are inadvertently steering things in a particular direction.  Starting with a process model implies that we are most interested in the process issues.  Of course, a process model can be used to discover other issues too, but it will likely steer the conversation in a particular direction.  Why not start without that structure, and introduce structure when more is known.

Another source of reluctance with less structured diagrams and visualization is whether stakeholders will be able to understand them.  This is an excellent question, however it’s important to consider the intent of the technique.  Visualizations such as rich pictures can be used purely as a device to create conversations and to make sense of a situation, with more structured artefacts following.  They absolutely can be shared, if this is useful, but in many ways the value is in the conversation and the creation of the picture, rather than in the artefact itself.  Not only this, details can be added to them over time as more information emerges.  They may help determine where to focus further analysis, and which types of more structured or formal models will be most valuable.

Overall, it’s important that we don’t prematurely impose structure on a situation. Embracing the unstructured, and incrementally building our knowledge on what works well and what needs improvement, whilst consciously seeking different stakeholder perspectives will likely yield dividends.

Back in the days when most BAs were able to work in offices, there’d be nothing I’d like more than a nice process discovery workshop. 

As analysts, we’ve probably all run those fantastic sessions with huge lengths of brown paper adorned with sticky notes carefully placed by stakeholders, each sticky note representing a task or sub-task.   It’s a great way of helping to uncover the complexity of existing processes and work out how they can be improved. Of course, today, these sessions are still fun but with many parts of the world in ‘lockdown’ it’s necessary to conduct the sessions remotely using a virtual whiteboard or modelling tool.

Whether the sessions are conducted remotely or locally, one thing that we should be aware of is that process discovery or a process improvement workshop tend to be ‘framed’ in a particular way.  Just using the word ‘process’ tends to imply that a certain viewpoint will be taken, and people may (quite naturally) have certain expectations on how the session will run and what the focus should be. There’s nothing inherently wrong with this, but it’s easy for conversation to become restricted and siloed.  It’s very easy to focus purely internally without thinking of what the customer actually wants to achieve…

Chasing Efficiency

Let’s take an example and imagine that we were examining the process in the claims department of a home (property) insurance company.  Rather than getting people to phone with their claims it would be much more efficient if they logged on and submitted their claim online.   That way they could upload photos of any damage (or scans of police reports in the case of theft), and have an interactive view of their claim as it goes through the settlement process. 

That sounds great, doesn’t it?  However, the conversation might soon extend to ensuring that a claim can only be submitted when all the necessary information is input.  Oh, and it’d be great if we had lots and lot of information up front—someone might suggest getting the customer to select the specific area of coverage or ‘peril’ that has occurred so that they can log the claim.  All of these things sound completely logical but when you add them all up you suddenly get a long and unwieldy form.  Plus, if a customer has (sadly) experienced a house fire, caused by lightening hitting the property, and their possessions were damaged by water from the fire brigades hoses do you really expect them to know whether to select “fire”, “lightening”, “flood” or “water damage” from the drop down menu?

Inject The Voice of the Customer

Of course, I’m using a deliberately extreme and provocative example, I’m sure no BA in their right mind would define the interface that way, but it illustrates a wider point.  If you only have internally-focused stakeholders in a process improvement session, you’ll get a process that is internally-efficient.  However it might be extremely inefficient for those who weren’t involved in its design, particularly external stakeholders such as customers.   And if we’re not building processes for customers, who are we building them for?

Part of the antidote to this is to inject diversity of opinion into the discussion, including representatives from groups that are often unheard or misrepresented.  In the insurance example mentioned above, clearly it wouldn’t be possible to have every customer present—but it would be possible to have somebody representing the ‘voice of the customer’.  This should be someone who has a close understanding of actual customers, ideally based on research and lived experience of dealing with their problems.  In some cases there might be two people covering two different perspectives—perhaps a front-line contact center worker bringing in their experience of customers’ likes & dislikes, and a marketing stakeholder who has conducted detailed research.  

It’s Always A BalanceIt’s Always A Balance

The old phrase ‘the customer is always right’ is only true some of the time.  I suppose we might update this to ‘the right customer is always right’, there will be some customers who have expectations that don’t match with the organization’s value proposition and also the external constraints that the business and legal environment places on them. I might want to open a bank account quickly, without showing my ID… but there are rules and regulations (ultimately for my protection) which mean this can’t happen.  

In many cases process design is a balance—the aim is to create a process that is more convenient and efficient for all relevant stakeholders.  To do this we need to consider and have them ‘in the room’ (virtual or real) when the decisions are being considered.

Business analysis often focuses on making a situation better. 

The challenge that I suspect many of us face is that it can be quite difficult to define what ‘better’ actually means, not least because different stakeholders often have very different perspectives.  People working on the front-line will have a different set of needs, fears and aspirations compared with the executives who are steering the ship.

We might, for example, be faced with the challenge of saving money by “improving process efficiency”.  This is the kind of broad remit that I suspect many of us enjoy taking on, it’s a woolly statement that enables us to utilize a whole range of strategic analysis tools to produce a range of different options for improvement.  We’d likely need to carry out investigations and obtain data to find out where the current inefficiencies are.  By focusing on the quantitative improvements that need to be achieved, the outcomes, we can start to understand the requirements and possible options for change.

This is certainly logical, but there is a pitfall awaiting the unprepared as there appears to be a very human tendency to ‘game’ measures and targets.  Want to look like you’re clearing a greater number of work items?  Split each item on your ‘to-do’ list in two: bam, productivity has doubled! Except of course it hasn’t.  The same ‘gaming’ happens a lot in organizations and in the processes that underpin them.

Imagine that a call center manager notices that the average call handling length has gone up from 3 minutes to 4 minutes. They feel that the calls could be cleared more quickly with a change to the processes that the call center workers follow, and perhaps with some changes to the IT system they use too. An analyst engaged at this point could rush ahead and scope out the IT change, look at streamlining the processes, and undoubtedly they could get the call time reduced…But would this really be a worthwhile problem to solve?.  Do we really care about how long the average call takes?  A simple way of exceeding the 3 minute target would be to simply cut every call off after 2:45mins, but I suspect this wouldn’t be what the sponsor really wants.  Which raises the question what are they really trying to achieve?

What Do They Really Want? Getting Beyond The TargetWhat Do They Really Want? Getting Beyond The Target

At the risk of repeating the important but somewhat clichéd line “start with why”, this is a situation where we really ought to question why the target is important.  Often people will fixate on a target, but investigation will find that different stakeholders care about the target for different reasons.  The ‘3 minute call length’ might be important for a whole number of reasons:

Advertisement

There would be many other perspectives beside, and for any change to be successful it’s likely to need to balance these different perspectives.

Understanding The Broader Situation Helps Us Broaden The Solution-Space

Understanding the true needs of our stakeholders helps us understand how they perceive the problem.  This will often open up new opportunities and solutions and help create a situation where there are more holistic discussions.  Perhaps we can improve the situation in a simpler, cheaper way than was initially envisioned whilst also better meeting their needs.   

All of this starts by focusing on stakeholders.  After all, business change is an inherently human endeavor, and business analysis is very much a ‘people profession’!

What are your views? Have you found particular approaches useful for eliciting and analyzing stakeholder viewpoints? I’d love to hear them. Be sure to connect with me on LinkedIn and let me know your thoughts!

The business and economic environment is incredibly tough right now, and I know from conversations with some of my connections that it’s a tricky time to be a BA jobseeker.

Competition is rife and it can be a challenge to know how to really shine in a job interview.

I recently facilitated a webinar panel session with Michelle Shakesheff and Saffron House (two senior BA managers) on this very topic.  This article summarizes some key takeaways from that session, with a few of my own thoughts added in for good measure.  It’s important to keep in mind that I’m based in the UK, so I’ll be reflecting on the expectations for job interviews here—I am sure expectations differ across the world so be sure to check out other articles and resources too.

Preparation Is Everything

When it comes to a job interview, preparation is everything.  There are many aspects that need to be considered, including the three ‘Rs’: Research, Role & Rehearsal.

Firstly, if you’re serious about working for a particular organization, then it’s crucial to research it.  This doesn’t have to be time-consuming, can be entirely ‘desk-based’ and is an opportunity to use a range of strategic business analysis tools.  You’ll want to check out the organization’s website, if it’s a large organization it’ll probably have an annual report.  What is its stated mission and strategic objectives? What are its stated values? Techniques such as VMOST can be useful for helping us to understand where a company is heading.  Approaches such as STEEPLE are excellent for brainstorming external factors that might affect the organization.  You might want to assess what you consider to be the biggest external opportunities and threats to the organization.  Utilizing these (and other) techniques alongside general research will provide a picture of the types of project that a company is likely to be undertaking.  You’ll pick up the language of the industry and organization, you’ll be well-placed to give specific answers to any strategic questions that the interviewer asks even if these don’t crop up, you’ll be well-placed to ask a relevant question about the organization’s strategy.  You’ll also get a sense of whether this is a company that you’d fit into and actually want to work for!

Secondly, there’s the role. Read every detail of the job description, person specification and whatever artefacts you can get your hands on.  Think back to your experience and be prepared to give an example for every skill or competency that is listed.   One senior manager I used to work with always advocated creating a table to systematically work through a job description, breaking it down into its component parts and adding an example against each.  If you do this, you’ll have the right example on the tip-of-your-tongue and won’t hesitate if a question crops up.  Here’s an example:

Finally, there’s the rehearsal.  I remember hearing polar explorer Allan Chambers speak over a decade ago.  He gave the sage advice ‘never take your body somewhere your mind hasn’t been’.  This applies for interviews too: take your mind to the interview room (or virtual interview room).  Imagine the types of questions you might encounter, formulate your response, and say them out loud.  What is the first thing you’ll say to the interviewer?  You’ll get different questions on the day, of course, but you’ll feel more confident and prepared and your answers will likely be slicker and well-informed.   This brings us neatly to our next topic, questions.

There Are No “Top Ten” Interview Question Lists

Although this might sound disappointing, there really aren’t any “standard” BA interview questions.  There might be patterns that crop up, but the questions are going to vary depending on the specific requirements for the role.  It’s also highly likely that there won’t be a “right answer” to any particular question—put yourself in the shoes of the interviewer and think what are they trying to understand from this question?  And don’t be afraid to ask for clarification.  It is genuinely hard to create unambiguous interview questions, and speaking personally, whenever I’ve been involved with interviewing candidates I take requests for clarification as an extremely positive thing. After all, BAs ought to be clarity-seekers!

It’s also important to answer the question that’s asked, not the one that you might have hoped the interviewer has asked.  I’ve fallen into this trap myself in the past, and I can tell you it doesn’t end well… However, if you’ve considered the different areas of the job specification and have examples for each area you’ll be well prepared to pivot and adapt on-the-fly.

A word of warning here. One trait that seems to be common amongst most BAs I’ve ever met (myself included) is the tendency to say “we”.  As BAs we work with others, and a success is a team success.  This is fine in most circumstances, but job interviews are a place to say I as well as we.   By all means discuss what the team achieved, but remember the job interviewer is going to want to know what you contributing.  Hearing “We created and prioritized a backlog” is interesting.  Hearing “I worked with the PO and coached them on the user story format. We experimented with different formats, but settled on user stories with some attached scenarios and acceptance criteria, which I wrote on behalf of the PO…” is more useful.  Precision is great.

Talking of precision, frameworks can act as a common language.  Being familiar with industry frameworks such as IIBA’s Business Analysis Body of Knowledge guide (or whichever is relevant for your context) can help.  Using industry standard terminology such as requirements elicitation, strategy analysis, requirements lifecycle management and many, many more besides will help ensure that you and the interviewer are on the same page.  Of course, it’s likely that the organization will have its own internal framework.  If you’ve been able to learn about that in advance through your research, then use those terms too.

Remember: An Interview Is Two-Way

It might seem like an interview is purely for the employer, but this is far from the truth.  It’s also you’re opportunity to assess whether the organization is a good fit for you.  Do the interviewers treat you respectfully?  Do they keep failing to turn up for the interview at the last minute without explaining why and then re-arranging?  Keep in mind that an employer that treats candidates without due respect may well treat employees similarly.

On the flip side, you may well find you get on fantastically with the interviewers, and all of your instincts are that this is the job for you.  Be sure to take the opportunity to ask the interviewer questions too.  You might ask them about the size of the team, the challenges they are facing—this might be a chance to showcase the research that you’ve done and ask them a specific question about the strategic direction of the organization and how it impacts the BA team.  Choose the right questions for the context, and use it to learn about the organization and the role.

Conclusion

Job interviews are nerve-wracking, but those nerves push us to prepare and perform well.  Remembering the three Rs: Research, Role & Rehearsal, thinking about the questions that might be asked and remembering an interview is a two-way process can help.

Imagine the scene: You’re working on a project where the intention is to follow an agile approach.

You’re a few months in and are happily writing user stories, but something prompts you to pause briefly and reflect.  You look at the user story in front of you and there are reams of detail. It is very similar to what a requirement would have looked like in a traditional business requirements document (BRD).  Yes, the format is different, and the story is written in a fancy agile management package that produces all sorts of fancy management charts and graphs, but when you step back you see a BRD split into functionally-decomposed story cards. In fact, you notice there is more detail on some cards that you’d have expected in a traditional BRD and the backlog is so huge it’s difficult to see the wood for the trees.

You conclude that yes, the work might be being delivered incrementally, but the delivery approach looks far more like a series of mini waterfalls than a truly agile process. There’s little discussion or communication, and a lot of documentation being produced.  You pause and ask yourself ‘how did we get here? We seem to be working in a hybrid approach which combines the worst elements of various approaches!.  Do you recognize this pattern?  If so, you’re not alone—I can still remember the shock when I first experienced it and it’s a pattern I’ve seen fairly regularly since. I’ve nicknamed one of the causes of this pattern silo left-shifting, and I thought I’d write this article to share my perspective and see if other BAs have experienced it too. Of course, your experience may be different!

Beware Silo Left-Shifting

I’m sure there are many reasons why this pattern can occur, but one relates to the way that a product (usually software) is being delivered.  In many cases, off-the-shelf packages are customized, configured and integrated by one or a number of third party suppliers.  Quite rightly, the accountability for the business analysis stays within the client organization (‘the requirements’) and the accountability for the technical design and implementation stays with the third party (‘the solutioning’).  There will undoubtedly be a desire to collaborate, but there will be a contract between the two organizations which determines that certain artefacts need to be produced, and there are certain contractual sign-offs etc, potentially with penalties for non-delivery.  Whilst we might not ever see the text of the contract, on the ground we feel its implications.  Collaboration can become difficult when the contract is divisive and coercive.  When the ‘pre-sales’ team within a supplier has had to concede on price to get the bid, the ‘delivery team’ (who may well be made up of different people) are stuck with the commitments their colleagues have made.  The pre-sales team may have even committed to a delivery date based on an initial understanding of scope that was ‘optimistic’ at best…

Imagine being a vendor who wins a bid and needs to get up to speed quickly, with a pressing contractual deadline.  You probably haven’t got team members spare, just ‘sitting on the bench’, so it takes time.  Yet the client wants to move fast, their project started months ago.  In fact, the client’s BAs are already writing user stories and the project manager and supplier management team at the client are worried about a lack of progress.  Your account manager is under pressure, and that pressure gets passed to a project manager which gets passed to the part-time developers who you’ve currently ‘borrowed’ to at least begin to get things moving.  They are doing their best but need the client-side BAs to slow down… there’s no time for the conversations that go alongside the user stories.  But it would be politically difficult to ask the client to ‘slow down’ as it would admit a lack of current capacity… so there’s a dilemma.  Then the silo left-shifting starts… Why not ask them for more detail?  And if there’s still not enough development capacity ask for even more…. Shift the work left! This will act as a useful speed-bump and seems constructive—it’ll be useful when the development team is up to speed.  It’s a small, seemingly insignificant change that incessantly creeps over time.

Crucially, this overlooks a key problem: The analysis and design/delivery activities aren’t synchronized, aren’t collaborative and two silos have emerged.  One team is moving at a faster pace than the other, and work is being produced just to act as a buffer between the two teams.  If the desire is to focus on agility, then surely the focus should be on communication, discussion irrespective of role?  There shouldn’t be ‘left-shifting’ between silos because there shouldn’t be silos in the first place. If there’s no conversation happening, and if everything is written out on story cards weeks or months before a developer sees them, then is this even the least bit agile anyway?  Aren’t we just ‘throwing it over the fence’ and haven’t we inadvertently crept towards a fairly linear, waterfall-esque delivery approach?

Calling It Out: This Is An Organizational (Not Vendor) Issue

It might sound like I’m having a pop at vendors here, and that really isn’t my intention.  Often vendors are stymied by contracts, estimates that have been taken as ‘commitments’ and all sorts of other constraints apply.  Ultimately, much of what I have described here is to do with the way the organization has managed its contractual relationship with the vendor.  There might be little we can do at a ground level to influence this.  However, there are several questions that we can ask, in particular I have regularly found the following useful:

1.What do you mean when you say ‘agile’?  ‘Agile’ is a word that appears a lot in the product and project world, but there are vastly different interpretations of what it means in practice.  I’ve learned to ask different stakeholders what exactly they mean by agile, and also whether they are happy with the potential implications of that.  Understanding whether different expectations exist over ‘estimates’, whether we really are going to have a self-organizing and multidisciplinary team, the delegation of decision making to product owners and so forth is important.   And calling out where differences in perspective exist.

2.How are we going to handle communication and documentation?  ‘Documentation’ is sometimes seen as a dirty word, but in my view it shouldn’t be.  The question here is how much are we going to document, and to what extent are we comfortable relying on communication? What will be documented after implementation?  Are we comfortable with a user story being ‘a placeholder for a conversation’, or are there contractual reasons that more information is needed up-front?  If there are, then let’s discuss that early.

3.Do we have the conditions to practice agile?  If the contract has been written assuming a waterfall delivery and if there’s no appetite to have collaborative cross-functional teams then perhaps we’re better off not kidding ourselves.  We could still be incremental or maybe even iterative; but let’s agree on an approach that works for the context.  Let’s not force an approach that doesn’t fit the context.  This is often an unpopular view, but let’s face it, if we march on ignoring the fact that the conditions aren’t right, we’ll just end up with a BRD split onto story cards anyway.  Of course the longer-term game here is to cultivate the conditions that will be conducive to agility, but when there’s a ‘burning project demand’ it can be worth separating this out as a longer-term objective.

I’m sure there are other questions too, and the questions above when taken with others can help create a conversation that avoids the fragility created when the silo left-shifting occurs.  Of course there are other causes of these issues, and this article addresses only one.  I hope you’ve found this article useful, and I’d love to hear your experiences too. Please do connect with me on LinkedIn and tell me your experiences!