The Project Success Model ™

The Project Success Model

A Guide to Defining Project Success

by

Henrico Dolfing

www.henricodolfing.com

Version 4.0
Copyright © 2022 Henrico Dolfing. All rights reserved.

2
 The Project Success Model ™

Content
1. Introduction 4
2. When Is a Project a Success? 6
3. The Three Levels of Project Success 8
4. The Project Success Model 11
4.1 Defining the Desired Business Outcome 12
4.2 Defining the Problem 12
4.3 Defining “Done” 14
4.4 Defining Project Delivery Success 16
4.5 Defining Product/Service Success 19
4.6 Model Relationships 20
5. Making Project Success Measurable 22
5.1 Objectives and Key Results 22
5.2 Don’t Turn OKRs Into a Project Activity List 23
5.3 Using Value-Based Key Results 24
5.4 OKRs vs. KPIs 25
6. Bringing It All Together 27
7. The Project Success Definition Workshop 28
8. About the Author 31

3
 The Project Success Model ™

1. Introduction

Alice: Would you tell me, please, which way I ought to go from here?
The Cheshire Cat: That depends a good deal on where you want to get to.
Alice: I don't much care where.
The Cheshire Cat: Then it doesn't much matter which way you go.
― Lewis Carroll, Alice in Wonderland

Study after study has shown that technology projects frequently fail to deliver on their
promises—by some estimates, well over half the time.

These reports show that 25 percent of technology projects fail outright and 20 to 25
percent show no return on investment. Just read my project failure case studies for
some prominent examples.

A large part of the other 50 percent needs massive reworking by the time they’re
finished.

The larger the project budget, the number of suppliers involved, and the number of
people working on it, the lower the chances of success. Some examples of such high-
risk technology projects are:

> ERP, i.e., introduction or upgrade to SAP/Oracle/etc.

> HC, i.e., introduction of Workday/SAP HCM
> CRM, i.e., introduction of Salesforce/MS Dynamics
> Modern Workplace, i.e., introduction of M365/G Suite
> Replacement of a core banking / insurance system
> Custom software development, i.e., a new product or service.

One of the main reasons why such projects fail is that, from the outset, they lack a
definition of project success.

If you’re unclear about what the project should achieve and to how to measure its
success, how can you steer the project? How will you make sound decisions? How will
you communicate its value? How will you prioritize and define its scope?

You can’t.

Still, many technology projects are implemented without any clear definition of project

4
 The Project Success Model ™

success. Just look at the billions of dollars that are wasted on technology
transformation projects without any meaningful business results.

Each large business-critical technology project needs a project sponsor, a steering

committee, and a project manager. And one of the first things this group of people
needs to do is sit down to define project success, how to measure it, and when to
measure it.

This is one of the most important things you can do in the early phase of a project to
increase the probability of success later on.

My proven Project Success Model ™ will help your executive team define success for
your key technology project.

I’ve written this eBook specifically for:

> C-level Executives or Board Members who want to make sure their business-critical
project is off to a good start.
> C-level Executives or Business Unit Leaders in the role of Project Sponsor.
> C-level Executives or Business Unit Leaders in the role of Steering Committee
Member.
> Project and Program Managers of large business-critical projects / programs.

While this eBook is written with a focus on technology projects, the concepts are
applicable to other types of projects as well. Clients and readers have successfully
applied the Project Success Model ™ on M&A projects, R&D projects, and others.

If you and your executive team need additional guidance to define success for your
business-critical project, just have a look at my Project Success Definition Workshop
in Chapter 8 or on my website.

5
 The Project Success Model ™

2. When Is a Project a Success?

“If you do not know how to ask the right question, you discover nothing.”
— W. Edwards Deming

Contrary to what many people think, project success and project failure are NOT
absolutes. It may not be possible to be a little bit pregnant, but you can be a little bit
successful.

Every project has multiple success criteria related to business results, product/service
results, and project delivery results (e.g., cost, schedule, scope, and quality).

Some criteria are absolute, meaning they must be completed on or before the original
planned date. Some are relative, meaning they must be completed by a date
acceptable to the client.

Project success is determined by how many of your success criteria are satisfied, and
how well.

Whether or not a project is successful also depends on who you ask:

> The delighted project manager who implemented the SAP project as scoped, on
time, and below budget (I know, this will NEVER happen).

