The Project Success Model ™

The Project Success Model

A Guide to Defining Project Success

by

Henrico Dolfing

www.henricodolfing.com

Version 1.7
Copyright © 2019 Henrico Dolfing. All rights reserved.

2
 The Project Success Model ™

Content
1. Introduction 4

2. The Three Levels of Project Success 5

3. The Project Success Model 7

3.1 Defining the desired business outcome 8
3.2 Defining the problem 9
3.3 Defining done 10
3.4 Defining project delivery success 12
3.5 Defining product/service success 15
3.6 Model relationships 15

4. Making project success measurable 17

4.1 Objectives and key results 17
4.2 Don’t turn OKRs into a project task list 18
4.3 Using value-based key results 19
4.4 OKRs vs. KPIs 20

5. Closing Thoughts 22

6. About the author 24

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

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 (cost, schedule, scope, and quality).

Some criteria are absolute, meaning they must be completed on or before the original
planned date, and 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 depends on who you ask. The very happy project
manager that implemented the SAP project as scoped on time and below budget (I
know, this will NEVER happen), the end users who absolutely hate the complexity and
slowness of the new system, and the COO that has seen IT costs double whilst none of
the expected savings materialized may all have very different opinions on the success
of the project.

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 as well.

So in order to determine the success or failure of your project, you should define all
the criteria relevant to your project, define how you will measure them, and define
when you will measure them.

4
 The Project Success Model ™

2. The Three Levels of Project Success

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

Simply put, project success occurs when outcomes add value to the business. This
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.

More specifically, there are three core components that work together to facilitate
project success:

1)​ ​Project delivery success​: Will the project delivery be successful? Essentially, this
assesses the classic triangle of scope, time, and budget. These are your ​costs​.

2)​ ​Product or service success​: This refers to when the product or service is deemed
successful (e.g., the system is used by all users in scope, up-time is 99.99 percent,
customer satisfaction has increased by 25 percent, and operational costs have
decreased by 15 percent). These are your ​benefits​.

3)​ ​Business success​: This has to do with whether the product or service brings value to
the overall organization, and how it contributes financially and/or strategically to the
business’s success. This is your ​value​.

Overall, a successful project depends on the combination of these criteria. Some argue
that product/service success is the same as business success, or argue that
product/service success automatically means business success. This is not true.

Examples of product/service success not resulting in business success

>​ Imagine a new investment product for a bank that has a high margin but also
carries a significant risk for the bank, not just the customer. The product was wildly
successful and many clients bought it. Many more than expected, which made the
risk profile for the bank too high.

>​ Now imagine that this one product is still very successful and is creating revenue
and happy customers but it goes against everything that is defined in the new
strategy of the company, and this is blocking the company from moving in a different
direction.

5
 The Project Success Model ™

>​ Or that this very successful product with many happy clients, instead of helping the
company to get additional clients, is actually cannibalizing their existing clients.

>​ Or that this very successful new service in the direct business of the company is
competing with services offered through partners of the business, and these
partners are so pissed that they jump ship and it results in a huge net loss.

All the above are true stories that illustrate how product success can be completely
different from business success.

For smaller companies with only one product, or a very small product/service portfolio,
you might argue they are similar and very tightly correlated.

But for larger companies with bigger portfolios, I’m of the opinion that product success
and business success are fundamentally different. This is reflected in the three
separate levels I recommend to define project success.

In terms of project 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 arise in clearly
defining and measuring these three levels of success at the beginning of the project,
then periodically reviewing and measuring them.

That is where the ​Project Success Model ™ c​ omes into the picture.

6
 The Project Success Model ™

3. 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. Where a mental model
captures ideas in a problem domain, a conceptual model represents 'concepts' and
relationships between them.

A conceptual model in the field of computer science is also known as a domain model.
Conceptual modeling should not be confused with other modeling disciplines such as
data modelling, logical modelling and physical modelling.

The aim of a conceptual model is to express the meaning of terms and concepts used
by domain experts to discuss the problem, and to find the correct relationships
between different concepts.

The conceptual model attempts to clarify the meaning of various, usually ambiguous
terms, and ensure that problems with different interpretations of the terms and
concepts will not occur.

