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 53 minutes
Video Transcription
All right, guys, Welcome back. I'm Katherine McKeever, and today we're going to discuss more business cases and problem statements. So we have come into here with the presumption that based off of the last module, you have selected a project and you have taken into consideration the size that you want your project to be.
We talked quite a bit about business case in problems statement in yellow Belt because this fundamentally lays the foundation for your domestic projects. So we're going to go into that in more depth today.
Now, if you remember back from Yellow Belt, we said that your problem statement was your who? What? Why, when and where? Questions that you're able to answer to articulate. What is the problem? Or why is it that we want to invest our time and energy insanity into fixing this problem?
So you want to make sure that you clearly state what is the problem? So saying it's not good enough
is not good enough. We want to talk about who does it impact so that you're gonna be both your internal and your external customers were to talk about. Why does it impact them or more specifically, what the impact is to them. So because X
we see why eso you're going to start developing your idea of some relationships, but you don't need to document them in the problem statement right now.
When does it happen? You want a timeframe on this? So you wanna temporally bound this because you can't say it always happens unless it does actually always happen. And where does it happen? So this is really this is going to help us narrow down when we get to our scope. Where in the process does it happen?
Gives us a sense of where we need to focus our energy.
So with that, I want to talk a little bit about what are not problem statements. So you want to keep these things in mind as data points, but certainly
not as the Beale End all, um and certainly not without data. So the first thing is not a problem. Statement
is an opinion. We can do this better. That's not a problem statement. Um, certainly these. These are people that you want to engage the stakeholders if they have an opinion, means they're passionate about the process.
So keep these things in the back of your mind when you're thinking about PDC, a key stakeholders who can help engage in your project, even arguably champions
past experience It used to be this way.
Still not a problems. Damon. You might be able to quantify it with data like the way we used to do it is better, but just saying this is the way it's been
isn't good enough. I'm six cents. So saying that I have a Spidey sense more a gut instinct that says that there's a problem here without quantifying factors means that you're going to set your project up for success by not having your objectives in your baseline measurements as you go through this.
So if we remembering Yellow Boat, we talked about the we fixed something, but now we have to go and figure out what we fixed.
That's where these come in
on the last one. I wish I was kidding on your bosses. Spouses. Intuition
is not a problem statement. Enough said
so with that, a bad problem statement would be something like our pizza orders have too many errors. Eso We talked quite a bit about our pizza giant and yellow belt
huge over our king. Our pizza orders have too many years. There are a lot of different areas for interpretation on this. So instead, a good problem statement would be our pizza. Orders for the weekend shift at the flagship location have what is perceived as a high error rate.
We're gonna say exact percentages to follow because we haven't hit measure yet.
That causes customer dissatisfaction by either having to accept a pizza they didn't order or insisting that we remake the pizza, resulting in delays and waste. So we have the who, what, where, when and why. All in this statement this paints are really clear picture for
me as your executive and you as the project facilitator leading your team of what exactly is going on. And what do we want to look at to make better.
when you're writing your problem, statements win in doubt air on the site of over description, because this creates your foundation or your North Star document throughout your project. If you feel your project getting off track, you can go back to your problem. Statement. Say this is what we're here to do
and help refocus your energies.
Conversely, your business case is the Why the heck do I care? This is your State of the Union address. This is why is this department or process important?
What happens if it doesn't change? So when we talk about my pizza example, if we don't fix this all of our customers we're going to go to the competitors. But this positions you within the organization.
So we talk about our value stream. Your state of the department should paint a picture off where you are in your value stream to give us an argument as to if I have, ah, 100 widgets, you get 85 of them. Because of your so important to the company, your customers will leave
these types of things.
So when we talk about a business case, you want to understand what what the impact is. So you want to try and keep this framed in the idea of strategic objectives? So remember when we talked about project prioritization? We want our projects tow line up with our strategic goals that you want to frame your business case
in that same way,
so important things to keep in mind. What is the project worth to your organization. You want that to be crystal clear. And what are the consequences if your project isn't done if things stay the status quo and you want to try and be concise in this business cases air really exciting because you could talk about all of the different ways that your department, where this process is important.
But then you kind of lose the meaningfulness. As you start to ramble,
I start to ramble. I write really long ones and then pair them back. Ah, good rule of thumb is try for about three sentences on your business case.
So an example. Ah, bad business case. The flagship pizza stop is the most important store
bad. A good business case. Pizza and the associated menu items comprised 100% of revenue generation. Thus a decrease in customer satisfaction could directly impact the operating margins. This is going to be what happens if we don't do the project, and it touches a little bit on
how important pizza is
because we mentioned are 100% revenue generation. The issues with the flagship pizza store have the potential to undermine our chains brand. As marketing research has shown, this store is the model for customer perception of our pizza quality. So now we have a, really, really clear what if
so we're talking about. Okay, we make the money. If it goes about, there's less money. But even more importantly, there's bigger ramifications if we don't fix this because we're talking about our customer perception and we're going back to our voice up.
So that's an example of a good business case. This should ring a bell because these were the case studies we used in Yellow Belt. So these should resonate for you guys, if not review Business case and problems statement modules. So with that, we reviewed how to write our business cases. In our problem statements,
we talked quite a bit about what quantifies our problem statements.
We're not going to use our bosses, spouses, intuition to track down
ghosts or bunny trails in our organization. So, business case why this is important problem Statement who, what, when, where, and why to get us down to this is what we're here to fix
in our next video. We're going to go over scope. Resource is objectives and delivery, Bols. So I will see you guys there
Up Next