> The users who absolutely hate the complexity and slowness of the new system.

> The COO who has seen IT costs double and none of the expected savings materialize.

They may all have very different opinions on the success of the project.

6
 The Project Success Model ™

Project success also depends on when you ask.

Twelve months after the go-live, the users will have a better grasp of the system and
initial performance problems will have been solved. And slowly but steadily, the
expected savings will often start to materialize.

So, to define the success (or failure) of your project you should:

1) Define all the success criteria relevant to your project.

2) Define how you will measure them.
3) Define when you will measure them.

7
 The Project Success Model ™

3. The Three Levels of Project Success

”A thing is worth what it can do for you, not what you choose to pay for it.”
― John Ruskin

Many people and organizations seem to have serious difficulties separating the inputs,
activities, outputs, outcomes, impact, and results of a project.

This leads to lots of confusion, bad communication, disappointed project teams, and
disappointed stakeholders.

Below you’ll find my take on these terms and their relevance to your project.

Inputs

Inputs are often confused with activities. However, these terms are not
interchangeable.

Inputs, in simple terms, are the things we use in the project to implement it.

For example, in any project, inputs include things like the time spent by internal and/or
external employees on the project, money, hardware and/or software, office space,
and so on.

Inputs ensure that the intended results of a project can be delivered.

Activities

Activities, on the other hand, are actions associated with delivering project goals. In
other words, they’re what your people do to achieve the project’s aims.

In a software development project, for example, activities include things such as

designing, building, testing, deploying, etc. In an upskilling initiative, employee training
would be an activity.

8
 The Project Success Model ™

Outputs

These are the first level of results associated with a project. Often confused with
“activities”, outputs are the direct immediate-term results associated with a project.

In other words, they are the delivered scope, the tangible and intangible products that
result from project activities. Outputs may include a new product or service, a new ERP
system that replaces an old one, or employees trained as part of a digital upskilling
initiative.

Success at this first level of results is what I call “Project Delivery Success”. It’s about
defining the criteria by which the process of delivering the project is successful.

Essentially, this addresses the classic triangle of "scope, time, budget".

It’s limited to the duration of the project, and success can be measured as soon as the
project is officially completed (with intermediary measures being taken as part of
project control processes). It always combines measurements of inputs and outputs.

Outcomes

This is the second level of results associated with a project and refers to the medium-
term consequences of the project. Outcomes usually relate to project goal(s).

For example, the new ERP system is used by all users in scope, uptime is 99.99%,
customer satisfaction has increased by 25%, operational costs have decreased by 15%,
and so on.

These criteria must be measured once the product/service is implemented and over a
defined period. It cannot be measured immediately at the end of the project. You’ll
have to run the system for 3 - 6 months before you can measure outcomes.

Success at this second level of results is what I often refer to as “Product or Service
Success”. It’s about defining the criteria by which the product or service delivered can
be deemed successful.

9
 The Project Success Model ™

Impact

This is the third level of project results and is the long-term consequence of a project.
Often, it’s difficult to ascertain the exclusive impact of a project since several other
projects, not similar in nature, can produce the same impact. Also, the overall
economy, weather, pandemics, and so on will make it difficult to isolate the impact of
single projects. Still, we should determine this impact per project as good as possible,

Examples of a project’s impact may include its economic contribution (increased

revenue, protected revenue, reduced costs, avoided costs), competitive advantage
(market share won, technology advantage), or compliance (FATCA, GDPR, etc.).

Success on this third level of results is what I call “Business Success”. Business success
is about defining the criteria by which the product or service delivered brings value to
the overall organization and how it contributes financially and/or strategically to the
business.

Results

Project results are the combination of outputs (level 1), outcomes (level 2), and impact
(level 3). These levels combined will determine your overall project success. You can be
successful on one level but not others.

Simply put, project success occurs when the results of the project add value to the
organization. The value of a project is defined by subtracting all of the direct and
indirect costs from all the benefits the project delivers.

Value = Benefits - Costs

In terms of accountabilities, the project manager is accountable for project delivery

success; the product/service owner is accountable for product or service success; and
the project sponsor is accountable for business success.

While this may sound simple and straightforward, the challenges will arise as you
attempt to clearly define the success criteria for each level, establish baseline values
for them, and then periodically review and measure them.

This is where the Project Success Model ™ will help you.

10
 The Project Success Model ™

4. The Project Success Model

