- The business case.
So the first theme we're going to talk about
here in PRINCE2 is the business case.
What is a business case, well it's a document
and this document is going to help us to put systems into place
that will assist the decision maker
in determining if a project is worthwhile or not.
It really comes down to letting the executive make a case
for why we should go forward with this project.
This is going to be implementing the principle
of continued business justification.
So as we mentioned in the last lesson,
each of these themes is going to be reliant
upon implementing those principles.
And later these themes are going to be implemented
through the processes, and so you could see
how PRINCE2 starts building upon itself.
Now, how many business cases are there for a project?
Well, there really is going to be two.
There's going to be one for the customer
and one for the supplier, because each comes at a project
with a different vantage point and a different perspective.
And they have to convince their bosses
that they should undertake this project.
And remember, PRINCE2 always assumes
a Customer Supplier Relationship.
Now, the customer is going to specify the products
that they're going to be required for this project.
They're going to pay for the project
and they're going to expect to receive some sort of benefit
by the time this project is over.
The supplier on the other hand
is the person, the team, or the organization
that is going to deliver those products
to market under the agreed upon level of quality.
So if I wanted to build a website, I may be the customer
and I need to hire a supplier to build it for me.
That supplier has to determine,
is it in their best interest to build it?
And that best interest may be defined
by how much money they're going to charge me,
or how long it's going to take them,
or will they get more business in the future?
They're going to have to determine
whether it's worth it or not to them,
just like I need to determine
whether or not it's worth it to me
as a customer to pay for this and to get these products.
So the business case is a document,
and this document is owned by the executive.
This is one of the PRINCE2 management products
that are going to be produced
throughout the processes of PRINCE2.
An acceptable business case has to exist at all times,
otherwise the executive should close down the project
because it's not going to get you the benefits you want
because again you're balancing time, and resources,
and quality, and money, and all of these things.
And if there's not going to be a big enough bang for your buck
you should terminate the project.
Now, when you're trying to decide as an executive
whether or not you should continue forward
with the project, you should always do it
with a sunk cost analysis.
And what I mean by that is, you need to determine
whether or not to move forward, without really relying
on looking back of how much you've already spent.
Because that is a way to blind yourself
into making bad decisions.
If you've ever played in a poker game
like you see here on the screen
you may have found yourself in this position.
You put in your blind of five chips
and then you put in your call of 10 chips,
and then the round of betting happens
and you put in another 50 chips.
And now you're at the last bet and somebody raises you
and you know you don't have that good of a hand,
but you're like "Well, I already put in 65 chips.
"I feel like I have to go forward."
And they call that pot committed.
Well, if you're using a sunk cost analysis
you would not even consider the fact
that you've already spent 65 chips to get to this point.
You would only look at the point you're currently at
and whether or not it makes sense to continue on forward.
That's the idea of a sunk cost analysis.
And so, when you're doing these business cases
and you're determining whether to go or no go
to the next stage, always use a sunk cost analysis approach.
Ignore what you've already put into the project,
only think about what more you're going
to have to put into the project to get it on track
and get the products out that you need.
And if that's too much,
then you're going to terminate the project
Now, when you look at the business case
the first business case you get in a project
is actually only going to be a draft, it's going to be an outline.
And the executive again should be the one producing
this initial business outline.
In some organizations that's actually maybe handled
by your corporate or program management board instead.
And they would provide the outline to the executive
to charge them with this project.
So for example, if I wanted to build an app
like I've used that example before, I may
as the program management come up with an outline
of what I think the app should do
and roughly what I think it may cost.
And give it to an executive to start working
on that project and move forward.
But once I turn it over to the executive
they own it from that point out.
Now, that initial first draft outline of a business case
is then going to be updated with additional levels of detail
as we go into the initiation stage of the project.
To initiate a project and get into the initiation stage
we only need an outline, but to get out of
that initiation stage we do need a complete business case.
And the business case is also going to be updated
at every stage boundary because we have to make
a go/no go determination on whether we're going to move
into the next stage, or terminate the project.
Now, we're going to come up with specialist products as well
as part of this business case.
These specialist products are the outputs
that are going to be found at the end of the project
by the users in the customer's organization.
So these products should positively change the way
that users conduct their business as usual.
So if they're normally used to filing things one way
and we build a new filing system
it should be a better filing system
than the current way they're doing business.
And that would have them realize a benefit.
The change that's going to occur here is called an outcome.
And any benefits are measurable improvements
and those would be different types of outcomes
as a result of this project.
Now, when I look at the benefits.
Let's look at an example here, one project I worked on
was we built a travel approval system.
It was a very small project, it only cost a couple
of hundred dollars, but its a great example here
of giving benefits to end users.
When I first got to the organization
the way that they dealt with their travel approval
was by routing manual paper copies.
So the person who wanted to go and travel would go ahead
and fill out a form of where they wanted to go
and they would look up the cost for the airplanes,
and they'd look up the cost for the hotels,
and the rental cars, and all that information
and put it on a piece of paper.
And then they would go bring it
to their first level supervisor,
and they would sign off on it.
And then they'd walk down the hall
to the supervisor's supervisor
and get them to sign off on it.
And they had to do this through five or six different levels
of approval and then get it to the person
who would book the tickets for them.
It was a very cumbersome system.
And when you wanted to go through a travel process
it may eat up four or five or six hours
of your day trying to get approvals
and track down the right people.
So when I got there I was tasked
with building an automated system to replace this.
And we did this using some workflows
and creativity through a website.
And it got to the point where the person, the end user
was able to log on to this website
put in where they wanted to go, how much it was going to be
and the system would automatically route it
through email from person to person to get those approvals.
And we were able to decrease the time
for approval from two to three days,
by having to track down all these people,
into just a couple of hours
by going through this automated process.
It was easier for the end user, it was easier
for the supervisors, and everyone loved it.
This is a really simple way of showing what the end result
of this business case and this project was.
Now when I was charged with this project
the corporate management came to me and said,
"I know what I want, I want an automated travel system."
So they already gave me the rough outline.
Then as the executive I had to go through
and build out my first draft of that,
get it into project initiation,
get it through execution stages,
and then close out the project and deliver those benefits.
That's the idea here when you talk about benefits.
In this case it was minimizing
the amount of time it took to get travel approved.
Now when we look at benefits the senior user role
is going to be the one responsible for specifying the benefits
and ensuring that those are realized.
So in my case it was a very small project
so I served as both the executive,
the senior user, and the senior supplier
because I ran the IT organization.
And so, I had the role of all three.
And in my senior user role I spoke to the end users
and said "what would make this system work well for you,
"what do you want to realize?"
And the big things were they didn't want to have
to leave their desks to get approval for travel
by having to walk around paper all day long
and they wanted to be quicker and easier.
So we took those pain points and we found those benefits
and built a system that supported that.
The senior user is going to come from the area
of the customer's organization
that's likely to be impacted by those changes.
Now as one of the guys who ran the IT department
I actually traveled a lot.
And so I was one of these users that was feeling this pain.
And so it was very easy for me
to capture those user requirements
because I was an end user of this project as well.
But if you're not, you need to go
and get somebody from that area.
If I was going to build an accounting system,
I'm not an accountant, I would want to embed one of
those people on my team to make sure that we're going to get
the benefits needed for that area of expertise.
So the next thing we have is what's called
the benefits management approach.
And the benefits management approach is a document,
it's one of the PRINCE2 management products
that's going to be created through the project.
This is going to document how the benefits
will be measured, when, and by who.
So in the example of my travel system
we said we were going to measure the amount
of time it took to get something approved.
In the old system it may take two or three days,
under the new system we had a target of about four hours.
From the time somebody had submitted
their initial process to the time it got back
and was approved and ready for purchase.
We said we wanted this done when,
we were measuring it weekly and by who,
we were measuring it by our knowledge management
and information management team to see
if the system was working appropriately.
And that is the way we did our
benefits management approach for this small project.
Now this is updated when the benefits are realized.
So once the product was delivered
we then went back and said "Okay we said we were going to do it
"to a four hour window, we're going to do it weekly,
and we're going to do it by the knowledge management,
"information management team, is that still correct?"
And once we delivered the product
and turned it over to operations they started seeing,
yeah once a week was good, doing it
for four hours was good, but they didn't think
the knowledge management or information management team
should be the ones measuring it.
So instead this was turned over to procurement
because they were the ones buying the tickets.
And they got those tickets, they could see
when the thing was put in as a request,
and when the ticket was actually bought.
So it's easier for them to measure it.
And we updated that when the project was closed
which is very, very common because that's when it's
going from the transition of building it into operations.
And it's a different team that will be measuring it.
Now let's summarize this whole business case theme up.
There are three minimum requirements
that you have to do inside of the business case theme.
The first is you have to define roles and responsibilities
for the business case and the benefits management approach.
Who's going to write them
and who's going to be responsible for them.
As a general rule, the executive is responsible
for the business case and the senior user is going to
be responsible for the benefits management approach.
But it doesn't mean they're going to write them,
it just means they're responsible to make sure they get done.
Then, we're going to make sure that
a business case is created and maintained.
And finally, we need to make sure
a benefits management approach is created and maintained.
If you get those three things that is the minimum
that you need to fit the theme of business case.