A conceptual model provides a key artifact of business understanding and clarity. The
concepts of the conceptual model can be mapped into actual implementations that
will be different for each organization and project.

The ​Project Success Model ™​ contains five steps, each one feeding into those that
follow.

1) Define the desired business outcome

2) Define the problem
3) Define the scope (project completion)
4) Define project delivery success
5) Define product/service success

The moment the definition of one of these steps changes, it is highly likely that it will
have a direct impact on the others.

7
 The Project Success Model ™

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

Although it is often easiest to start by defining the desired business outcome, there are
no restrictions as to where to begin. What is most important is that you go through
multiple iterations—to refine your definition of project success until it is stable, clear,
and feasible on all three levels. Following this overview, let’s take a deeper look at
each step.

3.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, measured in both financial and strategic terms.

Examples of business outcomes

>​ Financial value contribution (e.g., increased turnover, increased profits, or

decreased costs)

8
 The Project Success Model ™

>​ Competitive advantage (e.g., winning a share of the market or a technological

advantage)

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

3.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

When you have defined a desired business outcome, you have created a new problem
to solve. But 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 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” yourself? For me, the number is too high to count. With respect to
management science, Ackoff defined a “mess” forty years ago 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 the 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

9
 The Project Success Model ™

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. While I would not use the same time split as Einstein (in
the quote above), that is only because the problems I work on do not 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” that are generated will create new problems and without
any guarantee that they will even touch upon the existing issue they are meant to
solve. Alternatively, the better you understand the nuances of a problem, the more
likely you are to understand its root cause and, from this, to create countermeasures
to prevent the problem from recurring. Understanding the problem is the first step
toward any kind of problem-solving. The next step is to define how success will be
measured. After all, it is imperative to know—at the outset—whether your solution
will actually solve the problem.

3.3 Defining done

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

Project failure starts when we can’t tell what “done” looks like in any meaningful way.
Without some agreement on our vision of “done,” we’ll never recognize it when it
arrives, except when we’ve run out of time or money or both. We’ve all seen the
project failure numbers before. We’ve all been told how bad things are. We’ve all
heard that large numbers of projects fail because of poor planning or poor project
management. Whether this is true or not, how can we increase the probability of our
own project’s success?

First, we must recognize that 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 are trying to
accomplish. Capabilities drive requirements. Therefore, without first identifying the

10
 The Project Success Model ™

needed capabilities, we cannot deliver a successful project, and we will end up a

statistic like all the other failed projects.

What exactly are capabilities, then?

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

needs to be able to execute its business strategy (e.g., enable e-payments, tailor
solutions at 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​ in order to meet 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, and/or technology.
Capabilities serve as something of a catchall to reflect the primary dimension of the
needs of a business.

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 and can
be applied in different ways to bring about different outcomes.

Capabilities are steady

Well-defined capabilities seldom change. The capabilities provide a much more stable
view of organizations than do projects, processes, applications, or even strategies.
Capabilities only change when there is 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.

11
 The Project Success Model ™

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.

Examples of capabilities

>​ Managing risks: A bank manages risks by KYC, AML, and other processes.

>​ Managing credit risk: A bank's global credit department manages its credit risks.

>​ Analyzing client credit ratings: A team of analysts in a bank's global credit
department analyzes its clients' credit ratings.

>​ Sales pipeline management: The sales department of a telecommunications

company manages its sales pipeline.

>​ Qualifying sales leads: A sales operation team qualifies sales leads before they
enter a sales pipeline.

With capabilities as our starting point, we’re now going to look at project delivery
success as they apply to any project.

3.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
deliver 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 we have already defined scope (in the previous section on capabilities), we
are left to define time and budget.

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

12
 The Project Success Model ™

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 delays

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 that 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 $10,000 per week to your company, you are essentially losing that
amount for every week that you’re late. A delay of six weeks will cost the company
$60,000. If you have the benefit of knowing this up front, it would make sense, for
example, to hire an additional programmer for $15,000 to get the product released on
time. After all, you would still be $45,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 end product. 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.

>​ The new compliance law is active as of January 1.

Artificial deadlines

> ​We need to implement the CRM tool by March 31.

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

13
 The Project Success Model ™

Budget

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

As stated before, project success occurs when outcomes add value to the business.
This 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 return on investment (ROI) on each invested dollar of 50%, 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 is
that simple.

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

But as soon as your costs go over the authorized project budget (which is highly likely
for technology projects), or the estimated benefits are not as big as planned (highly
likely as well) you should ask yourself what the real budget of your project is and if you
are willing to spend it or not.

How do you know whether 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.

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 or not your organization is willing to spend their money on this project is
a prioritization question, not a budget question.

14
 The Project Success Model ™

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

3.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 product or service
that is delivered is 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 of time. This means that you need to adopt a long-term view
since product and service success cannot be measured immediately after the project
ends.

3.6 Model relationships

"Correlation does not imply causation." ― statistics adage

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

15
 The Project Success Model ™

From To Description

Business Problem When your desired business outcome

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

Problem Completion The solution to the problem that you want to

solve determines the capabilities you have to
cultivate and/or improve upon.

Completion Project delivery When the scope of your project changes

success (definition of scope) the costs and necessary
time to build/improve upon these capabilities
will also change.

Completion Product/service When the scope of your project changes

success (definition of completion), the direct 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 a number of months, your
business outcome will change (perhaps even
from net positive to net negative).

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).