"All models are wrong, but some are useful." ― George Box, statistician

The Project Success Model ™ is a so-called conceptual model. It represents individual

'concepts' and the relationships between them. The Project Success Model ™ contains
five concepts:

1) The desired business outcome, i.e., business success

2) The problem
3) The definition of “done”, i.e. solution scope
4) Project delivery success
5) Product/service success

These concepts and the relationships between them can be understood as a

reinforcing cascade, with the choices at the top of the cascade setting the context for
the choices below, and choices at the bottom influencing and refining the choices
above.

The diagram below offers a visual path of these steps and how they interrelate.

11
 The Project Success Model ™

Although it is often easiest to start by defining the desired business outcome, there are
no restrictions on where to begin. What’s most important is that you go through
multiple iterations to refine your definition of project success until it’s stable, clear,
and feasible on all three levels.

Now let’s take a closer look at each step.

4.1 Defining the Desired Business Outcome

“Of all the things I’ve done, the most vital is coordinating the talents of those
who work for us and pointing them toward a certain goal.” ― Walt Disney

Business success results from defining how a new product or service will create value
for the organization and is measured in both financial and strategic terms.

Examples of business outcomes

> Economic contribution (increased revenue, protected revenue, reduced costs,

avoided costs)

> Competitive advantage (market share won, technology advantage)

> Compliance (FATCA, GDPR, etc.)

> New markets (e.g., reaching a new geographical area or rolling out a new product)

At this step in the model, we only worry about defining the desired business outcomes.
How and when we will measure it is determined in a separate step. The moment you
define the desired business outcomes, you create a new problem to solve.

4.2 Defining the Problem

“We fail more often because we solve the wrong problem than because
we get the wrong solution to the right problem.” ― Russell L. Ackoff

Before you can solve a problem, you need to know exactly what the problem is, and
you should put a good amount of thinking and resources into understanding it. And

12
 The Project Success Model ™

because today’s problems are so complex, you know they can’t be solved by being
broken down into specific components.

Russell Ackoff—an American organizational theorist, professor, and researcher in the

field of systems thinking and management science—offered one of the most
compelling metaphors for complex problems I have encountered to date. He referred
to them as “messes.” How many times have you heard or have uttered the phrase
“This project is a mess”? For me, the number is too high to count. Forty years ago, with
respect to management science, Ackoff defined a “mess” as follows:

“Managers are not confronted with problems that are independent of each other, but
with dynamic situations that consist of complex systems of changing problems that
interact with each other. I call such situations messes. Problems are abstractions
extracted from messes by analysis; they are to messes as atoms are to tables and
chairs.”

According to Ackoff, dialogue is the only way to achieve a shared understanding of a

problem. Unfortunately, in this day and age, where hours are equated with cash and
simplicity reigns supreme, time spent on understanding problems is often viewed as
time wasted.

“Given one hour to save the world, I would spend fifty-five minutes defining the
problem and five minutes finding the solution.” ― Albert Einstein

Management demands action, not talk and collaborative analysis. The kind of meetings
that involve debate and discussion are especially seen as “just talk.” This is
understandable, considering the number of meaningless meetings most people
experience. But I believe debate and discussion are necessary to create a shared
understanding of a problem. I wouldn’t use the same time split as Einstein (in the
quote above), but only because the problems I work on don’t involve saving the world.

“It's so much easier to suggest solutions when you don't know

too much about the problem.” ― Malcolm Forbes

This brings us to a critical juncture. What happens if you don’t understand the
problem? The “solutions” generated will create new problems, but with no guarantee
they’ll even touch on the issue they’re meant to solve.

Understanding the problem is the first step toward any kind of problem-solving.

13
 The Project Success Model ™

4.3 Defining “Done”

“A project is complete when it starts working for you, rather than you working for it.”
― Scott Allen

Without a clear and concise description of done, the only measures of progress are the
passage of time, consumption of resources, and production of technical features.
These measures of progress fail to describe what business capabilities our project
needs to produce or what mission we’re trying to accomplish.

To start defining done, we first must separate between project scope and solution
scope.

Project scope includes all the work that needs to be done to create a product or deliver
a service. Project Scope is all about the project; it defines the work required to create
and deploy the product or service. It is not relevant for defining project success.

