Skip to main content

Author: Jamie Toyne

Jamie is an experienced Business Analysis Leader and community of practice builder, with over 14 years’ experience in transformational change in numerous sectors covering automotive, telco, financial services and more recently public sector. Currently interim Head of Business Analysis in a major UK Government department – Ministry of Justice (MoJ Digital & Technology) and formerly Head of Business Analysis of DWP Digital, where he led one of the largest communities of practice made up of 250+ BAs across the country. An advocate for developing others, he has previously launched the BA apprenticeship in DWP Digital, co-designed and launched an in-house Senior BA Development Programme and have successfully moved large communities to be fully virtual during the pandemic. Jamie is an active and influential member within the Cross-Government BA Leaders community, sits on the IS BA Level 4 Apprenticeship Standard review group, regular guest speaker as well as occasionally reviews new BCS publications.

What Do Business Analysts and Rockstars Have in Common?

Well, quite a lot actually. I’m not saying we’ve all got the swagger of Liam Gallagher, or the Ziggy Stardust fashion sense of Bowie. Nor, do we all play guitars, or know our way around a recording studio (although some do). And I’d confidently say, none of us are going around with diva-like demands or are smashing up hotel rooms. Most likely we’ll be littering the walls with post-its, hand-written using Sharpies.

But there are many aspects of being a Rockstar, that BAs do share in common. So much so, at Herd Consulting — we refer to ourselves as a Rockstar business analysis consultancy.

Here’s our top 5 reasons to convince you that good business analysis, really is rock ’n’ roll.

You wouldn’t see a Rockstar, ditching their genre. They love what they do. And that’s no different for most BAs. Sure, we could easily go on and become the next CEO of a major global firm, as many do. But they’re still using their inner BA and BA mindset day in, day out. Organizations, and the world around us is constantly evolving in its complexity. That means lots more challenges, and lots more opportunities. With our change know how, curiosity, and BA toolkit — we’re often best placed to take on the role of lead singer in any delivery team, as well as providing the backing rhythm when needed.




Now I’m not suggesting we should charge £100 a ticket to come along to one of our gigs (also sometimes known as workshops, show and tells, or presentations). But the most impactful BAs know who their audience is and engages with them. Equally as importantly, they keep them engaged. Maybe even some of their stakeholders and users, end up becoming fans too.


There’s no point recording the best songs if no-one is ever going to hear it. Similarly, business analysis shouldn’t be confined to just artefacts. It needs to be brought alive, it needs to be seen and heard. Without it, how will it ever challenge thinking, solve a problem, or guide and enable decisions to be made. Business analysts at the top of their game, make an event out of sharing their analysis, they make it easy and memorable to engage with. They provide recommendations or calls to action. Dare I say, it might even be the beginnings of a catchy hit.


Lyrics are a subjective topic, so we’ll steer away from the taxonomy of what good lyrics are, other than to say — the best usually tell a story. As professional business analysts, we’re always telling a story albeit likely with more precision and clarity than a song does. We’re discovering and writing a story (not necessarily just user stories), to guide delivery teams on what it is we’re doing and why we’re doing it. To have a clear specification of what’s required, and what’s not. Ultimately to ensure we’re all thinking about the same thing and are heading to the same destination.


Vinyl, cassettes, CDs, MP3s, streaming services. The world of music is constantly evolving. Remember music video channels? Rockstar’s are always having to keep up with the world of technology, and the changing commercial landscape around them. Business analysis is no different. Given most of us work in Digital or Change environments, we’re often at the forefront of progression and new thinking, whether that be Tech led or not. Therefore, to survive and thrive, we’re having to regularly invest in our knowledge and skills, broadening our experience, and expanding our networks.

Part 2 coming soon…


10 Principles for Working with Processes

Process: “a series of actions or events performed to make something or achieve a particular result, or a series of changes that happen naturally” Source: Cambridge Dictionary

When used correctly, process modelling is an invaluable activity, and along with process maps can be a powerful way of communicating of what is happening or should happen. At its simplest it helps us to decompose a process into a sequence of steps, with a defined start and end, and understand the various events that trigger specific actions. They can also help us to identify the users (‘actors’) and what their involvement is.

This provides the basis for analysis and optimization.

However, it can be easy to fall down the path of over-complication, especially when it comes to drawing up a process. Meaning that instead of being helpful, they can be time consuming and not fit for purpose.


