The B2B Podcast Index
Index
All categories
MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
MethodologySubmit
Best of:MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
An independent project byFame
SearchBest episodesGuestsInsightsMethodologySubmit a podcast
Index/Ops/BA Brew
BA Brew artwork

How to Improve Digital Change Collaboration: An Introduction to Service Frameworks (feat. Chris Pyatt and Victoria Banner)

BA Brew · 2026-06-12 · 27 min

0:00--:--

Key moments - from our scoring

Substance score

40 / 100

Five dimensions, 20 points each

Insight Density8 / 20
Originality7 / 20
Guest Caliber10 / 20
Specificity & Evidence9 / 20
Conversational Craft6 / 20

Service frameworks describe the range of services offered by a profession, providing a shared language and baseline for collaboration in complex change ecosystems. Chris Pyatt and Victoria Banner discuss how business analysis, business architecture, and service design frameworks - particularly those developed by Deborah Paul and Christina Lovelock - help organizations clarify roles, reduce territorial disputes, and create opportunities for interdisciplinary collaboration. The BA service framework includes situation investigation, problem analysis, feasibility assessment, business case development, business process improvement, requirements definition, business acceptance testing, and business change deployment. Similarly, the business architecture framework encompasses blueprint development, operating model work, and strategic roadmap development, while service designers contribute situation investigation, problem analysis, service definition, service experimentation, and service deployment. Rather than treating techniques as proprietary to specific professions, the hosts advocate reframing frameworks as collective toolkits - enabling business analysts to use value streams or service blueprints when appropriately skilled and governed. Both speakers share practical applications: DWP customized their BA framework for agile product teams, using it for capability assessment and learning and development prioritization; Victoria's organization leveraged the framework for recruitment, defining RACI models, and coordination across enterprise architecture disciplines. The key insight is treating frameworks as living documents adapted to organizational context, not bureaucratic constraints.

Key takeaways

  • →Service frameworks define shared services across change professions, reducing role conflict by reframing professional boundaries as collaboration opportunities rather than territorial disputes.
  • →Customizing published frameworks to your organization's language, operating model, and governance creates a practical tool for capability assessment, recruitment, and learning and development prioritization.
  • →Using service frameworks as lightweight heat maps helps identify capability gaps and ensures BAs develop breadth across all service offerings, from early-career requirements definition to strategic work like roadmap development.
  • →Treat change profession toolkits as collective resources - techniques like service blueprints and value streams should be available to any qualified practitioner following local standards, not restricted by professional silos.
  • →Successful framework adoption requires visible communication and engagement with teams to co-create the framework, then making it accessible and visually compelling so stakeholders actively use it, not buried in SharePoint.

Guests

Chris PyattVictoria Banner

Topics in this episode

Requirements definitionDWP (Department for Work and Pensions)Business Analysis Service FrameworkBusiness Architecture Service FrameworkService Design Service FrameworkDeborah PaulChristina LovelockSituation investigationBusiness process improvementBusiness acceptance testing

Questions this episode answers

What is a service framework and why do business analysts and architects need one?

A service framework describes the range of services offered by a profession - for business analysts, this includes situation investigation, requirements definition, business process improvement, business acceptance testing, and business change deployment. It provides a shared language with stakeholders, helps professionals understand the full breadth of their role, reduces role conflict, and creates a basis for measuring service quality and capability development.

How do business analysis, business architecture, and service design service frameworks overlap?

All three frameworks include situation investigation, problem analysis, feasibility assessment, and business case development, though they may use different tools, techniques, or language. Business architects add blueprint development and strategic roadmap work; service designers add service experimentation and deployment. The overlaps create opportunities for collaboration and clarifying who leads each service in your organization.

How can organizations use service frameworks for talent management and career development?

Frames help professionals see the full range of services they could develop expertise in, plan skill-building, and identify gaps in their experience. Managers can use frameworks for succession planning, recruitment (targeting candidates with specific service expertise), and prioritizing learning and development programs based on organizational capability gaps.

What should organizations avoid when implementing a service framework?

Avoid burying the framework in a document where no one uses it - successful implementation requires visible communication, team co-creation, and making it visually appealing and succinct so stakeholders and practitioners actively reference it. Also avoid using frameworks to create rigid role silos; instead, use them as starting points for discussion and collaboration across change professions.

How do you customize a published service framework like the BA or Business Architecture framework to your organization?