The product, service or solution scope are the capabilities of the product or service
that is to be built. The purpose of the solution scope is to conceptualize the
recommended solution for the defined problem in enough detail to enable
stakeholders to understand which new business capabilities the solution will deliver.

Written correctly, the solution scope will create a shared vision. And creating a shared
vision will help the project stay focused, significantly reduce scope creep, reduce
timelines, and increase stakeholder satisfaction.

In other words, a well-defined solution scope significantly increases the probability of a

project success.

So, to create our definition of “done” we will need to define our solution scope on
capability level. Capabilities drive requirements. Therefore, without first identifying the
needed capabilities, we cannot deliver a successful project and will end up a statistic
like all the other failed projects. Note that not every project must deliver new
capabilities. The desire to improve existing capabilities is a great reason to do a
project.

What exactly are capabilities, then?

A capability is the expression of the capacity, materials, and expertise an organization

needs to execute its business strategy (e.g., to enable e-payments, tailor solutions at

14
 The Project Success Model ™

the point of sale, demonstrate product concepts with customers, or combine elastic
and non-elastic materials side by side).

In short, capabilities encapsulate what a business is doing right now and what needs to
be done to execute its current and future strategy.

Another way to think of capability modeling is to think about capabilities as

organizational-level skills that are embedded in people, processes, technology, and
data. Capabilities serve as something of a catchall to reflect the primary dimension of a
business’s needs.

Each capability is unique

A capability is a crucial element of the organization and as such is clearly different from
other capabilities. A capability might be applied throughout the organization in
different ways to bring about different outcomes.

Capabilities are steady

Well-defined capabilities seldom change. They provide a much more stable view of
organizations than do projects, processes, applications, or even strategies. Capabilities
change only when there’s a significant shift in the underlying business model or
mission, which might occur through a business transformation initiative or in
conjunction with a new merger or acquisition.

Capabilities are abstracted from the organizational model

Capability models are more than a simple restatement of the enterprise’s

organizational model. They are organizationally neutral, meaning changes in the
organizational structure don’t require a change in the capability model. In simple
organizations, the capability model may indeed look similar to the corporate
organizational structure. However, in more complex organizations, capabilities arise
that are both common to, and unique to, the organization.

Common practice is to identify capabilities at different levels that can be mapped to

each other. For example, business capabilities may be identified at the organizational,
departmental, or team levels and then mapped to one another.

15
 The Project Success Model ™

Examples of capabilities

Below you will find a few examples of capabilities. Each capability is a combination of
technology, processes, people, and data. Any project delivering a new capability or
improve an existing one, should address these four elements.

> Billing: pretty much each firm needs to be able to send invoices to their clients.

> Dunning: since not every client will pay on time, we will need to be able to remind
them.

> Receiving Payments: Since we want to receive money from our clients, we need to
be able to do so. How is determined by your business needs. Wire transfer? Credit
card? Debit card? PayPal? Cash?

> Managing client risk: A bank needs to manage client risks by Know Your Customer
(KYC), Anti Money Laundering (AML), and other processes.

> Managing credit risk: A team of analysts in a bank's global credit department
needs to be able to analyze its clients' credit ratings before handing out that loan.

> Sales pipeline management: The sales department of a telecommunications

company needs to be able to manage its sales pipeline.

> Qualifying sales leads: A sales operation team needs to be able to qualify sales
leads before they enter a sales pipeline.

4.4 Defining Project Delivery Success

“Beware the time-driven project with an artificial deadline.” ― Michael S. Dobson

Project delivery success has to do with defining the criteria by which a project can be
delivered as intended. Essentially, this addresses the classic triangle of scope, time,
and budget. Project delivery success is limited to the duration of the project to the
extent that success can be measured as soon as the project is officially completed
(with intermediary measures being taken along the way as part of project control
processes). Considering that we have already defined our (solution) scope (in the
previous section on capabilities), we are left to define time and budget.

16
 The Project Success Model ™

Time

Let’s start with time. What criteria drive this parameter? New regulations? Other big
projects planned for next year? To be clear, time is not about planning. Planning is
carried out later by the project team. This process involves defining a time window
that will enable a successful project to be delivered. But first, we must think about the
costs associated with delays and artificial deadlines.

Costs of delay

A business exists to make money, so it’s logical to prioritize profit-maximizing activities.

Calculating your cost of delay allows you to do exactly that. It’s a way of
communicating the impact of time on the outcomes you hope to achieve.

