The Better Business Analysis Institute presence, the Better
Business Analysis Podcast with Kenjamin Walsh.
Hi everybody, and welcome back to the Better Business Analysis
Podcast with Benjamin Walsh. Now we're going to focus on a
topic here today, which is actually for some of you your
core job or for some of you a job that you would like and for
other B. As this is a mindset, it should
be a mindset regardless of it's your job or not.
And something that you as ABA, it is part of your remit, it is
part of your role. And if you follow the teachings
of the Better Business Analysis Institute, it actually relates
to one of our phases called release and Operational
improvement. And this topic I'm going to
broadly call continuous improvement.
Actually, we are going to focus on continuous improvement.
What does that actually mean? What does that mean for you in
your role? What does it mean for you on
your project? What does it mean for operations
and all those things? And we're going to bring it
together hopefully in a concise, easy to understand podcast
episode. What is continuous improvement?
What does, what does this continuous mean?
Well, if you're from the world or the world of Agile, then a
whole lot about Agile and agile delivery is around the
continuous nature of running a machine, really a delivery
machine, and allowing it to work in a great way.
So that's the that's the whole point of it, which gets feed in
basically into a backlog where and the machine starts to do its
thing. And off the back of Agile and
DevOps, we now use the word continuous, not just in
continuous improvement which has been around for a while since
the Six Sigma days and and even before that, but we also tag it
on to things like continuous delivery and continuous testing
and continuous integration. So you know, it is, it is the
word of the day. And so when we can talk about
continuous improvement, it's really just making sure that we
are making something better. If you have a product, the best
analogy and probably the best use case for an agile delivery
team, once you've established a product, which I would argue you
know is not an easy job and falls outside of the scope of a
delivery cycle, Say you've got a web app which is successful,
you've done all the upfront startup things and you're now in
a continuous improvement loop of making it better, right.
That's, that's where we can use a a great example of continuous
improvement in action where you get customer feedback and you
add features and you do AB testing and you know you grow it
to target different markets. That for me all in itself is you
know, continuous improvement on a product.
However, we also can apply the word continuous improvement to
look at processes, right. So a process regardless of
product is just not operating in an optimal way.
In reality it's usually enough that the there is benefit, more
benefit than cost to change what we're doing and that's an
important factor there. So not all things not everything
will be working perfectly and and actually to be honest
perfection I would say is is you know the opposite of progress in
some cases. So you know aiming for
perfection's it will never come plus the world changes which you
can't control hence you know move forward.
However with continuous improvement we talk about the
fact that when something has a strong business case and I'm
going to use that in a general sense.
So it simply that the cost benefit analysis is positive.
Say that again in more simple terms that it might sense
spending money in time and effort fixing an issue such that
you know that the outcome of spending that money in time and
effort will be more valuable than what you had before.
OK, so that's simply what we talk about when we mean
continuous improvement. Now there are methodologies for
doing that. The the analysis we're looking
at this process end to end, let's say the easiest example in
the examples where continuous improvement was really
corporalized was in manufacturing.
So you know things like Toyota and the the building of cars and
you can imagine it actually helps to have that analogy.
It actually helps to have something simple and real.
So you've got to convey about with an order and it's not
really focusing on that really. It's really the assembly line
which they were focusing on and making sure that they were
removing inefficiencies and reducing costs, OK, over the
long term. And they there is the concept of
lean, the word we've talked about before 6 Sigma, there
were, you know, there's there's a whole Kaizen, there's a whole,
there's a whole movement which is still with us today.
And a lot of that is aligned with the Agile movement, all for
that. But in simple terms, if you
don't know anything about those methodologies, I really suggest
that you learn about them, that you learn about 6 Sigma
specifically in lean. And just read those stories,
they're just fascinating, really great in the general sense.
I am a very, very, very, very pro removing waste, which is the
word that was used from a process, OK, because it just
doesn't benefit anyone and it's not necessary to drive the
bottom line or reduce costs or get rid of people's jobs or
anything. Any of those outcomes that
corporations might be looking for.
My I just don't. I just don't like it when there
are unnecessary steps that don't benefit anyone and society.
Can be can be one of the people that lose when you spend money,
the wrong money in areas which are inefficient where you could
be spending them on other areas. So this is not confined to the
corporate world. So continuous improvement is
around taking a process and looking for initial efficiencies
and then you know you really move from a a current state to a
future state process in stages, which is important like the
agile cycle. You don't do everything at once
because you want to measure that the change you made actually
made a difference and you might try things, you might not do
them all. So it's not necessary.
You've hooked on changing Step 2.
You know you you try different things and and and those
methodologies have a good way of measuring.
They've got different measurables to measure.
You know how efficient the process is.
OK and where the areas for improvement are.
OK. So that's the that's the bottom
line when it comes to continuous improvement, it can get you
know, quite scientific actually. Now we bring that up, that's so
we don't need to talk about the those particular methodology.
You can go and read about them. But in the general sense you're
improving a a process that existed continuous improvement.
So we've just said we can improve our product in the sense
of agile and you can feedback and make it better and I'd argue
that's what product management is all about.
You have to make your products better or they will just,
they'll just die death, OK. Product management is not about
just owning, you know, product ownership or just keeping
ownership of the product. You have to improve it over time
or do different things. So you know, you might say Coke,
the formula for Coke hasn't changed since they tried some
stuff in the 80s, but they do bring out new products.
So we've just said Coke 0 now. So they don't don't think for a
minute because the base rule product, the actual formula of
Coke hasn't changed in a while say let's just say that that's
true of their main product which is just the standard Coke.
They are always were looking at improving processes at
Coca-Cola, OK. They're reducing costs and
selling more moving into other countries distribution, they're
a huge distributor. They're actually to be honest
that the main part of their business is how to distribute,
you know they acquire other other brands.
They you know are playing with their their diet range as we've
just talked about they know sugar range and how they best do
that. This will continue that there is
a constant continuous improvement in Coca-Cola.
So don't think don't if you just you know take it at service
level might look like some of these products don't change over
time. They really do OK and the
companies do and they respond to the market.
So that's continuous improvement.
The product, the company itself and processes which form the the
company. And of course there's people,
processes and people. The way to improve people only
use a continuous word here is to take a mindset of continuous
learning. OK, so continuous learning is
really important here. So not only do we have
continuous improvement in those areas, to continually improve
yourself, you need to learn and you need to adapt and you need
to experience. And for you as ABA, this is
where this is where the topic becomes more interesting and
that is the fact that you have a challenge in your role.
You have a challenge as ABA and that is that the business
landscape is continuously, it's changing all the time.
OK. So you're you're forced to
respond to that. There are cycles, yes, there are
cycles and patterns, but the business landscape always
changes. There are new tools,
methodologies, industry trends that have merged.
They merge all the time. If you see any interesting
interviews with Elon Musk or Bill Gates, you know and Co,
then the question. They always get asked these
questions right. Their first question is what do
you think about AI? Or you know, what do you think
about machine learning or. Those topics have been on the
table for a while. You want to be good at your job.
You should be able to talk about these topics.
You won't know about all of them.
There are, there are days, every day I will be in a situation
where someone might be talking about something that's new that
I don't know about, but I have an obligation to go and learn
about that and be educated, especially before a workshop
where they might be talking about this topic.
So that's your job and that's a challenge.
Just moving on. That's slightly different from
that point apart from new trends and methodologies and industry
and waves and we are in a tech evolution.
So we've had the you know the industrial revolution and we
have it. We're still in the tech
revolution and now we're probably looking at more of AI
such a a big term but the idea of I won't call them robots but
I I just the idea that some of the task manual ways of working
and and and I want to I need to be very careful with my words
here but some of the manual ways of working that don't really add
value to you, your life your output so they can be done by
anyone. So they're the kind of jobs that
you would look to outsource or you know, big corporations would
get done in 3rd world countries can be done by robots as opposed
to humans and that will totally change.
Even if you are worried about other uses of AII can tell you
for sure. When it comes to people labor,
AI will have a huge impact on that.
So you can't ignore it. OK.
Even if you are not worried about some of the higher level
uses of AI, the market, the working class market is is going
to completely change and and and no I don't believe that it will
as Elon or Musk says that it will necessary benefit humanity.
OK, it might get rid of manual tasks that we think are just
it's silly that humans do. We'll look back at it and say
why are we doing you know merging two articles into one or
rewriting an article and they'll say well you know a a computer
can do that once you feed in the right algorithm and and
methodology and train it. Now that might be true, but the
the reality is that what's going to happen is that a lot of
people doing low skilled labor jobs which all involve just time
and data entry, they they're not going to do that anymore.
They're going to be done by robots and that will have a huge
impact on the market as we as we as we move forward.
So just take that as a point, write that down, willing to put
bet you $20 on that. So there's that.
But then there's also the fact that, and and I'm going to use
the word value. And I've just talked about an
example of, you know, people losing jobs because of AI
development. But your job as ABA is to talk
about value. And what part of that is
people's, you know, people doing work that's unnecessary and
unnecessary is different from work that can be done in a more
efficient way. So continuous improvement might
be saying, well, this particular task in a factory where the
people are kind of taking the doors and attaching them to the
car, we've, you know, you've done the analysis and there was
a robot that can do that much cheaper, that totally might make
sense. Obviously there's some impact to
the employees as a result of that and you know,
redistributing that that labor into a better area, like maybe
turning that person into a a machine technician or engineer,
that might be a best use of time.
And I'm as much as you might have a view on an empathy for
those people. Your job is to look at the best
value, the big, best use of resources in a company.
OK. So your job is to stay informed
and provide the best value. OK.
So this is all what continuous improvement is about.
OK. So, so we've talked about that.
So your job is to respond to look at market trends, to keep
up to date and to and to kind of keep learning yourself as a
person. Now when it comes to things like
Scrum, so specifically within an agile team, now you can Scrum
agile use it interchangeably. That's a really good example
where continuous learning and improvement is built in.
So you do a Sprint retrospective, which is around
to look at the team internally, looking at the team what went
well, what could be improved, what should be adapted.
So I I like that analogy because that's exactly what continuous
learning and improvement is about.
It fosters that. It's built into the framework.
There are what we call empirical process controls.
So Scrum is an empirical approach and so we are making
decisions on what's observed, not what we think.
And we learn from that throughout the project.
So it's kind of the idea of having this kind of, I guess
it's iterative approach allows the team that you're working
with to learn from successes and failures and refine OK as well
as the backlog because refinement is what is built into
the backlog grooming. And the fact that your list of
requirements that you start with might be quite different at the
end in terms of what you plan to do upfront.
And there's a there's a kind of a principle which talks about
inspecting and adapting. So Scrum emphasizes the
importance of inspecting the current state of a project and
then adapting the pro approach based on learnings.
OK? And that cycle promotes
continuous learning throughout the development process.
So that is how you can incorporate, I guess by looking
at the benefits of Scrum, or at least even if you're not in an
Agile ish environment and you're working in a more traditional
way, you can still do these things.
You can have a a retro by looking internally.
You can, you know, start to measure things and based on
what's observed, like a scientific method, you can
inspect and adapt based on what's worked for the last
series of time. You can call them sprints if you
want and you also have the concept that within within Scrum
Agile is that you are releasing the product and getting
feedback. So incorporating and I don't
talk about that enough really, but the idea that customer
insights are feeding your backlog, not your just your
product owner, you know this, it's very soft around that.
But there should be a stronger emphasis which is better I guess
explained in product management and we've talked about that
before with some great gifts that the customer is feeding
back. So ultimately are they buying
it, what are they using, what's their features, you know and
incorporating things like hot jar on your web app and seeing
where they're clicking and improving the user experience or
you know is all is all that. So that's continuous learning
and improvement and I don't think you can, I actually don't
think you can. If you're looking looking at
this higher level of abstraction, like I said, not
down in the weeds. I don't think you can actually
pull apart continuous learning and improvement.
So continuous learning is is and improvement is kind of locked
together what and I guess it's a Venn diagram because you take
learnings, you might not do anything with them, but the
overlap is where you've you've actually taken learnings and
you've improved, right. And you can have continuous
improvement which is a bit more random not from learnings just
by trying things which is wasteful.
So the true continuous improvement, I would say, OK, so
this is, you know, those who have studied 6 Sigma and all the
rest of it. For me, true continuous
improvement relies on continuous learning, right, And learnings
generally. And the overlap you've actually
got a reason to look at improving a process, not just
trying to improve everything and spending lots of money and then
not actually having a better outcome.
So that's important. And then in terms of practical
uses of continuous improvement as a whole at the Beta Business
Analysis Institute we talk about release and operational
improvement at the end of a of a of the kind of journey and you
know the the two big topics we we've squeezed them into one and
because I think it's really important that you are aware
that when you're released it's not done.
So you're looping back and and that all connects quite nicely
with Scrum and the idea is you're releasing and then
there's usually and the reason we don't collect continuous
improvement, we call it operational improvement, is that
at some point I guess it's continuous if the program and
the project team is still working.
But it's usually an operational team and you need to appreciate
that when you're handing over a project which might have all
this great continuous improvement culture, continuous
learning baked into it, man that that can die at death when it
goes to operations. If that isn't the way your
operational teams are set up or whether or not that team isn't
already an operational team delivering you know the delivery
side like you know they're not already a internal delivery
team. So you've got to be really
careful about how you hand that over and you need to hand over
more than just the project and the product and the insights and
the documentation as we always see and the and the training
guides. You need to hand over the
culture that actually this is, this is how we do it.
So you know in a product, true product management shop that is
all done because it's baked into the fact that product's going to
be there for the end of its life.
Having product teams and the operational area is is OK.
I I think they need my personal preferences.
They're one and the same as the project team, overarching, and
they're involved in change. Not like true change, big
changes, not just tweaks to the product.
But as we talk about at the institute, release and
operational management of the product or service really
contributes to the betterment of of the product, right.
It it it contributes to how you do that.
Sorry, I guess how you do that is a is a hugely important step
and we need to kind of think about things like release
planning, you know what does that mean in terms of the the
risks that we have on the project.
When you think about how we test it continuous, I guess quality
assurance and continuous testing maybe our acceptance criteria,
change management, benefits realization and then and then
right. So we can think about all these
things when we do release management and then of course
we're thinking about OK, well when this does go over to the
operational teams, we need to collaborate with them to look at
ways in which we can actually establish process optimization
after the fact. So it is not even though we've
got these continuous improvement and learning processes within
the project, it is not the product team or deliveries job
to make it the most optimal process, right, The not to loop
around the most optimal process when delivering their product.
I'll say that another way, the goals of the project, the
delivery, the production, let's say it's a new product, There is
usually nothing written into the objectives.
There's nothing in the business case or the link canvas.
There's nothing that says and and in some ways I'll justify
why that you need to make sure that the process is the most
efficient, quite the opposite by delivering something very
quickly and by focusing on the user stories within the job to
be done to get the result and focusing on where the customer
we're going to get the biggest value, value driven.
That's the whole point in releasing a product to the
market, focus on the value. You are actually maybe flying in
the face of process optimization.
OK. So we're just going to be really
careful here. We've talked about before that
you know a project might spin up which is literally taking an
existing process and we may be trying to improve it, OK.
And that generates a project, right.
That's that's that's one way of looking at, that's one angle Now
in the in the kind of situation where you're talking about a
product, right. And and probably the same for
people by the way, it's not always you know, the most
optimal situation for them to be in and we'll come back to that.
But in regards to a product, that isn't the goal, the goal
isn't necessary. Making sure that every single
process step that a customer goes through to interact with
your product or your back end processing or the way you
support it or even the kit it runs on, none of that, none of
that journey is focused on making sure that that is the
most efficient process step. I would say it's the opposite.
It is the most. It's usually the most MacGyver
way you can do it. Now hopefully, if you're this is
a scalable product, you've baked in, You've taught, you've
thought about technical debt From a technical point of view,
you've got architects, business architects.
Thinking about how this might long after the product is in
market, you've already thought about how it can be integrated
with the rest of the ecosystem and you've even baked into the
project plan or the program or the operational support budget.
This is, this is the trick. So if you're in the situation do
this, I always say don't process optimize, OK.
So I'm going to say, OK, sorry, sorry, let me rewind.
If the project is kicked off to improve a process, so you're
moving a process that's paper based into a system or another
system into a new system, you will probably do some process
improvement. That's how you generate your
requirements. You know what doesn't work
today? You won't just simply lift and
shift that process into a product.
So there's that side of it. OK, Making it better, OK, that's
fine. But now you've got that process
inside a new product and the combination of process and
product there might be more efficiency sees with the way you
use use the product now to fulfill those processes.
So at more down at the procedure level, OK.
And that level don't try and optimize that at the same time
don't fully optimize that process.
You will improve it by nature of moving to the to the new
product. The BA will work with you and
work out better ways of doing things and new UX, but you won't
really know. You won't really know where to
put your money improving that process right until people are
using the new product. Not at the procedure level, not
the low when I say that it's a lower process level.
Once you use the product, you might start using new features
that you didn't know existed before, and you might start
optimizing things like screens. OK.
And that is a different lens. That is a different lens.
Continuous improvement at that point is a different lens.
It's optimizing every single step.
And that's very hard to do if you don't know what the
solution's going to be. OK.
So like I said, you can do that with an existing product.
You can do that even at a high level process point of view.
But when you're and you can actually do that the procedure
level, all I'm saying is that if you're going to do a project
like where you're moving a process you've improved it, you
put into a new kit, the best time to do real process
optimization is about 3 months after you've released.
And there's something you should think about.
Don't try and intertwine those two things.
They're quite different. Even the skill set you need the
focus, you know, the fact that you don't really understand the
product, what you'll know after three months of using the
product with the process, the improved process probably that
you've put into the system, That's the point in using it is
you'll actually start to get some facts about how people are
using it, OK. And it's it's that's a corporate
example, that's an internal example like moving to a new CRM
system. But it's the same methodology is
all about, well, you don't know what to change in your product
until you release it to the market.
So when we talk about public facing products, you actually
don't know what you should change until you've got customer
feedback on it. Once the product's established,
it's exactly the same. We're moving to a new internal
system like a moving to a new CRM system or ERP is that you
can prove it to a certain degree, but you you know upfront
process improvement, but you won't be able to do procedural
improvement or low level process improvement until people have
used the product. I hope that's clear.
But when you do do process optimization, which is the
series I'm talking about, real continuous improvement, you're
starting to look at things like automation opportunities,
workflow enhancements, data-driven recommendations and
customer feedback. So all of those four factors are
feeding in and and that changes the focus of the project to be
more operational in my mind, right.
Not only people using new product, you know the new if
you've got a brand new product, customers using it or you're,
you know using an internal product and your users are using
it. All of those things, you can
actually have a different lens on the project after the fact
and it will save you money because you'll be spending money
in the right place if you do it after you've done the initial
implementation. What I'm not saying is don't you
know don't do any improvement upfront, just do the big things.
OK, cool. So we've got the, I think we've
ascertained that continuous improvement and continuous
learning overlapped and some of our project processes are baked
in for that. And we've just talked about the
fact that at the Better Business Analysis Institute, we think
about those things both in release and operational
improvement, OK, which is one of the stages of the delivery
journey. We're doing continuous
improvement and continuous learning throughout where it's a
that's a consistent mindset that we're applying just across our
organization regardless of team. But we are specifically saying
that when you go from release into the operational teams which
are probably going to be different.
We then have a specific phase and a specific lens that we are
now putting across our product and our service that is both
like we said to get the best bang for buck in terms of where
we spend money based on customer feedback that you're learning
know and user feedback once they've used the product.
But we're also not just talking about that, We're also talking
about the fact that our organization, we need to think
about how our product and our processes fit within the
organization. And I'll give you an example
there. So if your large corporate is
getting into a new business, let's say that your telecoms
company, so telecommunications company that just does mobile
phones very much a commodity company, decides that this is
not much different to selling electricity, OK, Also a
commodity that people need these days.
So you need your mobile in some kind of messaging and you need
electricity, OK. That's just the developing
world, that kind of necessities. Now they have sourced
electricity from a from a generator and they're just going
to sell it, right. They're going to do some kind of
wholesale agreement and they're going to sell it, start
packaging it together. Now all the processes that are
needed to support that new business stream, new product,
new service, one on the same that might exist outside of the
organization right now because it's just in a product team's
idea. And they're thinking about
things like building an interface and things like, I
guess, buy like how they're going to purchase this, how
they're going to manage managing meters and homes because they
are now a retailer. And so they need to worry about
all those things. They're worried about
disconnection, They're worried about customer services.
So this whole business model, well, let's just call that the
program or the project and the organization doesn't have all
that infrastructure set up. So as part of that project,
ideally, you've got phases, you've got sprints thinking
about that that's baked into the project.
But that's why we have a specific phase delivery phase
called release and operational improvement.
It's not just around improving the product, making it better.
It's also about the organization's ability to
respond to that new product or service, OK.
And it's around setting those things up, change management,
BAS may be involved in organizational structures even
fitting into that that probably the best people to place placed
on the project to go well, actually there's three or four
new processes. What teams do you have today?
There's a gap, capability gap and identifying that maybe you
know that you're introducing new services like quite different to
what you've got in your new team.
So if we take a telecoms company, they probably already
have a call center. They probably already got
customer acquisition. They're probably already
actually even clearer around connections and disconnections.
So you might think, well those processes, think about it for a
minute, they'll integrate with those tanks that do that today,
right. We might need new personnel,
more staff and more training, but they kind of fit.
But then equally you might have a process which is very specific
to the electricity market. Maybe it's, I don't know how you
the charge, how you charge the complex complexity around
charging or you know maybe that just goes to the finance team.
But there might be, there will be elements which are unique to
the electricity market and you don't necessarily have a team in
which you're going to hand that over to, right.
You don't just hand over the the box that is the project, you
hand over processes that have changed.
So you need to create that. So this is what this phase is
all about and the reason I bring this up and you could say this
is you're going off on a bit of a tangent here and I I am
specifically to say that that is you need to worry about all that
stuff, right? That is for me still the scope
of continuous improvement and learning.
It's not just about the project or the product or the services,
about the people and the organization responding to that
after the fact. And if you don't worry about
those things, if you ignore those things and you just focus
on your project and say they'll just take care of themselves or
wow, the operational team needs to get used to that, they're
busy. They're doing BAU.
They they've got enough time for this.
This is your job. This is your project team's job.
If you don't think about that and you ignore that, then all
that continuous improvement you've made throughout your
projects phase and all the great BA work you've done to improve
the process, it's all Nutter. It's all it means.
It can mean nothing. It can mean nothing if it's not
fully embraced and recognized by the organization.
And it's not just them accepting it like a, you know, throwing a
baseball and then catching it or whatever.
And other analogy you want to use.
You know, they need to prepare, They need to have the Met, They
need to know how to play the game, and you need to do that as
part of your program. OK.
You as ABA are critical in that. So the final point I guess I
want to make around continuous improvement in learning and and
why I'm stressing, it's so important and needs to be baked
into your project, your mindset. The four PS that I've talked
about with you know people and processes and products right and
projects is that you also have 222 other kind of aspects here
you have the continuous learning from the project team itself by
sharing that knowledge. This relates to the last point I
just made around having knowledge sharing sessions.
This is where you're this is the way in which you are doing what
I would say the greater change management, change management
plus plus where you encouraging members of your team to or
expertise in the in the team to cross pollinate that knowledge
that you've learnt to the organization.
You can talk about what you've found.
You know you're in a lucky spot. You are.
In some ways, the operational teams can get jealous of this.
And this can happen, especially if the team that's working on
the project as a contractor or consultant.
You know there can be jealousy here, so you need to share your
knowledge. Your job is not to retain that
knowledge. If you are a contractor or a
consultant, your job is to empower and leave the
organization better than you found it.
You can have brown paper bag lunches.
You can have lunch breaks and formal presentations, talk about
new topics, industry trends, lessons learnt, what's going on
in your project and updates something fun demoing back to
them. You can also like integrate
operational members into your team.
So this is all about continuous improvement and learning.
It's about the people side by maybe pairing up a team member
with a less experienced person. Sometimes you know you might
have a senior programmer in your team and they're working with a
junior and you know they can't afford to pay the best wages for
internal staff. So you end up with a junior
there and you know your job is to transfer that.
That can be quite rewarding. There's also around the fact
that you could even this is this happens infrequently but I I've
recently been involved in this where we're encouraging the BAU
operational team to have a learning budget right.
And because you're you're on the project so you're working with a
product let's say you're just integrating off the shelf
product. So some product that you've just
as part of the project you've integrated or put in a product
and someone's going to look after that and you find out
because you know how's the operational team because they
know about it. You're the one who's worked out
that it's going to fit and you've done all the the work in
terms of requirement management and your architects worked out
technically, it's it's nice and you and you've your projects
worked on it. And as part of that learning you
pick up that the certification for learning how to use this
product is cheap, right. It has certifications, it has
learnings, it has conferences. Salesforce would be an example.
Dynamics 365 would be an example.
There's a whole ecosystem around these products.
And so you can maybe suggest to the team that you might be
handing it over to or your SME team that, you know, your
project manager could do this, that they need, that this is how
much it costs to get educated in this area.
And so as part of your project, you could put out some of these
recommendations that people get trained in these tools.
And so they're ready. Like I said, they've got the
mat, they're ready to catch the ball.
You could also suggest there's some learning time for them and
you could do a bit of a, you know, a bit of a playback
session to that team. So I think there's, there's some
good ways in which you can help with operational improvement or
continuous improvement in learning for the organization
outside of the project team that you're working on, OK.
You know, allowing them to be involved a bit more, sharing,
you know, you're fostering this continuous learning in a kind of
collaborative way. I think that's really great.
So there's that aspect, right. And then finally there's the
aspect about yourself, OK, we talked about like learning,
keeping ahead of business acumen and soft skill development.
Well, not not so much on soft skill development but industry
trends and how you can provide value but and emerging
technologies. But one of the things that I
think that you could do as ABA and I touched on it there with
the soft skills kind of gave it away is just making sure that
you are continually learning yourself, OK about your own
tools, techniques, processes, you, you as a human also, which
I you know not very good at, there are things that you could
learn to be better with soft skills.
So getting certifications, courses, micro credits,
listening to this podcast, you know, going on to our website,
reading articles about BA, going to conferences, all of that is
continuous learning and improvement of yourself.
So I'm going to suggest that you find one area where you can add
or improve yourself 1%. So it might be going for a walk,
you know, not drinking as much, taking some time out, sleeping
in, you know, it doesn't have to be anything big.
It's your list, it's you. But improve yourself by 1%.
If you do that every day, then you know it's just like
interest. You'll end up in a much better
place than you are today. So I think it's really important
that you do focus on improving yourself.
What it allows you to do, and the reason why it's good as BA
to do this exercise, is that by having a mindset of continuous
improvement on yourself, you're able to find and look for and
recognize continuous improvement opportunities in a business and
just in life generally. So I'll leave you with that
action, which is to continuously improve one area of your life by
1% every day, and I'll see you on the next episode.