16
 The Project Success Model ™

4. 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 among the biggest technology companies in the world today,
including Google and Zynga.

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
strategy and goals, and laying it out in a digestible way with OKRs can help your project
team and stakeholders to see how they are contributing to the big picture, and
whether and how they can align with other teams.

4.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. Not only does this provide clarity in the planning phase, it can be
used at a later time to assess whether you have reached, or have a clear path to
reaching, that objective. Choosing the right objectives is one of the hardest things to
do for any project and, quite frankly, it requires a great deal of thinking and courage to
do it well.

Assuming that 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. 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 are 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.

17
 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 ten times over.

4.2 Don’t turn OKRs into a project task 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

18
 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 upon 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.

4.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 (cancellation) 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 preferred 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​.

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​?

19
 The Project Success Model ™

When project teams start to work with value-based OKRs, it is common for them to get
stuck listing activities as key results. To convert those activities into value, think about
the consequences of succeeding in this task. 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

4.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 to judge 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 despite “no new bugs” making
an awful OKR, it’s still an important measure of business health. It’s worth keeping an
eye on.

There are plenty of metrics like bugs released (a proxy for code quality) which are
important to watch but don’t fit well in 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).

20
 The Project Success Model ™

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.

21
 The Project Success Model ™

5. Closing Thoughts

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

The ​Project Success Model ™​ contains five steps, each one feeding into those that
follow.

1) Define the desired business outcome

2) Define the problem
3) Define the scope (project completion)
4) Define project delivery success
5) Define product/service success

The moment the definition of one of these steps changes, it is highly likely that it will
have a direct impact on the others.

As you learn what you should be measuring and what truly matters for 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.

Project Success Model ™ Workshops

Would you like me to help you and your team understand and define project success?
Contact me ​here​ to book an onsite workshop.

Newsletter

You can subscribe to my monthly newsletter ​here​. You will receive articles I have
written, how-to guides, and case studies around project management, program
management, and portfolio management.

22
 The Project Success Model ™

Blog

With my blog “​Doing the right projects and doing projects right​” I want to provide you
with relevant, helpful content in all areas of project, program, and portfolio
management that you can use to further your organizational and professional growth.

If you’re new to my site you'd best ​start here​.

How-to guides

I have written a vast number of articles in the format of how-to guides. They outline a
step-by-step process which you can follow to solve a problem or task related to
project, program, and portfolio management. You will find an overview of these guides
here​.

Project failure case studies

I research technology project failures and then write case studies about them because
it is a great way of learning from others' mistakes. This page ​here​ is an ever-growing
collection of case studies I have written.

23
 The Project Success Model ™

6. About the author

Hi, my name is Henrico Dolfing, and I help C-level
executives with troubled projects.

I have done project reviews, recoveries and advisory for

over a decade, and have worked 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 to save projects from the brink of failure. By combining my
deep technical knowledge with a proven process, I quickly address major problems and
bottlenecks, putting the project 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 putting my reputation behind 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 longer and shorter projects all through 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 toddler
son.

Connect with me on LinkedIn or via email:

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

Email​: ​[email protected]

24