Let’s use a simple example to illustrate this concept.

If you’re developing a product that will add a value of $100,000 per week to your
company, you’re essentially losing that amount for every week that you’re late. A delay
of six weeks will cost the company $600,000. If you have the benefit of knowing this up
front, it makes sense, for example, to hire an additional programmer for $150,000 to
get the product released on time. After all, you’d still be $450,000 better off.

Artificial deadlines

Artificial deadlines are those imposed by management rather than a customer’s

expectations, legal requirements, or a deadline negotiated fairly between a project’s
stakeholders and the project team. Quite simply, an artificial deadline does not
materially affect the results of a project. Of course, practically any artificial deadline
can be justified. The question is one of its importance relative to other deadlines and
priority items.

Examples of deadlines

Real deadlines

> The customer wants the product by July 31, and it will not buy the product if its
late.

> The new compliance law is active as of January 1 and your company will be fined or
worse if your company does not comply.

17
 The Project Success Model ™

Artificial deadlines

> We need to implement our new Customer Relationship Management (CRM) or ERP
solution by March 31.

> We need to finish our reorganization by the end of this month.

Budget

Your project budget should always be expressed in terms of expected project value.

As stated, previously, project success occurs when outcomes add value to the
business. This notion implies that the value of a project is defined by subtracting all of
the (in)direct costs from all of the (in)direct benefits the project delivers.

Using this logic, when your expected project value is USD 3M and your company wants
a 50% return on investment (ROI) on each invested dollar, your project budget is USD
2M. In other words, project budget = project value / 1.5.

If the estimated value of your project goes down, your project budget goes down. It’s
that simple.

Many people confuse real project budgets with authorized project budgets. The
authorized project budget is the total amount of authorized financial resources
allocated to the particular purpose(s) of the sponsored project for a specific period. It’s
usually based on a mixture of project cost estimates, department budgets, free cash
flow, and other factors.

But as soon as your costs exceed the authorized project budget (which is highly likely in
technology projects), or the estimated benefits are not as large as planned (highly
likely as well) you should ask yourself what the real budget of your project is and
whether you’re willing to spend it or not.

How do you know you’re looking at the right factors when it comes to determining the
real budget?

Whether or not your company can spend this money is a financing and risk question,
not a budget question. You could even secure a loan to do certain projects. This
increases risk and reduces ROI (because of paid interest) but can be a valid option.

18
 The Project Success Model ™

Whether or not this budget is enough to realize the project is a cost estimation and risk
question, not a budget question. You should never confuse your cost estimations with
your budget. Budget is what you can spend, while cost estimation is what you think
you will spend. Ideally, the latter is less than the former.

And whether your organization is willing to spend their money on this project is a
prioritization question, not a budget question.

Always express your project budget in terms of expected value delivered. When you do
that, you’ll have a better idea of the real budget of any project.

4.5 Defining Product/Service Success

"It is change, continuing change, inevitable change, that is the dominant factor in
society today. No sensible decision can be made any longer without taking into
account not only the world as it is, but the world as it will be." ― Isaac Asimov

Product or service success involves defining the criteria by which the delivered product
or service can be deemed successful.

Examples of product/service success

> The system is adopted by all target users

> System uptime is 99.99%

> Customer satisfaction has increased by 25%

> Operational costs have decreased by 15%

Importantly, these criteria must be measured once the product/service is implemented

and over a defined period. This means you need to adopt a long-term view, since
product and service success cannot be measured immediately after the project ends.

19
 The Project Success Model ™

4.6 Model Relationships

"Correlation does not imply causation." ― statistics adage

The problem you need to solve critically determines which solution is needed. In turn,
the solution needed determines what capabilities are required to achieve the desired
outcome. Aligned with this, the efforts required to build these capabilities have a
significant impact on your project delivery success, which will correspondingly have a
big impact on costs. The success of the product or service determines its direct
benefits, just as it impacts its indirect benefits and business value.

From To Relationship

Business Problem to When your desired business outcome

outcome solve changes (e.g., a change in strategy or the
market entry of a competitor) there is a high
probability you will need to solve a different
problem than the one you started with.

Problem to solve Definition of The solution to the problem you want to solve
Done determines the capabilities you have to create
and/or improve upon.

Definition of Project delivery When the solution scope of your project

Done success changes, the costs and time needed to
build/improve upon these capabilities will
also change.

