If you don't know, I'm a little bit of a nerd.
Welcome to Business Analysis Live.
I'm your host, Susan Moore, community engagement manager
with the International Institute of Business Analysis.
I explore topics with industry guest about the work of business
analysis professionals and how their work helps organizations
achieve better outcomes. And Yep, we take your questions
too. Thanks for listening.
Let's get started. When it comes to the business
analysis body of knowledge, what we call the babock, probably one
of my favorite nerdy chapters is business analysis planning and
monitoring. And you might ask why.
And the reason is because I've done a lot of commercial off the
shelf projects over the course of my career.
And inevitably that is at the very beginning of every project
that I do. And what I've discovered over
the years is that's not always the first thing that people
think about when they start a project, Business analysis,
planning and monitoring. Not only commercial off the
shelf projects benefit from that, but really any kind of
project that you do as a business analysis professional,
any kind of project benefits from that.
And I'm going to leave you with a question that our guest today
is going to help us to answer and that is if you are not
planning your business analysis work, who is?
Are you leaving it to chance? Well, today we're going to be
talking about why plan your business analysis.
And my guest for that topic is Kathy Burkage.
Welcome to the stage, Kathy. Lovely to be here Susan and
great to see you again. Talking about something I
totally agree with. Yeah.
And you know, you and I had a chance to meet virtually way
back during the pandemic and at that time when we were talking
about stakeholder engagement. And this is definitely an
extension. This is part of business
analysis planning and monitoring.
So I know that you also geek out a little bit to this, so I am
happy to have birds of a feather here.
Hey, before we get into today's topic, I'd like for you to
introduce yourself. So for those folks who may not
have seen you and because you are around the world, you are a
global traveler for business analysis, if you will tell folks
a little bit about yourself. Thanks.
So I'm in based in Melbourne, Australia and you can tell by
the accent. I started doing business
analysis work in the 1990s before IBA was formed, before
the word business analyst was even a title.
It was analyst programmer back then.
And yes, I did come from a technical software development
background, but my passion was always working with my users,
working with my stakeholders, understanding their real needs
and making sure solutions align to it.
Now that's of course what we do as business analysts and OF in
2003 that became the way that we define business analysis.
I've been working in business analysis in multiple
organizations, predominantly in the telecommunications and
utility sectors here in Australia.
I helped form a BA Community of Practice as part of a PMO and
one of the government departments.
I write about business analysis, I blog about it, I've talked
about it forever, and I've performed it so a lot for so
many, so many years. I'd say at least 20 years as a
BAI also trained business analysis to people going through
their certifications through the IIBA and of course, teaching
specific tools and techniques of business analysis, even if
they're not going through the official certification
processes. So I'm a passionate business
analyst and I love contributing to the community and helping
other BAS up skill and develop. As you were introducing
yourself, you were reminding me there's an insurance company
here in the United States. And to paraphrase their tagline,
it's something like, we know a lot of things because we've seen
a lot of things. And I feel like that's what you
bring to the business analysis profession and to all of the
talks that you do. You know a lot of this because
you've you've seen a lot of this.
And my guess is the reason that you get really excited and
really want to talk about business analysis planning is
because you've probably seen projects go sideways and you
probably know a lot of things about what could prevent that.
So let's talk a little bit about maybe this first question.
So why do you think planning gets overlooked in the work that
we do? And it does too often.
There's two primary reasons, I think for number 1 is our
project manager and or our sponsors and stakeholders just
telling us we need this now, go forth and get going.
And they don't really recognise that we need to do any planning.
They just think you're ABA, you know what to do, go, go forth
and do it. And BAS often we're not given
that opportunity. We're not given the time or the
authorisation. I don't know if that's the right
word to say, OK, I just want to spend a moment here making sure
I know how we're going to go about doing the BA work for your
project. They're almost ramming us into
just getting started and as BAS, especially those who haven't
maybe come across some of the planning techniques and tools
that we, we might talk about today, they might feel pressured
and not realise, OK, well, I'll just do it per what the PMS
telling me, because the PM might just have a task on their Gantt
chart saying business analysis requirements, you know, or
create the BRD or whatever the case might be, create the
backlog, write some user stories.
They will just allocate us a task without a task for business
analysis. So that's the primary reason in
my mind, what I've seen, what I talked to other BAS, they're
told we don't get the opportunity to do this because
we're not supported in performing the work.
So that's half of the problem. The other half of the problem is
that many BAS simply don't know what should we be planning in
the first place. I'm not a project manager.
I'm not planning the project. So what is business analysis
planning? What does that mean?
What should I be doing? Am I duplicating work?
So they're probably not confident in what's needed for
us to kind of go forth and know what we're going to do.
It doesn't need to be extensive. It doesn't need to take hours,
but it gives us the opportunity to, as they say, you know, for
failing to plan is planning to fail, as Benjamin Franklin says.
And so opportunity to sort of, hey, let's step back before we
set ourselves up for a disaster rather than success.
Yeah. Is you were giving that answer,
I was. This is probably another
question that maybe members of our audience are thinking about
today. Won't the project manager create
the business analysis plan? You said don't count on it
because it's different business. A business analysis plan would
be different from the overall project plan that gets created.
It could be rolled into the project management plan, but it
really, I think needs to come from the business analysis
professional. We often say that business
analysis is a project within a project, and that's how I've
always viewed it. You know, when we think of the
project manager and the BA, we should be, you know, working
symbiotically. But the project manager is
coordinating all the different resources and stakeholders that
come together to build a project.
We're coordinating all the requirements and solutions to
ensure that what the project implements is the right thing.
So our part is a big part of defining what the project
manager is going to deliver, but they almost never will give us
planning as a task. They'll just say do the
requirements as a task, not the do the BA planning.
I don't think I've in any of my projects ever seen a project
manager or any project plan that has business analysis planning
as a task from anywhere at this. Yes, just do it.
Or ad hoc maybe. Yeah.
And I think because we often do similar kinds of projects over
and over, we probably know what it entails.
But if you are doing something that you've never done before,
you're doing a commercial off the shelf project, if you're
doing something that involves a lot of people, a lot of
individual things, I think it's really important.
And you're right, it doesn't have to be a formal phase.
It doesn't have to be a formal document, but it should
encompass a number of areas of just about how you are going to
do your work. Before you and I got started
today, I was thinking about when I started projects.
Inevitably I would get stakeholders who would say what
do you need me to do? How long do you need me to do
it? That gets answered with a
business analysis plan. Absolutely.
And something we again overlooked too often and so do
the project managers. There's this weird thing that
I've noticed in many projects that our stakeholders time is
not chargeable and we don't sort of count on how much we're
expecting from them. And there's this weird thing
that especially depending on your organization's, if you're
using cost centers and things like that for your projects,
then stakeholders attending meetings or stakeholders doing
workshops to, to do process mapping or requirements or story
mapping or whatever we're doing, their time is not scheduled.
But if we do ABA plan, we can start saying, I'm going to have
these kinds of workshops, I'm going to be creating these kinds
of artefacts and these are the inputs I need.
And once we understand that, we can understand how much time we
are expecting from our stakeholders.
They apparently aren't sitting around waiting for us all day
every day. They're busy, they want to know
what's happening and they want to know how much time.
So forewarned is forearmed so we can at least say, look, this
project is going to be X, this is what I'm planning to do and
it's going to happen in these kinds of time frames.
Now, of course, this is not something we do independently.
We certainly will be talking with our project managers about
this stuff as well. So you're answering a question
that I think members of our audience will have, which is how
does planning impact stakeholder engagement and project outcomes.
And stakeholder engagement is a part of the plan.
But also I think having a plan let's your stakeholders know
that you are prepared and ready for them.
You can answer those questions and that can build trust and
goodwill and you're not wasting their time.
That's a good thing for stakeholder engagement.
Absolutely. And and again, often project
managers will say, I do stakeholder analysis, I do a
stakeholder engagement plan, I do a communication plan.
Fantastic. Thank you, project manager.
I'm glad that you're doing it for the project overall, but I'm
going to do 1 specifically for business analysis activities,
which I'm happy to be part of your overall plan, but I need to
engage stakeholders independently of you because
you're probably doing more coordination activities.
I'm going to be doing deep dives into their root cause, into
their process flows, into the underlying problems.
And these are things that I'm going to be needing to do.
You know, it's not, it's BA work.
So yes, I can input that. But I need to think about, well,
when I'm talking to my stakeholders, you're looking at
it from the project execution point of view.
I'm looking at it as the solution implementation point of
view and their needs. So there are, when you do your
analysis, you're doing it through a different lens than me
as ABA looking at the analysis of my stakeholders from the BA
lens. So yes, they're both needed.
They are slightly different. Yeah.
And I think having those conversations with your project
manager, I mean, we have talked so far in this conversation,
we've talked about a project manager at each stage.
And I think sometimes for business analysis professionals,
you may be working with a project manager who really
doesn't understand what you do. They may not understand that
there's a component of planning that you can contribute.
I think it starts with good relationships with your project
managers just to let them know what you can contribute, what
you see as needed for them. Also to have a really good
project plan, make sure that you are, if you're not being asked
for input, my advice is make sure that you're talking with
your project manager because they may be getting these
questions like how long? Who are you going to need?
How long are you going to need them?
What is it that you're going to produce?
Right? And if they don't know that you
can contribute that, then project managers either may say,
don't worry about it, or they may make something up.
And then you really do get boxed in to.
This is how I have to work. And the other thing that I've
seen way too much is 2 two big things.
Sometimes ABA doesn't have a project manager.
We're being told to go forth and do some work and implement some
enhancements. Maybe they're not huge projects.
Maybe it's this minor enhancement, in which case we're
helping coordinate the work without that formal project
construct. So when there's no PM, well,
it's up to us anyhow. So in that case, we are we're in
a bit of a hat of APM. At the same time, the other
thing that I have heard, and it was appalling to me, but I'm
sure some of you might have heard this, there's a perception
out there that project managers can do business analysis work,
the business analysis and BAS, but BAS can't do project
management work. I'm like, I think it's more
likely to be the other way around.
I think the project managers completely underestimate what BA
work is because a project manager will probably just say
pick a solution, get it in, whereas we're going to say what
is the right solution in the 1st place, which I don't think they
do. So yes, there's a lot of
misconception from the project managers depending.
Some are better than others. Of course, they're not all evil.
Some of them simply don't understand the business
analysis, the value that we bring to their projects.
They just don't understand it. So therefore they undervalue it,
and therefore they just see us as a resource churning out a
document. Yeah, that's right.
And so sometimes, that's why
they sometimes don't ask us for how are you going to do what
you're going to produce? They're just going to assume
Susan's going to write requirements, therefore she just
needs three weeks, because how long can it take to write a
document? Not the case at all.
There's tons of stuff. So you know, we've been talking
about what a project of a business analysis plan looks
like. I bet some folks out there are
thinking what is a good business analysis plan actually look
like? And so I know that you this is
something that you have not only been thinking about, but you've
been talking about it and you have built something.
I don't know if you would call it a plan.
I think you call it a canvas. Maybe we take a look at at your
canvas concept and then we can maybe talk through the kinds of
things that you think a business analysis professional should be
collecting, thinking about whatever as part of their
business analysis plan. I think that would be great to
share with you. So we know that in the business
analysis body of knowledge, our favorite Big Orange book,
there's a whole chapter and a whole knowledge area dedicated
to business analysis, planning and monitoring.
So if you're like me and I love my Baboch and I study it and of
course I train others in it, when you read that chapter, it's
quite overwhelming. And for ABA, who's perhaps new
to business analysis or you know, not sure of the whole what
do I need to do here, it talks a lot about the tasks and the
techniques like the the bad box got the knowledge area.
And the knowledge area has five tasks.
And those five tasks can be done by all these techniques.
And you'll read through it with all that text and all those
references and you'll just sit there and say, where do I start?
And that's how I viewed it when I train it, when I talk about it
to trainees, when I talk about it to project managers, they
just go, well, what does that mean?
So all I've done is really looked at what we need to do as
part of what it's telling us in the Bablock and creating a
template or a canvas. I mean, canvases are more trendy
than templates, but that's all it is.
And I'm just going to share the screen.
I don't know if you're going to put that up there.
So what what it is, it's really talking about the nine elements
we need to really think about to be sure that we're covering the
business analysis, planning concepts altogether.
Now, sometimes people might look at this and say, well, that's
what the project manager does. But once again, we need to look
at it with the BA lens. A few of the things along the
top really should be from the project management plan or the
project business case, or they should come from somebody else.
But as a BA, we often can't think about things like the
problem or the opportunity. So the first element I've got
there is being clear about the problem.
So what is the problem or opportunity being addressed
again? Is it something being fixed or
are we something that we're improving?
We talk about it's background now as ABA.
This may be already documented, but sometimes we might need to
investigate this because we can't do planning and or scoping
and or requirement solicitation without clarity on the
background of the scope, how big it is and how long it's been
there. So this may or may not be cut
and paste from somewhere else or maybe something we need to go
out and reconfirm, and we're not necessarily reinventing the
wheel here, but we're just making sure we've got clarity on
what it is that we're trying to achieve in the first place.
The next element is scope. Now this is, you know, scope
just seems to be a dirty word in projects.
I don't know why things are going to change.
Your requirements are going to change, your stakeholders are
going to change, your priorities are going to change.
We know this happens. That's why a jail was born.
But even if it isn't, we know that we manage these changes.
But scope in this sense is really a high level expectation
of what is changing, what is being modified and what is not,
what's clearly included and excluded.
We're only doing the HR system. We're not touching finance,
we're not touching the website. So it's really kind of putting
some boundaries, broad boundaries around the
requirements set, not the specific requirements, the
specific requirements are going to be what we manage, but the
set of requirements. Are we looking at change
management requirements? Are we looking at or is the
change manager going to do that sort of work?
And some organisations don't have a change manager and it's
often left to the BAS to do some of that work.
So that's what we're really talking about, the scope of how
much and what we're really going to be looking at for the BA
analysis activity. So not detailed requirement
scope whatsoever. So this causes a lot of
confusion, of course. Yeah, I could see where folks
that are looking at this might get some of this a little bit
mixed up with the requirements effort, but still you are
thinking about your plan. What is the scope of the effort
that I need to be thinking about is I am planning my activities,
the work that I'm going to do. That's your scope.
That's exactly it. So we're not at all thinking
about, oh, you know, which screens are changing on the
website or what you apps or what.
And it's really about, I'm gonna be looking at HR, I'm gonna be
looking specifically at. Payroll or whatever it is.
So it's really just kind of defining where I'm going to be
looking in the 1st place rather than the requirement scope.
And that's really what we need to.
So it's a stepping back of it's looking at it at a much higher
level, you know, higher level picture of this is the scope of
my work, not the scope of the. Requirements.
Yeah. And I bet a lot of folks
probably don't even stop to think about what is the scope of
my work, What have I been tasked with doing?
Sort of put on a consultant mindset potentially you've been
hired with the company, what's the scope that they've asked you
to do so that's. Exactly it.
So it helps give us a bit of a frame of reference, all of this
stuff and the goals and objectives.
Once again, as ABA, we not necessarily come up with the
goals and objectives, but we must be clear that what does
good look like, what does success look like and how is it
going to be measured? Now this probably is in line
with the project management documentation again, if it
exists because sometimes it doesn't exist because it's an
initiative that we're doing without that formality.
So it doesn't have to be project specifically related.
It might be just, you know some of the BA you kind of BA work
that some of us do. So what's the expected result?
We're expecting sales to increase, or employee engagement
to increase, or the cost of postage and delivery to come
down or whatever it is. We're clear about what good
looks like, so we're not reinventing it.
We're just confirming it. So the top layer gives us the
framework, it sets the scene, it gives me the foundations and the
context of my BA work. Then we start digging into some
detail. Now here we've got stakeholders
and there are great tools including another canvas staff
presented as mentioned that stakeholder analysis.
But this provides a high level view of who the stakeholders
impacted, what is their role and their needs.
So at a high level, we can understand a little bit about
our stakeholders and we might follow this up with a much more
detailed stakeholder analysis, which I've thoroughly recommend.
But of course on the canvas here, it may just be the the
summary and then the detailed work would be done in addition
to the plan. But at least here it gives you
that first kind of set of names and roles and and gives you that
sort of very starting point of the stake stakeholder analysis
processes. So we need to understand who the
stakeholders are. And once again, going back to
what we mentioned earlier, we can start thinking about how
much time we might need from each of these stakeholders
because what are we expecting them to be participating in?
Are they in workshops or one on ones?
Are we going to do some observations?
Are we going to do some simulations prototyping so we
get a small picture of what we might be needing from them here?
Yeah. And here I think you're right.
As you are thinking about the kinds of artifacts you think you
are going to be producing, you also kind of have to retro
engineer who are the people, even if you don't know names,
what kinds of people, what departments, what teams who do I
think might need to be involved in helping me to produce X?
Yep. So that you can make sure that
you can create that more detailed document that says, OK,
I need to talk to the HR team and specifically to the
recruiting staff. It's who I need to be talking
to. And I'm not sure who that is
yet, but I know those are the folks that are going to be
important to being able to produce whatever recruiting
workflows. Yeah.
And because this is a planning document, it's really saying
this is what I think I'm going to need to get into.
So this will form the basis of the more detail.
So it's again providing that all right, you know that like any of
the canvases and templates, it's really about organizing my
thinking and organizing all the bits and pieces so I don't miss
things. And so this gives us that
initial think of, yes, I think I need to talk to these folk and
maybe not the others. Moving on to risks.
And again, project managers might go, but that's my job.
Risk management. Well, of course project risk
management is, but we're looking at risks to business analysis,
risks to our requirements, risks to to the modelling, risks to
problems that could affect the business analysis activities and
risks to the solution success. Beyond like project management
risks, which might be looking at things like, you know,
resourcing risks or technology risks or weather risks or
whatever it might be. We're going to be looking
specifically at what might affect us.
So we might say, well, the availability of the HR manager
not coming to us and giving their requirements, we're going
to miss stuff. So we're going to be looking
specifically at that requirement solicitation, solution
recommendation, you know, really looking at those kinds of risks,
the risks of we don't have enough time for workshops, you
know, and this could I happens all the time and certainly I
would be talking to my project manager here.
It's not like I'm saying I'm doing a separate risk analysis
from you. I'm just going to say, well,
these are very specific to what I'm trying to do within the
project. And it may become a subset of
the project risks that they might add, but leave us to kind
of manage because that's what we naturally do anyhow.
Yes, Yep. Then, so now we've got a bit
more kind of context and now we start really framing it up.
What is the governance expectations of this project?
How a decision is going to be made, where the approvals, what
needs approval, what doesn't? How are we going to do change
management? Because change is definitely
going to happen. How do we manage change?
And we're going to be looking at it from the point of view of
requirements and the solutioning, not the big project
stuff because of course project change, the project manager will
look at, you know, budget and schedule.
We're going to be looking at requirements change.
So we need to think about how we're going to prioritise and
how do we manage change very specifically in the requirement
set more so than the project. So again, it's like that project
within a project, so we care about this.
I think sometimes that we are not thinking about this, this in
particular because I've, I've been on projects where we did
not have a decision making protocol.
Who's making decisions? Where are we logging, we
communicating them? Who approves requirements?
What is the process for sending out a request for approval?
There may be lots of ways that you've worked in the past, but
for this project, I think it it makes sense to just talk about
these things, have a plan for them so that we all know and
that's all you're saying. Especially if we're dealing with
vendors with commercial software, because that's going
to be even more important to understand how we're going to
manage this stuff because if we approve change requirements, we
might be affecting costs of the contract.
So this is the kind of stuff we need to think of upfront.
Yes, Yep. The next one is shouldn't take
too long. It's really about what kind of
project methods and frameworks are we following?
Are we using Scrum? Are we using waterfall?
Are we doing something hybrid? So we've got a clear picture of
the project life cycle and the expected level of detail of the
requirements at the various stages.
Of course, that's the big difference between Waterfall and
Agile in my mind. Waterfall projects do more
detail upfront, Agile do more detail as we go.
So what is that approach and how we're going to fit our
requirements analysis and the levels of detail and how the the
the work's going to emerge based on the overall method of the
project. So we can plan for know this is
a bit of a hybrid, you know, all this is fully waterfall or is it
completely the vendor and we're almost acting as a product
owner. So that could be completely
different to the approach too, right.
And that happens in many circumstances.
Oh yeah. Yeah.
The last one is all about making it clear in our own minds what
artifacts are we producing? Are we doing end to end process
models or are we just doing things in JIRA based on user
stories with epics, etcetera? How are we managing things?
Is it in Confluence or SharePoint or is it still back
to BRDS? I worked with a team just last
week that still use detailed documents in Word, full BRDS.
So it just depends on who it is and what company, but we're
clear about about the documents, artifacts and other information
sources, where they're stored, who's going to be reviewing
them, who's going to need to look at them, how they're going
to be distributed. So we're clear and we might even
consider this stuff that's maybe internal.
The vendors don't see if it is that case or maybe something
that has to stay within the IT department that doesn't go out
to the the call center, I don't know.
So we're starting to think about information management in all
its forms, including security, and who's involved.
And this information management piece is where you might
possibly take a left turn and start to go into a requirement
management plan, which would be a completely separate thing.
But if you are going to be managing a lot of requirements,
are you going to have a requirement management plan?
Where is that? Who's writing it?
Where is it stored? And then, you know, so I I can
see where each of these very well could take you into another
document which gets much deeper. Yeah.
And it's sort of it's kind of all feeds in to a clear BA plan
and that's similar to what you've sort of said.
So we're clear about, you know again it sounds obvious who's
going to perform the work. In many big projects, you might
have a team of BA's such as one BA, and some BA might be looking
at different elements. So now we've got all this work
that we've done in the other elements to be clear about who's
doing what, especially if there's multiple BAS or there
might be other people. There might be project managers
or testers or UX designers doing some of the works.
What activities are happening? Interviews, workshops, go out to
client sites, observations, all of that, that idea of tasks and
time frames and what techniques we're going to use.
We're going to use BPMN here. We're going to do some story
mapping there. So all of the other information
should now feed in to give us that clarity on the activities
and the rough timings of what we need to do based on all the
other elements of the canvas, so to speak.
They should now be able to inform us to answer these
questions so we can be clear and formulate a plan and that could
go into the overall project plan with our project manager to say
if that if that's what they want to do.
Some of them might say we're happy for you to manage that
part. It just depends.
Yeah, this is where I think it's really helpful when business
analysts have a little bit of project management skill set
under, you know, under their belt.
Just because I think it can help you in those instances where
either you don't have a project manager or your project manager
says, you know what, I'm just going to let you manage that.
Just check in with me. So not a bad thing to have a
little bit of project management skills.
I know that folks that are watching today may be thinking,
wow, that's a lot of stuff. You mean I have to do that for
every project? What would you, how would you
answer that question? Do you have to have a plan for
every project? So if you're doing a huge 18
months massive transformation plan, well, this is probably
going to be a little bit more detailed and probably a lot more
important to be clear, because the larger the scope and the
larger the complexity, the more likely it is you need to think
more carefully about this and have a clear plan.
If I'm doing a couple of weeks worth of a quick enhancement,
this may be nothing more than some scribbles under the
headings just to clarify some thinking.
It may be completely informal and goes no further than my own
sticky notes on my whiteboard. So it's not intended to be a
formal document, but it certainly could form a formal
document that's signed off and approved and, and goes proper
project management type of stage gates and stuff.
It just depends on what the project is and that again, you
know, if we're working for government versus working for a
start up, that's going to hugely influence the level of formality
and the level of detail as well. So it needs to be thought of is
how much is valuable and how much is overkill and how much is
not enough. Because, you know, I always feel
like these things are like the Goldilocks parable, you know,
too much wasteful, not enough, also wasteful.
What's just right is going to be so dependent on the context.
I think this is an area where if you are a business analysis
professional who wants to grow in the profession and you're
looking for some some things that you can start to
incorporate, that'll make the difference.
I actually think doing business analysis, planning, being more
intentional with it is one of the ways that you can start to
be thinking about how you're going to grow your career.
Knowing why you are doing things and being able to show your
work, as they say, I think can be really helpful for yourself
and for those around you to build confidence that you know
how to do things. Also to make your plans clear so
that you can ask for feedback and get assistance from maybe
more senior BA. So to me it's a form of
leadership skills if you want to do this.
Yeah, it does. And I think that you're right
because it's showing your team, it's showing your stakeholders,
your project managers and your sponsors.
I'm serious about this stuff. I'm not just winging it and, you
know, flying by the seat of my pants.
I'm serious about developing and contributing to successful
outcomes. Yes, exactly.
And so you mentioned that you took your inspiration for that
canvas from the Business Analysis Body of Knowledge
Chapter 4. Listen, I don't know the
chapters like everybody, like some folks who know the
chapters, but there's a whole chapter on this.
And so for those of you that are are joining us today and who,
who are like, OK, that canvas makes sense to me.
I want more. Well, that's where you go to get
more and you can get the, the detail of how to think about
each of those things, why you would do each of those things.
So I think that's really helpful.
Maybe just one last question that folks might be thinking,
which is I do, I'm an agile I've I don't need to do this, right?
You know, I hear so much noise about BA's.
Agile BA's are different than regular BA's.
No, it's the same work. The only difference is how much
is done up front versus how much is done as you are going.
But that's why the approach needs to be thought of.
And in an agile project, all of these things are the same.
We still need to manage artifacts and information.
We still need stakeholder engagement.
We still need to understand risks.
We'll still need to understand governance.
Good agile projects have good disciplined governance as well.
So all of these things still need to be thought of.
But am I going to spend weeks on ABA plan?
No, it's probably going to be quite lightweight, quite
informal, and it's going to speak to the agile way of
working rather than the more perhaps traditional ways of
working. So it's no different.
It's the same BA work in an agile project.
So I think that that's something I hope we can get in the BA
community that the the activities, the tools and the
techniques. Yeah, there's some different
special agile techniques, stories and story mapping and
things like this, but the work is the same.
Understanding the needs to recommend solutions that deliver
value to our stakeholders. It's no different.
It's enabling change. Exactly.
All right. Well, a great conversation.
So I hope those that are joining us today know a little bit more
about why they should be thinking about business
analysis, planning. You are going to continue
talking about this. You told me that you are going
to be at BBC this year in Toronto in April.
I think it's like the 20th through the 23rd or 4th of
April. Yeah.
So and this is your topic. Are you doing a workshop?
Are you doing a talk? Doing a workshop, we're going to
do a big deep dive into how to do all of these good stuff.
So yes, it shall be a workshop and there may or may not be
another session, we're not sure yet, but I definitely will be in
Toronto, the birth place of the. So I'm very excited.
I've been to Canada once, but I haven't been to Toronto.
So I'm very excited to be up there for the first time and
again, see all the passionate BAS as what we have in all our
community events. And this is going to be a big
one, I'm sure. Yes, and it'll be good to see
you there. So Kathy, thanks again for
joining us today. You're.
Very welcome, it's been a pleasure.
Yeah. Thanks.
All right. And that is it for our episode
today. Maybe there's some things that
you heard today that you're going to incorporate.
Maybe you're going to take another look at that chapter in
the business analysis body of knowledge on business analysis
planning. Maybe you'll think about that
canvas that Kathy showed us today.
Whatever you choose to do, I think there's a lot there that
can give you some control over the approaches that you take
when you do your business analysis.
So I look forward to seeing you again.
See you soon. Thanks for listening.
Do you have any questions, comments or thoughts about
today's topic? We'd love to hear them.
Drop us a review or leave a note in the comments.
Then like, subscribe or share this podcast if you like what
you heard. And hey, you can help us shape
future episodes. What do you want to know more
about? Send us an e-mail at Live at
iiba.org with your ideas. See you again on our next
episode.