7.1 Business Case and Problem Statements

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

9 hours 3 minutes
Video Transcription
Hi, guys. Welcome to define phase Business case and problems statement. I'm Catherine MacGyver, and today you're going to get an understanding of what makes a good business case in a problem's Damon and have the framework to start documenting these for yourself.
So I want to stop right now and congratulate you for starting your first domestic
project. So if you remember back Thio through our quick hits at one point when you start articulating what your problem is, you need to make the decision as to whether or not this is a P D. C. A quick hit,
a just do it or common sense or a domestic project. And if you think that it's a D make project, do you remember that those air four criteria
for what makes a good lean six Sigma project it? Number one has thio be a process. So have defined inputs, activities or a process. Andi outputs.
It has to be measurable and re measurable. It has to have a process owner, and it has to have no defined solution. If you already know what the solution is, you should just do it. So we're going to have gotten past all of that.
You know that this is a domestic project and now we're going to get started with that
by starting with our problems statement.
So when we talk about our problems statement in our business case, they are often done in conjunction with each other. But they are two different statements. So your problem statement is what is the problem? So this is going to be what exactly caused you to think that this is somewhere that you need to do a process improvement effort
and then your business cases? Why does it matter?
So this is a little bit different than some of the other project based methodologies because business case and Problems statement can get intertwined. But remember where the differences in a lean six sigma
is that we don't have a defined solution. So we want to make sure that the white is it or the what does it matter? And what is the problem are very different things, so that we can clearly frame the need for this
eso remember that we start the problem statement on the business case because your project hasn't yet been chartered.
So you are somebody who has recognized that there is something going on that you think merits a domestic projects, so you're going to start drafting your problem. Statement In business case, I prefer that my practitioners start with the problem statement
in the way that I teach all my practitioners to write a problem statement is. Imagine yourself as an old school reporter
and you're going to want to make sure when you document your problem, statement the who, what, when, where and why of the problem. So when we talk about this, we want to know what is the problem? What exactly is the problem? Beers explicit as possible. If you're talking about defect rate,
is it on? Lee defects for product
for parts that have this component? Or is it everything that goes through the manufacturing line? Who does it impact? So this is going to be your customer conversation? Is this an internal customer? So we have high levels of orders that are not filled correctly or filled out correctly.
So the fulfillment departments having to do quite a bit of re work, or is this high levels of orders that are not filled correctly
and your clients and your customers are feeling the impact of these defects.
Why does it impact to them? So this is where you're going to talk. About what? What exactly are those downstream effects from whatever this process is. So when we talk about that fulfillment department, the impact is they have to go back to whomever filled out the order and
complete a new order. So you have high levels of real work, which is causing delays
and decreased capacity on when you're talking about with your clients and you fill your orders incorrectly. The impact is the clients don't get with a purchase that causes decreased satisfaction, and your clients move on. When does it happen? You want to be a CZ time bound as possible. And this is for specificity.
If this is a 24 7 all ships all the time,
make sure you call that out. If this is on Lee on a certain shift, make sure you articulate that and where does it happen? So this is going to be Is this only one production line? Is this only one department is this Every department that uses the system, make sure that you help frame the magnitude of your problem.
So ah, couple of examples. A bad problem statement is our pizza orders have too many errors.
A good problem statement for the same type of thing is our pizza. Orders for the weekend shifts at the flagship location have what is perceived as a high error rate, exact percentages to follow. That causes customer dissatisfaction
by having to either accept a pizza they didn't order or by insisting that we remake the pizzas,
resulting in delays and waste. So you will notice we have the Who That's gonna be. Our customers are what high error rate are when it's going to be. Our weekend shifts are What's that impact? So this is going to be they have to either take the pizza or insists that we remake it
and where. So this is going to be at our flagship location.
So this is a really solid problem statement. Something to call out right here is exact percentage to follow
your project charter, which is going to be the document that's going to capture all of this information is a living document. Generally, you don't get to see these exact details and these measurements until you're in the measure phase and you're capturing the baseline metrics. So, for example, ah, hi, error rate. We don't know.
I know what a high error rate is right now. We just know that it's perceived as high, so that could be 2%.
Could be 12%. It could be 20%.
All right, so a business case is, conversely different. So when you talk about a business case, think of this as your state of your department address. You are the president of your department, and you need to tell us why this department or process is important to your company. And if this isn't fixed,
what the problem is like, why do we care that this needs to be fixed?
bad business case we're carrying forward from our problem Statement is the flagship pizza shop is the most important store.
Sure, a good business case would be something along the lines of pizza unassociated menu items currently comprised 100% of revenue generation.
What thus, a decrease in customer satisfaction could directly impact the operating emergence. It's pause and think
executives are probably gonna want to know about that. The issues with the flagship pizza store have the potential to undermine our pizza chain's brand as marketing research has shown that this store is the model for customer perception of our pizza quality. So if you were an executive or a sponsor
went reading this, you're going to read, Okay, money,
more money. Brand perception, Yes. This is something we need to fix. As compared to you, the flagship pizza store is our most important store.
Yeah, we all know that on. So when you're articulating your business keys, you want to think about how can you make the importance of this resonates such that a sponsor wants to take on this project.
So when we're talking about our problems statements in our business cases, this is where you get started. This is how you articulate that there is something that needs to be done. So your problem statement the who, what, when, Where and why. And this is in fact, important to the business. This is your state of the department address
This the problem statement in the business case are what set
the expectations and subsequent objectives, which is our next module for your lean six Sigma project. So
practice your business to practice your problem statements in your business case. We will talk quite a bit more of it as we go through. Andi, I look forward to seeing you for objectives and deliverer, Bols.
Up Next