Definition of Product/service When the solution scope of your project

Done success changes, the impact of the resulting project
service/product will change as well.

Project delivery Business If your project costs explode, or if the project

success outcome will be delayed by several months, your
business outcome will change (perhaps even
from net positive to net negative).

20
 The Project Success Model ™

Project delivery Product/service Shortcuts during the project typically lead to

success success higher operational costs, which will have a
negative impact on your Product/Service
success.

Product/service Business When your product benefits are less than

success outcome expected, your business outcome will change
(perhaps even from net positive to net
negative).

21
 The Project Success Model ™

5. Making Project Success Measurable

“You can’t manage what you can’t measure.” ― Peter Drucker

Objectives and key results (OKRs) were first articulated by the Intel Corporation and
are now widely used measures in the largest technology companies.

OKRs were originally meant to set strategy and goals over a specified amount of time
for an organization and teams. At the end of a work period, your OKRs provide a
reference to evaluate how well you did in executing your objectives.

The same concept can be used to define project success. Identifying your project goals
and describing them with OKRs can help your project team and stakeholders see how
they’re contributing to the big picture.

5.1 Objectives and Key Results

There are one or more objectives at the heart of any project, which are also known as
the desired business outcomes. The act of setting an objective involves listing what you
hope to accomplish.

This provides clarity in the planning phase. But objective-setting can also be used later
to assess whether you have reached, or have a clear path to reaching, that objective.
Choosing the right objectives is one of the most important, and at the same time,
hardest things to do in any project.

Assuming your objectives are well thought out, the key results can be introduced into
your OKRs. In more detail, key results are numerically based expressions of success or
progress toward an objective. As per the Peter Drucker quotation above, all key results
must be quantifiable and measurable.

The important element here is measuring success. It’s not good enough to make broad
statements about improvement (which are subjectively evaluated). The bottom line is
that we need to know how well we’re succeeding. Accordingly, qualitative goals (which
are more felt than measured) tend to underrepresent our capabilities because the
solution tends to serve the lowest common denominator.

22
 The Project Success Model ™

For example, if I create a goal to “launch a new training program for the sales team” I
might do that for one sales team member. If I set a key result to “train fifty sales team
members” and only train ten, I’ve still exceeded my original goal (of one) by ten times.

5.2 Don’t Turn OKRs Into a Project Activity List

“If it does not have a number, it is not a key result.” ― Marissa Mayer

Activity-based results measure the completion of tasks and activities, or the delivery of
project milestones and deliverables.

Examples of activity-based results

> Releasing a beta version of a product

> Launching a new feature

> Creating a new training program

> Developing a new lead-generation campaign

> Writing a solution design document

Activity-based results usually start with verbs such as “launch,” “create,” “develop,”
“deliver,” “build,” “make,” “implement,” “define,” “release,” “test,” “prepare,” and
“plan.”

The critical questions to ask yourself are: Do you want to measure efforts or results?
Are your OKRs focused on your objective or on the means to get there? As mentioned
before, when used correctly, OKRs define success criteria for a project and whether or
not it has achieved success. But to do that, OKRs cannot be based on activities. There
are three main reasons for this:

1) We want a results-focused culture, and not one focused on tasks.

2) If you did all your tasks and nothing has improved, that is not a success. Success
is improving something: customers are more satisfied, sales are higher, costs
have been reduced.
3) Your project is just a series of hypotheses. An idea is just a non-validated
hypothesis. In the same way, we don’t know if our project will improve our

23
 The Project Success Model ™

results or add value to the organization. The project is just a hypothesis, so you
cannot attach your OKRs to a non-validated bet.

The reality is that nobody works on projects as a hobby. Behind every project is the
desire to improve one or more metrics. So, instead of tracking the delivery of a project,
we should measure the indicators that motivated it in the first place.

5.3 Using Value-Based Key Results

Value-based key results measure the delivery of value to an organization or its
customers. They measure the outcomes of activities.

Examples of value-based results

> Increasing a net promoter score from X to Y

> Increasing a repurchasing rate from X to Y

> Maintaining customer acquisition costs under Y

> Reducing revenue churning (cancellations) from X% to Y%

> Improving average weekly visits (per active user) from X to Y

> Increasing non-paid (organic) traffic from X to Y

> Improving engagement rates (e.g., users complete full profile) from X to Y

The typical structure of a value-based key result is:

Increasing/reducing the metric M from X to Y, where X is the baseline (where we

begin), and Y is the target (what we want to achieve).

Using the “from X to Y” model is preferable to writing a change in percentages,

because it conveys more information. To see why, compare the two options below:

1) Increase the number of new users by 20%.

2) Increase the number of new users from 4,000 to 4,800.

24
 The Project Success Model ™

Option 1 can be confusing since it’s hard to tell how ambitious the target is. Are we
talking about increasing the number of new users from 500 to 600, or from 4000 to
4800?

When project teams start to work with value-based OKRs, it’s common for them to get
stuck listing activities as key results. To convert those activities into value, think about
the consequences of succeeding at the tasks. What are the desired outcomes?

In other words, if we are successful with the project, we will:

> Key result #1

> Key result #2
> Key result #3

Examples of OKRs

If we are successful with the new campaign, we will…

> Increase our net promoter score from 29% to 31%

> Reduce churn from 3.2% to 2.7%

If we successfully migrate the platform, we will:

> Reduce infrastructure costs from 1.5M to 1.1M

> Maintain availability during migration to 99.99%
> Maintain revenue of 6M

5.4 OKRs vs. KPIs

OKRs should be the driving force behind your project and product direction. They
boldly state where you’re going, and they give you metrics that allow you to know
when you’ve arrived.

OKRs should be fail-by-default. To succeed in an OKR, you shouldn’t be able to sit on

your ass and play defense.

Objectives like “don’t release any new bugs” make terrible OKRs. A guaranteed way to
achieve that objective is to stop releasing software. But while “no new bugs” is an
awful OKR, it’s still an important measure of business health. It’s worth keeping an eye
on.

25
 The Project Success Model ™

There are plenty of metrics like bugs released (a proxy for code quality) that are
important to watch but don’t make good OKRs. Rather than trying to wedge them into
a container where they don’t belong, consider adding a second tool to your toolkit—
key performance indicators (KPIs).

If OKRs give your teams direction, KPIs make sure nothing is going off the rails.
Practically any metric—site uptime, conversion rates, user retention—can be used as a
KPI. KPIs are a metric that’s important to watch, but not something you’re trying to
change right now.

Keeping track of relevant KPIs will help you uncover problems as they emerge. If you
decide a KPI is out of line enough to justify investing in a fix, then it simply becomes
part of an OKR. The passive KPI “Conversion rate—5%” becomes the active objective
“Double conversion rate by September.”

Use KPIs to keep an eye on things. Use OKRs when you want to make a change.

26
 The Project Success Model ™

6. Bringing It All Together

“Good business leaders create a vision, articulate the vision, passionately own the
vision, and relentlessly drive it to completion.” — Jack Welch

Each large business-critical technology project needs a project sponsor, a steering

committee, and a project manager.

One of the first things this group of people needs to do is sit together and define
project success, how they are going to measure it, and when.

To help you with this, you and the rest of the group can go through a number of
iterations of the Project Success Model™.

1) Define the desired business outcome, i.e., business success

2) Define the problem
3) Define the definition of done, i.e., solution scope
4) Define project delivery success
5) Define product/service success

This process will result in several Objectives and sometimes already a few Key Results.

Now the group will review all the Objectives and define Value Based Key Results for
each of them. The last thing the group needs to do is to prioritize the Objectives. If
everything is a priority, nothing is a priority.

As you learn what you should be measuring and what truly matters to your project and
business success, it becomes easier to define measurable results.

And as it becomes easier to define measurable results, it also becomes easier to

achieve them.

If you and your executive team need help to define success for your business-critical
project, check out my Project Success Definition Workshop in the next chapter or on
my website.

27
 The Project Success Model ™

7. The Project Success Definition Workshop

In this half day workshop, I will use the Project Success Model™ to guide you and your
executive team through the process of defining success for your business-critical
technology project.

Every project has multiple success criteria related to business results, product/service
results, and project delivery results (cost, schedule, scope, and quality).

Project success is determined by how many of your success criteria are satisfied, and
how well.

So, to define the success and failure of your project you should:

1) Define all the criteria relevant to your project.

2) Define how you will measure them.
3) Define when you will measure them.

That is where this workshop will help you.

Typical Clients

Clients that have bought this workshop are:

> C-level Executives or Board Members who want to make sure their business-critical
project is off to a good start.
> C-level Executives or Business Unit Leaders in the role of Project Sponsor.
> C-level Executives or Business Unit Leaders in the role of Steering Committee
Member.

Typical Projects

Projects that can greatly benefit from this workshop include:

> ERP, i.e., an introduction or upgrade of SAP/Oracle/etc.

> HC, i.e., introduction of Workday/SAP HCM
> CRM, i.e., introduction of Salesforce/MS Dynamics
> Modern Workplace, i.e., introduction of M365/G Suite
> Replacement of core banking / insurance system
> Custom software development, i.e., a new product or service

28
 The Project Success Model ™

The investment volumes of these projects typically exceed USD 5M.

Participation

Participants in this workshop should include:

> Your Project Sponsor

> Your Steering Committee members
> Your Project Manager
> Your relevant Key Stakeholders (optional)

Input

Each participant in the workshop should:

> Read my The Project Success Model™ eBook before the workshop.
> Prepare for the workshop by defining their own project success criteria on the three
levels explained in the eBook.
> Actively participate during the ½-day workshop.

I will bring my extensive experience and knowledge around technology projects.

Output

The outputs we will generate create during the workshop include:

> Clear and measurable criteria for project delivery success

> Clear and measurable criteria for product / service success
> Clear and measurable criteria for business success
> Clear problem statement
> Clear and measurable definition of done on capability level

Client Outcome

I have done many of these workshops as part of my client engagements and with
startups I have invested in.

Clients have seen the following results:

> A clear vision and success criteria for their key project
> A common understanding of the goals and scope of their project

29
 The Project Success Model ™

> Some realized that they should invest more money and time in a project
> Some realized that they should not do a planned project
> Some realized that they should stop an existing project
> Some realized that they should re-scope an existing project
> Some realized that they tried to solve the wrong problem

All of them gained a very valuable tool (and an understanding of how to use it) for
other projects.

Delivery

I will come to your office. Ideally, you and the rest of the team will be there as well.

We will need a block of 4 hours for the workshop. For example, 8:00 - 12:00 or 13:00 -
17:00.

If you want to save on the travel costs, I can deliver this workshop online, but you’ll
miss out on the team-building effect this workshop can have, especially if you combine
it with lunch or dinner with all participants.

Scheduling

A Project Success Definition workshop can usually be initiated within 2-3 weeks,
depending on the time of year.

Price

CHF/USD/EUR 5000, excluding VAT and business-class travel costs.

Note: some clients combine this workshop with the Project Complexity Reduction
Workshop to make it a full-day experience. You’ll get a 20% discount on both
workshops if you do so.

You can book this workshop by contacting me by email (henrico.dolfing@data-

solutions.ch) or telephone (+41 79 326 4763).

30
 The Project Success Model ™

8. About the Author

Hi! My name is Henrico Dolfing, and I help C-level
executives in the financial service industry with interim
management and recovery of troubled technology
projects. I have done project reviews, recoveries, and
advisory work for over a decade. I toiled in the trenches
of software development for more than 15 years.

Projects fail for a variety of reasons. Technology projects

in particular have a low success rate. Typically, more than
half of them are considered a failure. If your current project is off-track, chances are I
can bring the necessary knowledge and experience to get the job done.

Troubled projects are never pretty. Often there isn’t time for guessing, just acting. I
have helped companies pull projects back from the brink of failure. By combining my
deep technical knowledge with a proven process, I quickly address major problems and
bottlenecks to put derailed projects back on track.

I provide the leadership necessary to solve complicated problems. I am not afraid to

deliver bad news; I am not afraid of staking my reputation on the decisions I make; and
most of all, I am responsive and sensitive to the intricacies of troubled projects.

I have a strong technical background as a software developer and solution architect,

including an M.Sc. degree in Computer Science and a B.Ec. in Economics.

My diverse international experience allows me to successfully collaborate with people

from all over the globe. Born in the Netherlands, I have lived in Germany, the USA, and
Switzerland. I have worked on both long- and short-term projects in Europe, the
Channel Islands, the Caribbean, and North America.

I spend my spare time in the Swiss mountains enjoying alpine marathons, climbing,
downhill mountain biking, river rafting, and leisurely hikes with my wife and son.

Connect with me on LinkedIn or via email:

LinkedIn: http://ch.linkedin.com/in/henricodolfing

Email: [email protected]

31