Review the published framework with your team, identify which services you deliver and how they fit your operating model (for example, DWP combined acceptance testing and transition into 'support and enable solution delivery' for agile teams), adjust language to match your stakeholders' terminology, and map existing team activities against the framework to spot gaps or out-of-scope work.

What our scoring noted

Our reviewer’s read on each dimension, with quotes from the episode.

Insight Density

8 / 20

The episode surfaces a handful of genuinely practical applications of service frameworks (capability heat-mapping, recruitment gap-filling, cross-profession overlap identification) but is heavily padded with career reminiscence, mutual affirmations, and definitional restatements that reduce the ideas-per-minute ratio significantly.

we can consider almost like a heat map really, the different LSD offers that we have and how those map to the service framework. And therefore, are there gaps, are there areas where we're not providing the right sort of support
we've also used it to help with recruitment you know we were we were light on a certain area and and you know the team that was in place didn't have experience of x so as we've gone to market

Originality

7 / 20

The cross-profession service framework alignment angle - showing BA, business architecture, and service design overlap to enable collaboration rather than turf wars - is a moderately fresh framing, but the underlying advice (reframe conflict as collaboration, define what you don't do, use shared language) is fairly standard professional development fare.

I'd really rather we reframe some of those role conflicts as opportunities for great collaboration rather than getting into a bit of a turf
a service blueprint is only ever written by someone who is a service designer and I think service designers are very well placed to build service blueprints They have expertise But I also think that it a technique

Guest Caliber

10 / 20

Both guests are working practitioners with genuine organizational depth - Chris has embedded the framework across multiple large organizations including DWP and presented at the European Conference; Victoria co-authored a book on business architecture and has applied the framework in a scaled enterprise context. They are credible but mid-level practitioners rather than senior transformation leaders.

currently at DWP, we use a BA service framework and we've adjusted some of the services to fit better the nature of the, many of our BAs are deployed, embedded into agile product delivery teams
we've recently revisited it based on the work that me and you have done in the recent publication of Business Architecture Comprehensive Guide

Specificity & Evidence

9 / 20

There are some genuine specifics - DWP named, 120 BAs versus 5 business architects cited, a concrete example of merging two services into 'support and enable solution delivery' - but the episode has no outcome metrics, no dollar figures, no timeline data, and the examples rarely go deep enough to be directly replicable.

in my organization we have 120 ish business analysts who are embedded in change activity across the organization there are five business architects
we amalgamated the the latter two services around acceptance testing and transition and release into something we framed as more support and enable solution delivery, which sort of covers supporting solution creation, acceptance, transition, release, and impact measurement

Conversational Craft

6 / 20

The host is knowledgeable about the subject matter but conducts a supportive PR-style chat rather than a probing interview - no claim is challenged, questions are open invitations to expand, and effusive praise ('brilliant brilliant,' 'what an answer that was, I'm very impressed') repeatedly interrupts the flow without adding substance.

what an answer that was that was a brilliant answer Chris I'm very impressed
brilliant brilliant some some brilliant collective advice

Conversation analysis

Computed from the transcript - who did the talking, and the words that came up most.

Most-used words

service61services36framework35analysis17different17change16chris13organization13architecture13team12frameworks10useful10organizations10terms10role10development10

Episode notes

Service frameworks are a powerful yet often overlooked tool that can fundamentally change how teams understand, collaborate, and achieve outcomes. In this episode of BA Brew, Jonathan Hunsley from AssistKD is joined by Chris Pyatt and Victoria Banner to discuss how service frameworks help business analysts, business architects and service designers clarify their value, improve collaboration and navigate complex organisational change ecosystems. The discussion covers: What a service framework actually is - and how it defines the value a role delivers Why business analysis, architecture and service design overlap more than we think How frameworks create clarity on roles, responsibilities and boundaries The role they play in reducing confusion, conflict and duplication across teams How they support career growth, capability building and even recruitment decisions Practical advice on getting started - and why you don’t need to build everything at once Whether you are a business analyst, business architect, service designer or other digital change professional, this episode offers practical advice for improving conversations and outcomes.

Full transcript

27 min

Transcribed and scored by The B2B Podcast Index.

Hi, welcome to BA Brew. I'm Jonathan. I'm Chris. And I'm Victoria.

Today we're going to be speaking about a subject that I am exceptionally passionate about. I want the world to know about these things. We're going to be talking about service frameworks, what they are, why they might be useful, and how you could maybe get started using what we're going to describe as a service framework. So I'm going to go to you first, Chris.

For our listeners, for our watchers, what is a service framework? And then have you got a little bit of insight into what you've been doing with one? And I know you've done lots with the business analysis service framework, but what is a service framework, Chris? Yeah, so a service framework describes the range of services that are offered by a particular profession.

So in this case, the business analysis service framework describes the services that business analysts offer to their teams, to their stakeholders and to their organizations. and this is particularly useful because business analysis has always been a bit tricky for other professions to understand and taking more of a service lens on it and describing it in terms of the services we offer in order to co-create value with our stakeholders that can be a really helpful way of describing what we do and why and how those services can can help them so the service framework provides a base set of services that you can then individual BA teams can customize to fit their organization and their ways of working.

Brilliant, brilliant and they're quite well established in the business analysis service business analysis profession given the work that Deborah Paul and Christina Lovelock and others have done and Chris you've spoken about the use of the service framework at the European Conference and others have spoken about it but it's quite it's quite a mature thing in business analysis but not so mature in some of the other change professions um Vic you're um you have a service framework um where you work for business architecture I understand is that is that right yes we do it's um it's a concept that's been around in the business architecture function for quite a while.

We've recently revisited it based on the work that me and you have done in the recent publication of Business Architecture Comprehensive Guide. Really to bring it in line with that business analysis framework and that thinking, it's really helpful for us, particularly when we're engaging with senior leaders in the role of business architecture, to articulate the value that we add, the services that we offer, and I guess the boundary of the role as well, which can get confused with other disciplines.

So it's been particularly helpful for us in our day-to-day work. Yeah. So overview, it's a start point for defining what services do you offer and that's really useful for the internal team, but also to external stakeholders. When we're talking about the change professions as a whole, what really buys viewers is it's really hard to deliver change.

It's really complex. And if we've got an absence of shared understanding in terms of what are we doing and who's doing what, that is a barrier for us delivering in these complex ecosystems our change initiatives. So the intent is that they are used as a start point for a discussion to build a shared understanding about the services that are being offered by change professionals and that they're amended and adapted to the context. The other service framework I want to bring into the discussion is the service design service framework, which is relatively new.

But it's an interesting one because as with business analysis and business architecture, the service designers are also, in my opinion, doing situation investigation and problem analysis and feasibility assessment of business case development. They might use different tools and techniques. They might use a slightly different language, but essentially they're offering those similar services, but coming at those services from a slightly different angle. If we can see that overlap between the business analysts, the business architects, and the service designers, in the delivery of those services, it gives an opportunity for us to say, what's our standard in our organization for how we do this work?

And a basis for collaboration across those professions for those service outcomes. The service designers get involved in some organizations' customer experience analysis. In other organizations, that service is solely the domain of the user researchers. So there's a difference there.

Service designers get involved with service definition or requirements definition. But it wouldn't make sense if the requirements engineers, business analysts, were working with the service designers when they're defining their services, stakeholderistic view. And then the service designers get involved in two other core services, service experimentation and service deployment. and then stakeholder engagement underpins all of the service frameworks because whatever service we're delivering we're we need to engage our stakeholders um so hopefully that's given the listeners a little bit of an overview of um what are the service frameworks Vic did you want to give a little bit more detail on what's in that business architecture service framework because I've gone through a few of the services for the service designers yeah absolutely so um as you as you touched on there situation investigation and problem analysis and feasibility assessment and business case development is also in the in the business architecture service framework I guess the work that the the individuals are doing there can vary depending on the organization they're in the lines of responsibility with program managers you know product owners all sorts of different change professionals can operate in that space so that's very much a one for an active conversation if you're looking to develop a service framework is understanding what what shape that is in your organization um it then goes on to i guess more um specific activities for a business architect so um blueprint development and maintenance and business architecture governance there a lot of um focus on target operator models and operating models generally within the framework And then strategic roadmap development is another one of the key services in there Brilliant.

And then, Chris, I suspect many of our listeners know what's in the BA service framework in terms of the business analysis one. But you're okay to outline the other services that we've not mentioned that are in that framework as well. Yeah, of course. So as you've mentioned, situation investigation and problem analysis.

so that understanding the problem, the opportunity, and making sure it's well framed. The work around feasibility assessment and business case development, again, likely to be very collaborative with the other professions. The other services in the BA one are business process improvement, so that work around modelling existing processes, improving them, generating 2B processes, and doing that gap analysis to understand the actions that could be needed. Requirements definition, so I guess the kind of bread and butter of the BA role, really.

So eliciting and analyzing, defining the requirements, all that good requirements engineering stuff. Business acceptance testing. So supporting our stakeholders in testing the business and IT changes and accepting those. And then finally, business change deployment.

So landing the change successfully, ensuring that smooth transition and enabling the adoption of the solution. And again, all of that is supported by this auxiliary service of stakeholder engagement. And one of the things that's really good about that, I think, is that some business analysts, particularly earlier in their career, might be focused a lot on just a couple of those services. So they might be heavily involved in requirements definition and heavily involved in business process improvement.

But the service framework allows them to see the edges of the role, see the full breadth. And that can be really useful for them in kind of planning where they're going to go, how they're going to build their skills and what additional sorts of services and projects they want to get involved in. Yeah, I think back to the start of my career, Chris, and the very first piece of work I had to do was in the requirements definition area. And then a few years later, I'm then doing process modeling work and slowly start to build the services that I felt competent in offering, supported obviously by mentoring and training and opportunity.

but then later on getting more into the feasibility assessment and business case development services um but it takes time doesn't it to build skill and expertise in delivering each of these services um was your was your journey similar Vic in terms of looking at one of the services at the start of your career definitely I mean obviously I've trod the business analysis route as well so I was very much in that space of almost picking up as you go along the kind of experience and criteria to be able to say yes I've done that and I'm good at that.

I think in business architecture it's things like a target operating model they don't come along very often so you kind of have to be really clear that that is a gap in my knowledge and that's something I want to experience and kind of carve that opportunity out. I mean it's the same for all the professions But I think when you're talking about kind of big transformational pieces, strategic roadmaps, that's not an everyday occurrence that only comes along every so often. So you kind of have to be really deliberate about gaining that experience and kind of building out that knowledge and CPE, I suppose.

It's quite cool, though, if you can see the different services from across the different service frameworks and go, well I'm really interested in doing strategic roadmap development or business acceptance testing or something you've not done before and you say well I want to do that and then you have a conversation with your manager or whoever's allocating the word say can you help me get the opportunity to go work in this area support me ask what training is available what standards you're expected to work to and then it's a way of thinking about career progression and then for the BA resource managers it's a way of thinking about talent management and succession planning as well it's kind of there's multiple kind of benefits of these things isn't there and I wouldn't care I'd never volunteer to go do the business acceptance testing I'll be much more likely to be going can I kind of go do the strategic roadmap development or the blueprint development maintenance I think I think as well to build on I think it's easier to if you understand what services you're offering it's also easier to measure them as well so if you're not if you're not clear about the services that you and your team can offer in terms of governing that and delivering that to a certain standard that's much easier to do when you've got a framework to frame against essentially um so that's another area where i think the framework adds value to the organization not just the individual as well I think there's also something in terms of not just defining what we do, but defining what we don't do.

So an absence of us offering a service kind of helps us to have some of those more difficult conversations, perhaps, where BAs are having requests to do work that's outside their scope. And obviously, a lot of BAs, we want to be helpful. We want to be good team players, good team-shaped professionals. but if you're being pulled out inside your lane too often you're not actually delivering the services that you're there to deliver so i think having being able to have those conversations with with stakeholders with project managers and say hang on a second this is actually the sort of work i should be engaged with this is the benefit that that's bringing to the team um appreciate that getting me to uh you know let the visitors in or make the coffee is helpful but not actually is helpful perhaps it's defining that problem or a listing that's required i think reduce organizational politics as well when you've got a clear boundary between roles and what people do and don't do that conflict tends to resolve itself it takes time to understand all the boundaries around the roles um but the framework helps to to dovetail that nicely without all the well this BA does that but that BA doesn't and well I've got an architect over there who's doing requirements but you know it's kind of that confusion with which we can we can get rid of a lot of that noise with with the frameworks.

Yeah and it's proactive because you can proactively define your own framework you don't have to use the ones as they're published you can adapt this concept to your own language what would work with your stakeholders but it's proactively thinking ahead to some of those difficult conversations And I think presenting a standard that you could use not for the sake of having a standard but so you got a shared language also a baseline of this is what we expect a professional business architect, professional service designer or business analyst to do.

And it's then, you've then got a basis for maturing. How do you offer that service based upon your defined standard? because if you don't have a defined standard how could you possibly measure the quality of that service or be starting to think about how we improve it and Chris rightly or wrongly I think you're quite a way down this road in terms of you've been using the service the BA business analysis service framework for quite some time so I think possibly you're quite mature in terms of using it is that is that a fair judgment I'd say so so um I've used it in two organizations now and in both of those organizations done work to customize it to the way that we operate.

So for example, currently at DWP, we use a BA service framework and we've adjusted some of the services to fit better the nature of the, many of our BAs are deployed, embedded into agile product delivery teams. And so with the way that different surrounding teams operate, we sort of amalgamated the the latter two services around acceptance testing and transition and release into something we framed as more support and enable solution delivery, which sort of covers supporting solution creation, acceptance, transition, release, and impact measurement.

It just works better to how they have to intercept with other teams. But what we've managed to do is once we've got that service framework in place, it's amazing how many different uses you find for it that you wouldn't necessarily in fact. So one of the areas that we find are particularly useful for is around building capability. So we've touched on how VAs can use it themselves to sort of think about their skills, but from a practice standpoint, we can consider almost like a heat map really, the different LSD offers that we have and how those map to the service framework.

And therefore, are there gaps, are there areas where we're not providing the right sort of support and capability development, and the rates we should be focusing on more. And we've also been able to use it as a bit of a kind of lightweight capability assessment to gauge how confident BAs are in carrying out each of the services. We have skills frameworks as well, but taking this service length has been quite useful for us in prioritizing sort of capability workshops and things like that.

Vic, your experience of using it in your organization, um because you so you it sounds like you've got it embedded and and it's now the language yeah absolutely and and we've um we've we've also used it to help with recruitment you know we were we were light on a certain area and and you know the team that was in place didn't have experience of x so as we've gone to market for you know a new team member we've kind of specifically looked to see if they've got if they've got those skills to complement the rest of the team um we've we've used it um actively in kind of making sure that we are dovetailing with the rest of the architecture discipline so there was quite a lot of um work last year which um we were looking at roadmaps and blueprints for the organization um and the kind of the racy that underpins that was really helpful you know to complement with the service framework so you know the business architects will pick up this part of that piece of work the solution architects will pick up this part etc etc and so having that clarity about what we're good at and also we know what we should be doing for the organization versus you know some of the other roles that we've got in our team brilliant and you're extending it and finding other ways because that change ecosystem with the enterprise architects then the if you've got them the specialist data or infrastructure security yes there's there's all different flavors of architects and it's kind of right who's doing what and how does that achieve the change outcomes for our organization it can get quite challenging if we can't have that conversation with each other and in a little bit territorial as well Jonathan sometimes some organizations there's an outright role conflict or tension between the roles where a particular profession might say this is my artifact this is my output and if a different change professional were to pick up the artifact or output you get quite sensitive um have you come across that in your you know either current or previous workplaces absolutely but um i'm trying really hard and in fact as part of our ba service framework i've included a bit of supplementary information at the end to do with role collaboration because I'd really rather we reframe some of those role conflicts as opportunities for great collaboration rather than getting into a bit of a turf or sort of different professions coming together and bringing their different toolkits, mindsets, viewpoints and collaborating together to deliver those services.

That feels to me as though you're getting the most bang for your buck and you're getting the best quality service delivery for getting the best outcomes for customers and the organisation. So I think reframing conflict into collaboration is something I'm quite keen to push. And I think the survey framework helps with that. And it gives you a basis to have that discussion on, right, what are the services and how might we best collaborate to achieve the outcomes that we're trying to get to, be it a blueprints developed or a services defined or set requirements that are created and validated, obviously.

But it's kind of, it's a basis for that discussion. And with other collaborative professionals, that should, I would hope, give a basis for a, you know, a fruitful discussion. But unfortunately, there are some change professionals that think that this is a threat. they don't see it as the opportunity as maybe you're framing it as Chris they're seeing it as I do whatever thing it is that they are talking about and don't go near it one example is rare but would be someone saying for example a service blueprint is only ever written by someone who is a service designer and I think service designers are very well placed to build service blueprints They have expertise But I also think that it a technique and that if a business architect or a business analyst has the skill and competency to build a service blueprint, I think they should be empowered to do that in a collaborative working relationship.

But I'd also say the same of a business architecture technique. If a business analyst or a service designer wants to draw out a value stream, as long as they do it to the local standards and they're aligned and collaborating with the business architecture team, they should be able to use the value stream and not be worried about who can use what technique. It should be focused on instead the outcomes for the organization. I'd agree, Jonathan.

I think the toolkit is a collective toolkit for change professionals it's not uh this belongs to this community and that belongs to that community i think the other thing is um you know that there's a there's a numbers game here so in my organization we have 120 ish business analysts who are embedded in change activity across the organization there are five business architects so we cannot be involved in all the change at that you know at a certain level um so i i rely on the business architecture community in our organization to to kind of take some of the techniques and take that thinking of you know strategic enablement into their change programs and i'm absolutely happy for them to do that um you know on the on the on the you know proviso that that you know they're following the standards like you said and you know they're following the governance framework etc but it's a pure numbers game sometimes as well and I suspect there's there's limited service professionals compared to business analysts um in uh in a lot of organizations as well so yeah yeah there's a there's a scarcity of the specialist skills in some organizations or complete absence of these specialist skills exactly but so it's kind of right how do we help our organizations move forward not putting in um role boundaries for the sake of putting in role boundaries the intent of the service frameworks is that you can pick and use them and you can see i'm surrounded by lego figures behind me think of them as lego building blocks that you can add in or remove from your service offer and it could could it's obviously got to be dependent on your on your local standards um right we're coming towards the end um let me just ask um chris any kind of hints and tips if someone's picking up a service framework or looking at one for the first time any hints and tips that you could give them if they were to be interested in learning a bit more about service frameworks or how to use them yeah so i'd say obviously first of all review and understand the framework you know it's available within various of the bcs books and details so you can can read up on it there i'd say try and involve the team as well the ba team can contribute in terms of kind of bringing out what's the different things they're doing, the different types of analysis, the different projects they're working on.

And you can then look at that and consider how it fits into the framework or whether there's gaps where perhaps you've identified some additional services you provide or some changes to those services, or whether they're doing things that actually aren't the BA role and perhaps they shouldn't be doing. So that's useful. They can also cross check against the skills frameworks if you have them and I'd say one thing that's really important for me is think about how this is going to be communicated and used it doesn't really have any value if it just sits in a spreadsheet buried somewhere at the bottom of your SharePoint structure so think about if you have got a framework developed how you are going to bring it to life how you're going to communicate it how you can make sure it's visually appealing and succinct so that your business analyst can use it to communicate with stakeholders and explain what they're doing rather than it just kind of getting forgotten about or being something that stakeholders just don't want to look at because it looks really unengaging.

Wow, wow and I was going to ask you a follow-on question Vic but I can't, Chris is just feeling such an extensive wow what an answer that was that was a brilliant answer Chris I'm very impressed. Vic is there anything you would add to that which I'm not sure that I don't know I'm not sure what you can add but if you've got anything you'd add in terms of hints and tips where to get started practical applications so it's okay to have one or two services and and then build them up over time I think you know you don't need to go for the full suite from day one and it's okay to be to be deliberate about sort of building that up at a time would be my advice yeah brilliant brilliant some some brilliant collective advice um there hopefully listeners have found the this pod interesting and useful uh the idea of the frameworks is that they are picked up and used and adapted so that it fits with your context and and i really do hope that people find them to be useful um i did want to say um thank you to and i should have said this at the start but Chris has been a very short notice uh request to come on the pod um but Chris a long-time friend of the BA Brew and we've each three of us have got our BA Brew mugs and I think this might be a first where we've got two external guests with two completely different organizations coming on and thank you for being friends of the brew and coming back and Vic um I'm not sure if you're to keep up with the annual attendance joining of the pod but i really appreciate the support you got a back catalog of these now between both of you so thank you very much for joining us uh thank you to every single listener every single watcher of the ba brew um if you found anything useful in today's pod please do like the pod and share it with your colleagues um if If you're sat listening in and you've got a question or you've got an idea for the BA Brew, send us an email.

It's babrew at sskd.com. Thank you very much.

Related episodes across the Index

Other episodes covering the same guests and topics, from across The B2B Podcast Index.

  • How do you create a consistent workplace culture with multiple sites & hard-to-reach employees? With Ruth JacksonMAD Leaders Podcast · on DWP (Department for Work and Pensions)66 / 100
  • Service Management Leadership - Define What Good Looks LikeService Management Leadership Podcast · on Requirements definition42 / 100
  • 94: Stop Overcomplicating Business Systems: Simplicity Is Your AdvantageBeyond Your Business · on Business process improvement

More from BA Brew

All episodes →
  • Business Analysis Mode: Stuck On (feat. Stu Mullinger)
  • Informal Networks & Gossip in Business Analysis (feat. Carlos Pullen-Ferreira)
  • Active Listening for Business Analysts (feat. Craig Rollason and Corrine Thomas)
  • Supporting the Next Generation of BAs with the YBA (feat. Joanne Fahy and Joseph Haslam)
  • The Professional BA (feat. Laurens de Rooij)
Explore the best B2B Ops podcasts →
All BA Brew episodes →