Therefore, here are my set of 10 principles for working with processes, whether that be through a discovery activity to define an ‘as-is’ or through a design phase to build up a set of potential ‘to-be’ processes.

  1. Understand the purpose and why, before anything else — what are the models going to be used for? Is it to share with others to seek a consenus view on how something works? Is it to enable you to perform analysis activities off the back of? Is it to identify to a list of users (‘actors’) in an existing process?
  2. Consider your audience, and use notation frameworks sparingly. Notation frameworks such as UML and BPMN, can be helpful in the right circumstances. Especially as a ‘behind the scenes’ analytical aid. But, bear in mind, they often confuse many who haven’t had the same training.
  3. Focus on ‘just enough’, don’t let perfection be the enemy of good. Low-fi is generally fine, share early. Iterative process modelling is often the best form.
  4. Think about accessibility, when sharing process maps—not everyone may have a Visio or Lucid license. Consider the best tool so that everyone who needs to access it, can access it. If in doubt, export it as a PDF before sharing.
  5. Levels, know when you need them and when you don’t — you don’t need to model every level every time. However, you may need to understand something at a higher level first, before you can break it down further. All goes back to the purpose!
  6. Beware relying on previously documented processes — Beware of re-using or relying on the information in a previously modelled processes unless you have a robust process library, that is regularly maintained and with stringent change control. Processes have a shelf life!
  7. Consider sample size, like you would with any other type of research — there are documented processes, and then there are workarounds that users and customer actually do. Not everyone may approach or engage with it in the same way, so consider how many people you should speak to, in the same way you would with any other type of research activity.
  8. Talk to users who ‘do’ the processnot just the person who ‘owns’ the process. Expectations vs reality are often very different.
  9. Obsess over the events that trigger a process. They might be automated, such as triggered at a set time or upon a specific action being completed. They could be manual, triggered by an interaction from a user. Whatever, they are — invest time in understanding what they are, how they work and assess whether they’re helpful.
  10. Reference your contributors — its theirs, not yours — whether they’ve helped you to to understand how a current process works, or if they’ve been involved in designing an improved or new process. Not only is it polite, to reference those who you’ve collaborated with along the way, it‘s a helpful record when looking back. It may also prompt others, to suggest additional people who should be involved.




Lastly, remember processes are different to customer journey maps, service maps, business capabilities. Don’t be fooled into thinking that you don’t need to understand processes, if you have a good grasp on the customer journey or business capabilities. They provide different thinking and perspectives, and will uncover different information. Especially in discovery settings, processes are the closest you can get to understanding what is actually happening for all users involved. They also consider both visible and invisible triggers and events.

How can I make my work more visible as an Agile BA to my team and organization?

Photo by Lala Azizli on Unsplash

Something I often hear from other BAs working in multi-disciplinary Agile teams is that their work sometimes seems invisible. Or at least, less visible when compared to other professions. To put that in context, designers will likely be mocking up various designs that they develop and share iteratively. Devs regularly build and release new features. Content designers produce content to be published.

However, as BAs, especially in an Agile environment it can be difficult to see similar types of tangible output. Of course, you’ll have probably been involved in defining various backlog items and likely some modeling of the business or its processes, as well as facilitating numerous workshops to find out information. But these individually maybe aren’t as ‘visible’ or as tangible to many in the same way as when compared to some of the outputs from other professions.


This is where it can be useful to take a step back to think about our role. The primary responsibilities of Business Analysts aren’t to create designs, content, or code. Very briefly, we’re there to understand how things work, work out the gaps, break down complexity, align initiatives to wider org goals and help articulate a clear specification of what needs to be done. Ultimately this enables decisions to be made, challenges thinking, and helps solve problems. These collectively, enable value to be created, as well as being the basis for many other professions to create their stuff.

So, what can you do to make our work less invisible and more visible? Luckily quite a lot, here are some suggestions on how we can shine the spotlight more on what we do;

  1. Shout about your successes in retros — for example, talk about how your work enabled a particularly important decision to be made or how modeling a specific part of the business has identified something no one in the team was aware of before. Maybe add the impact of not finding this out.
  2. Show and tells, town halls, basically anywhere you’re showing the work you’ve done as a team in an open forum — if you’re currently in a Discovery or Alpha phase it could be sharing what you have discovered and what that has enabled, or if you’re in Beta, it could be mentioned that through undertaking something like root cause analysis has helped to find a solution to a specific problem.
  3. Introduce a BA Service Framework —that helps to articulate the value of business analysis as a set of services in the context of your organization. If you’re not familiar with the BA Service Framework, I’d strongly recommend checking out the BCS publication ‘Delivering Business Analysis: The BA Service Handbook’ by Debra Paul and Christina Lovelock. (I’ll be sharing more on this topic through my LinkedInprofile over the coming weeks).
  4. Work in the open (where possible)— if you’re in the office, this could be just placing analysis outputs on walls in your huddle spaces, or if you’re using collaboration tools such as Miro or Lucid — then make sure they’re open for all those in your team to see. Encourage comments and conversation about them, and don’t worry about them being perfect.
  5. Talk about tasks with a clear mention of why you’re doing it— whether you’re using post-its on a Kanban board, putting tickets on Trello, or just talking it through in a stand-up. Be clear on the task you’re doing and the purpose behind it. For example, ‘understanding X piece of legislation so that we design and deliver a compliant service’, is significantly clearer than just saying ‘doing research’.
  6. Write blogs and articles — if you can and time allows, get in the habit of sharing successes of how business analysis has helped to reach a consensus or challenged thinking on a particularly complex topic. Maybe it’s solved an important problem for your users. Whatever it is, look to use the appropriate medium to tell your story. This may mean publishing an article on an internal space such as an Intranet, or if the subject allows, publishing an external blog.

Thanks for reading, let me know your thoughts by getting in touch on LinkedIn. It would be great to hear if you use any of the approaches above and how you find them, whether you’ve been using them for a while or if it’s something new you’ve tried after reading this article. Similarly, please share if you have found another effective way to make your work ‘more visible’, that isn’t listed above.