See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/348849361

Endless Modernization: How Infinite Flow Keeps Software Fresh

Article · January 2021

CITATION READS
1 1,137

2 authors:

Jim Johnson Hans Mulder

29 PUBLICATIONS 136 CITATIONS

Antwerp Management School
110 PUBLICATIONS 576 CITATIONS
SEE PROFILE
SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Collaborative Decision Making in Enterprise Architecture Development View project

Enterprise Engineering View project

All content following this page was uploaded by Hans Mulder on 28 January 2021.

The user has requested enhancement of the downloaded file.

 ENDLESS MODERNIZATION:
How Infinite Flow Keeps Software Fresh

Jim Johnson
Dreamer
The Standish Group

Hans Mulder
European Research Director
The Standish Group

Copyright © 2020 by The Standish Group International, Inc. A

 INTRODUCTION
Keeping the Golden Gate Bridge modern is a permanent full-time job for a team of 30 painters and mechanics.
Every working day, this team helps the bridge maintain its flexibility in the face of assaults from the strong winds
off San Francisco Bay. The team also continually paints the bridge to preserve its majestic blood-orange glow.
Keeping mission-critical software applications fresh and glowing requires the same dedication.

EXECUTIVE SUMMARY
This paper is the result of unique and extensive research for identifying the best methods for modernizing
mission-critical application software. We have concluded that projects using the principles of what we call
“Infinite Flow” (a continuous process, unlike projects that are designed as one-time events with a beginning
and an end) achieve superior results. (For more information, see addendum, “About Infinite Flow.”) As a result
of these compelling findings, we are providing a method for transition from a project-based environment to
non-project activities by adopting the principles of Infinite Flow to modernize legacy applications.

Since Infinite Flow is not a project, we cannot measure it. Therefore, we have reduced the observations from
all modernization projects to those that generally meet the attributes of microprojects and some attributes of
Infinite Flow (Flow), such as Scrum and DevOps. We call this “flow like modernization” in order to compare
it more clearly with the other types of application modernization that we have observed. In essence, we have
found that great progress can be made by ending project-based modernization in favor of the flow process.

Our findings show:

a. Flow like modernization projects that are a series of microservices or microprojects, rather than one large
project, achieve much better outcomes.

b. Flow like microprojects reap greater customer satisfaction because of the built-in user/customer feedback loop.

c. Flow like modernization microprojects achieve a higher return of value.

d. Flow like microprojects offer a reduced risk of failure and monetary loss.

e. Flow like microprojects have a higher degree of sustainable innovation.

f. Flow achieves a longer lifespan of applications, avoiding premature retirements.

CHAOS RESEARCH AND DATA

For the last 25 years, The Standish Group has collected, adjudicated, and approved between 2,500 and 5,000
new project cases per year. In each of those 25 years, we have added and changed observations to gain a better
understanding of why some projects are successful while others fail. We also research many other issues having
a bearing on project success; these have led to books and workshops on how to be a good sponsor, a good
team, and a good workplace. Most importantly, we have pinpointed the issue of decision latency as crucial to
project success.

Our organization profiles, which inform the Standish database, study organizations from the viewpoint of
24 separate data points. Our project profiles depend on more than 80 data points through which projects are
analyzed and assessed, and on a dozen worksheets developed for each project. The database is used to create
reports like this one. It’s also used for projects like “CHAOS 2020: Beyond Infinity,” as well as general queries,
single-project assessments, future portfolio predictions, and performance benchmarks. Our database is robust,
so we can see many different views of data and measure attributes such as OnTime, OnBudget, OnTarget,
Copyright © 2020 by The Standish Group International, Inc. 1
 OnGoal, Value, and Customer Satisfaction. We can also use any
of these measurements for decision speed, team capability, size of This paper builds on our research,
projects, types of projects, methods of delivery, and a number of other with an introduction to Infinite
common applications. Flow and the discovery of decision
latency as the root cause of
In Chart 1 we see success by the traditional metric of OnTime, poor project performance. That
OnBudget, and OnTarget over the last 25 years. After 25 years of research includes our 2010
research, the only sure way to prevent software projects from being either paper, “Modernization: Clearing a
challenged or failed is to stop doing projects and adopt Infinite Flow. Pathway to Success,” [1] which
identified three common ways
organizations go about replacing
CHART 1: LONGITUDINAL CHAOS RESEARCH a current software application
and compared the results of each
method. Type 1 was essentially
a new application development.
It involved developing new
user requirements, technical
specifications, programming,
tests, and user education, as
well as a host of other project
management and executive
activities. Type 2 used a typical
1994 1995–1999 2000–2004 2005–2009 2010–2014 2015–2020
commercial off-the-shelf (COTS)
package or implementation that
required moderate modifications.
Successful Challenged Failed Type 3 used a method we called
“modernization”: refurbishing an
existing application rather than
CHART 2: MODERN RESOLUTION BY PROJECT TYPE replacing it fully.

For the current paper, we

PROJECT TYPE SUCCESSFUL CHALLENGED FAILED have added a further category
of application replacement,
Developed from
26% 54% 20% using a collection of software
scratch
components. We have also
Developed using replaced “modernization”
37% 46% 17% with our discovery of “flow-like
components
modernization.”
Purchased
44% 36% 20% In 2014, we published a second
application (COTS)
research paper, “Modernization
Flow Like in Place,” [2] which presented
71% 28% 1% a technique with which to
Modernization
modernize an application or a
The “modern” definition of success (OnBudget, OnTime, Customer Satisfied) system while it is fully functional
also shows that Flow modernization projects do much better than other and being used by an organization
project types. This chart is based on the 50,000 projects in the and its customers. Infinite Flow
CHAOS 2020 database. again advances this concept by
making changes a daily event.

Copyright © 2020 by The Standish Group International, Inc. 2

 DECISION LATENCY THEORY
Decision Latency theory states: “The value of
the interval is greater than the quality of the
decision.”[4] The Standish Group has determined
that the root cause of software project failures
and challenges is slow decision latency, and that
to improve project performance, organizations
need to find ways to make decisions faster. The
problem is, “good project management” actually
tends toward slower decisions out of fear of
making a bad one. This seemingly wise practice
causes fragility [FN2] in the pursuit of a better
outcome. True, short decision intervals are likely
to result in some minor errors—but being able to
“tinker” with the project makes the whole process
antifragile. Short decision latency also promotes
agility and thus decreased future technical debt.
Overall, learning to make decisions quickly results
in faster time to market and additional savings.

For each of the three application-replacement

techniques—development of a completely new
application, implementation of a commercial
off-the-shelf (COTS) package, or the use of a
number of software components—The Standish Group has arrived at a formula for number of decisions to
be made per thousand dollars invested. We developed an overall average of one decision per thousand dollars.
Tellingly, however, Flow modernization projects came in at about half the decisions of the average—in other
words, one decision per $2,000. Why? Consider that many of the decisions to be made during a project
center around features and functions. However, modernization projects already have a feature and function
role model, and this, of course, reduces the number of decisions to be made. These role models also improve
the “dwell time” needed for many of those decisions. In addition, Flow modernization teams are usually self-
directed and can make decisions on their own, further reducing the interval.

CHART 3 RESOLUTION BY DECISION LATENCY SKILLS

SKILL LEVEL SUCCESSFUL CHALLENGED FAILED

Highly Skilled 63% 30% 7%

Skilled 28% 61% 11%

Moderately Skilled 20% 51% 29%

Poorly Skilled 18% 47% 35%

Teams that have better decision latency skills are also more successful.
This chart uses the modern definition of success (OnBudget, OnTime,
satisfied customer) and is based on the 50,000 projects in the
CHAOS 2020 database.

Copyright © 2020 by The Standish Group International, Inc. 3

In general, our findings found decision latency costs to account for about 25% of the overall cost of a software
development project. For example, a million-dollar modernization project will require about 500 decisions,
and the average interval or dwell time is less than one hour, making the estimated cost around $50,000. In
contrast, a typical million-dollar new application development project will require about 1,100 decisions at a
dwell time of two hours. The cost of those decisions will come in at $220,000—more than four times the cost
of a Flow Like modernization project.

We believe improved decision latency is the main reason Flow like modernization projects enjoy a greater
success rate and cost less than other types of projects. The Standish Group measures the skill level by
information in the project profile.

CHART 4: DECISION LATENCY BY PROJECT TYPE

PROJECT TYPE HIGHLY SKILLED SKILLED MODERATELY SKILLED POORLY SKILLED

Developed from
17% 38% 27% 18%
scratch

Developed using
21% 39% 23% 17%
components

Purchased application
22% 36% 26% 16%
(COTS)

Flow Like
27% 43% 18% 12%
Modernization

Flow Like modernization project teams generally display better decision latency skills than teams on other types of projects.
This chart is based on the 50,000 projects in the CHAOS 2020 database.

Decision latency costs to account

for about 25% of the overall cost of
a software development project for
non-like modernization project.

4
 CUSTOMER SATISFACTION
The real test of a successful software project is customer satisfaction—it’s one of the major reasons we create
and modernize software. There’s a direct relationship between customer satisfaction and that customer’s
ability to absorb change. Large, “big bang” projects produce only a 6% rate of high satisfaction, and they
produce a 60% rate of customer disappointment. Small, iterative modernization projects reap four times that
rate of high satisfaction and produce only an 8% rate of customer disappointment. Retaining similarity in a
transition to new features and functions avoids the necessity for retraining. Being able to make changes to the
user experience that are intuitive increases user productivity. This is further spelled out in our
Absorption Theory [FN3].

CHART 5: CUSTOMER SATISFACTION BY PROJECT TYPE

VERY SOMEWHAT NOT

PROJECT TYPE SATISFIED DISAPPOINTED
SATISFIED SATISFIED SATISFIED

Developed from
12% 18% 25% 22% 23%
scratch

Developed using
14% 21% 25% 19% 21%
components

Purchased application
13% 21% 26% 21% 19%
(COTS)

Flow Like
21% 34% 30% 9% 6%
Modernization

Flow Like modernization projects attain a higher level of customer satisfaction than other project types. This chart is based
on the 50,000 projects in the CHAOS 2020 database.

Large, “big bang” projects produce only a 6% rate of high satisfaction,

and they produce a 60% rate of customer disappointment.

Copyright © 2020 by The Standish Group International, Inc. 5

 VALUE OF FLOW MODERNIZATION
If you buy a car today but cannot drive it for two years, you obviously get no value for that period of time. In
addition, the car will depreciate in value by about 24% before you do drive it. It’s the same for the delivery of
new or improved software features and functions. However, Flow modernization allows you to build a new
software function today—and enjoy the return on value tomorrow. Value is the other measurement of Flow.

Our research shows that as much as 80% of new software features and functions are dead on arrival and rarely
used. However, Flow modernization eliminates many of those features and functions before they are even
created. Flow modernization also eliminates many unused features and functions through refactoring—which
improves software maintenance costs, thus creating additional value. The proof is in the numbers: Flow like
modernization returns twice the value on average than for other types of software development.

CHART 6: VALUE BY PROJECT TYPE

PROJECT TYPE VERY HIGH HIGH VALUE AVERAGE LOW VERY LOW
VALUE VALUE VALUE VALUE

Developed from 8% 19% 32% 15% 26%

scratch

Developed using 11% 22% 32% 13% 22%

components

Purchased application 10% 21% 31% 12% 26%

(COTS)

Flow Like 22% 32% 30% 9% 7%

Modernization

Flow Like modernization projects offer a much higher return on investment/value than for other project types. This chart is
based on the 50,000 projects in the CHAOS 2020 database.

Flow Like modernization returns twice the value on

average than for other types of software development.

Copyright © 2020 by The Standish Group International, Inc. 6

 PROJECT ENVIRONMENT
The Standish Group has reduced the “Factors
of Success” to these three practices: the good
place, the good team, and the good sponsor.
The place is the project environment. The
environment is the people, places, and things,
such as tools, through which the project is
executed—basically, everything but the team
and the sponsor. An environment that values
skill in its employees and is attentive to its other
attributes improves the chances of a successful
project; a poorly skilled environment presents
challenges. The Standish Group has identified
10 principles and 50 skills that go into making
a “good place.” The Good Place skills are listed
in the current CHAOS2020: Beyond Infinity
Report [10]. The Standish Group also has an
online appraisal to measure the skills of The
Good Place. Setting up the right culture to
support Flow is essential, that is why we have
created a set of principles, practices, and skills
as a recommendation for a Flow
Modernization environment.

CHART 7: PROJECT ENVIRONMENTAL SKILLS BY PROJECT TYPE

PROJECT TYPE HIGHLY SKILLED SKILLED MODERATELY SKILLED POORLY SKILLED

Developed from
7% 49% 39% 5%
scratch

Developed using
8% 50% 37% 5%
components

Purchased application
8% 49% 39% 4%
(COTS)

Flow Like
12% 56% 29% 3%
Modernization

Flow Like modernization projects tend to have project environments that are slightly more skilled places than do other
project types. This chart is based on the 50,000 projects in the CHAOS 2020 database.

Copyright © 2020 by The Standish Group International, Inc. 7

SKILLED STAFF
Our continuous research on project success shows successful projects need smart, trained people. Not surprisingly,
one of the key project success factors that Standish has identified since the beginning of its CHAOS research is a
competent staff [5]. However, as with any team, Flow modernization teams improve with time, experience, feedback,
and collaboration. Fortunately, the Flow modernization process promotes rapid feedback, experimentation, small
failures, and rapid customer engagements with actual use. Also fortunately, Flow modernization teams tend to be
smaller, at around four to six team members, and this improves agility and communication. Our book The Good
Mate offers advice, insights, and practical approaches to improve teamwork and teams [6]. The nice thing about Flow
is that you can work on a task while improving skills for future tasks without losing valuable production time. In
addition, special tasks can be easily augmented by temporary gig members.

CHART 8: TEAM SKILLS BY PROJECT TYPE

PROJECT TYPE GIFTED TALENTED COMPETENT ABLE UNSKILLED

Developed from 10% 31% 40% 13% 5%

scratch

Developed using 12% 30% 39% 14% 6%

components

Purchased application 11% 32% 42% 12% 4%

(COTS)

Flow Like 14% 26% 45% 12% 3%

Modernization

Flow Like modernization projects tend to have slightly more skilled teams than do other project types. This chart is based
on the 50,000 projects in the CHAOS 2020 database.

8
 PROJECT SPONSOR
Key to success for any project is a skilled sponsor, and our book The Good Sponsor [7] identifies 10 principles
and 50 skills that characterize good sponsors. We believe that unlike teams, which improve with time,
sponsors tend to lose interest over time, and hence their skills degrade. Flow modernization projects come
in at about average in terms of project sponsor skills. However, maintaining rapid and constant Flow
modernization deliveries helps maintain sponsor interest, and changing sponsors as a project’s focus changes
also helps. Of course, the most effective thing you can do to improve sponsor skills is to encourage them to
take a course, like our Good Sponsor Crash Course.

CHART 9: PROJECT SPONSOR SKILLS BY PROJECT TYPE

PROJECT TYPE HIGHLY SKILLED SKILLED MODERATELY SKILLED POORLY SKILLED

Developed from
16% 39% 28% 17%
scratch

Developed using
21% 38% 25% 16%
components

Purchased application
22% 35% 27% 16%
(COTS)

Flow Like
25% 43% 20% 12%
Modernization

Skill levels for sponsors of Flow Like modernization projects come in slightly higher than for other project types. This chart
is based on the 50,000 projects in the CHAOS 2020 database.

Flow Like modernization projects that

have a highly skilled project sponsor have
an 81% success rate.

Copyright © 2020 by The Standish Group International, Inc. 9

 SUCCESS LADDER BENCHMARK
The Success Ladder benchmark offers a quick and easy way to get a rough order of magnitude for a single
project’s chances of success. The benchmark is part of the premium member service. By completing 7 project
profile questions the system will return an estimate of success The benchmark returns a result based on
answers to questions ranked against answers given for the 50,000 project profiles in the CHAOS database.
By changing the answers, you can see the effect of the change. For example, you answer that the skills of the
project sponsor are poor. You then look at how the chances of success change by selecting highly skilled. Then
you can decide if you want to either change the sponsor to a highly skilled sponsor or provide education to
improve the project sponsor.

Currently, the Success Ladder has six rungs. Rung 1 is the actuary or project type (i.e., developed from scratch
or through modernization) and the project method (i.e., agile or waterfall). Rung 2 considers project size; the
results change based on our labor cost range. Rung 3 measures complexity. Rung 4 measures the environment
in which the project takes place. Rung 5 considers the emotional maturity of the team, and Rung 6 measures
the skills of the sponsor. Creating a Success Ladder benchmark is a simple task and only takes a few minutes.

CHART 10: SUCCESS LADDER BENCHMARK FOR FLOW LIKE MODERNIZATION

SKILLS LEVEL SUCCESSFUL CHALLENGED FAILED

Good Sponsor Highly 87% 12% 1%

Good Team Highly 82% 15% 3%

Good Place Highly 79% 20% 1%

Complexity Very Easy 66% 31% 3%

Size Small 62% 35% 3%

Base Actuary 54% 37% 9%

Charts 10 and 11 present results for the same project, using two methods: Flow modernization, and
the development of an entirely new application. Chart 10 attacks the project using small, iterative, agile
modernization methods and features high levels of skills. The project is broken into 10 individual projects at
about $1 million each.

Chart 11 presents the complete opposite—a large, very complex, waterfall software development project
featuring moderate skill levels and running at $10 million in total.

The results seen in Chart 10 show an extremely positive outcome (OnTime, OnBudget, with a satisfied
customer). In contrast, predictions for the project shown in Chart 11 come in at a mere 1% chance of success.

Copyright © 2020 by The Standish Group International, Inc. 10

 CHART 11: SUCCESS LADDER BENCHMARK FOR NON-FLOW LIKE MODERNIZATION

SKILLS LEVEL SUCCESSFUL CHALLENGED FAILED

Good Sponsor Moderately 1% 56% 43%

Good Team Moderately 1% 56% 43%

Good Place Moderately 2% 51% 46%

Complexity Very Complex 3% 54% 42%

Size Grand 5% 57% 37%

Base Actuary 12% 61% 27%

EX AMPLE
Flow Like modernization is not just a theory or a wild idea. It works for developing successful software projects.
Take, for example, a large European financial organization that used the method to replace a 40-year-old system.
The organization had found that the increasing complexity of the interdependencies between infrastructure
software and application software components was preventing agility and leading to longer lead times. These
are major risks because of the number of people involved, the dependencies between projects, and issues of
lifecycle management and user training and acceptance. The institution had already tried a couple of times to do
a full replacement—once with a new development and once with a package. In both cases, the projects failed,
at a cost of many millions of dollars. Using small projects instead, with some Flow-like techniques, kept many
dependencies in place while gradually eliminating them. The effort has taken several years, but at reduced cost
with no down time. This organization is also saving about 80% on its annual software maintenance by reducing
most of the technical debt.

This large European organization is saving about 80% on its annual

software maintenance by reducing most of the technical debt.

Copyright © 2020 by The Standish Group International, Inc. 11

 WATERFALL PROJECTS THE FUTURE IS FLOW
Net Value The world is getting faster every day. Attention spans are measured in the
20% space of a “tweet.” Executives are impatient and want everything NOW.
Timeframes for projects have gone from years to months, to weeks, and
sometimes days. The next step we foresee is no projects at all—and tasks
will be measured in hours for the majority of software development and
implementation activity. This is a major culture change that fits into
today’s business environment. The demand is for more value, higher
customer satisfaction, and lower costs. It is our opinion—based on our
extensive research and observation of role models—that the move to
Infinite Flow satisfies all three of these demands.
Overhead
80%
Infinite Flow greatly reduces overhead. A typical waterfall-type
modernization project will incur about 80% in overhead and offer a net
value of less than 20%. The average net value of such a project is derived
from the mere 16% of features and function that are frequently used. Most
AGILE PROJECTS of the overhead that results comes from command-and-control efforts such
as gates, steering committees, and meetings that increase decision latency.
Net Value
48% The typical agile-type modernization project will cut that overhead in
half and triple the net value. This increase in value is the direct result
of self-managed teams, which allow faster decisions to be made. The
Infinite Flow method results in an overhead cost of only 20%, and a
net value of 80%.

Infinite Flow greatly increases customer satisfaction. A typical waterfall-type

modernization project will result in a high level of customer satisfaction
in perhaps 20% of customers, at best. Much of this unhappiness is caused
Overhead by the low level of feature function absorption, which reflects customer
52%
frustration with a difficult change management process. However, the use
of agile doubles the satisfaction level in customers. Much of this increase is
the result of faster delivery of features and functions that embrace change
and allow for greater user absorption. Infinite Flow daily delivery and value
INFINITE FLOW increases customer satisfaction to a level of about 80%.

Net Value Infinite Flow also greatly decreases costs. A typical waterfall-type
80% modernization project might cost $12 million in direct labor. For the same
features and functions delivered, an agile approach would cut that cost in
half. The same features and functions using Infinite Flow practices would
cut the costs in half again—in other words, a cost of about $3 million.

The great thing about Infinite Flow is that it involves no estimates or budget
items, no project plans, no steering committees, and no deadlines. There are
no conflicts on what should be included and what should not be included.
There are no project failures or “challenged” projects: There are no projects.
Overhead Budgets are based on teams, and tasks are based on obvious needs.
20%

Copyright © 2020 by The Standish Group International, Inc. 12

 IN SUMMARY
ADDENDUM – ABOUT
Starting a Flow modernization group is not a big
investment or decision. You can begin with a small team
INFINITE FLOW
of four to six members; this is the best size to begin a
test project. Make sure the team has the right technical The Flow process continuously manages
skills for the Flow-like project. Train each team member software modernization, implementation,
in our Good Mate program. Choose a Scrum master or and maintenance . The Flow process is a
a DevOps professional to guide the team. Encourage service-oriented method that incorporates
the sponsor to take our Good Sponsor class and find many of the features and functions of agile/
a certified Scrum product owner to help that sponsor. Scrum and DevOps [3] to reduce the friction
Choose a project team that has executed projects within and delays associated with traditional
four to six months. Choose a small application that is software project development methods.
highly visible and offers both good value and visibility. Flow also reduces technical debt [FN1] by
Every day your permanent team will deliver something, a continuous refactoring in order to keep
and every day your team—as well as the software software fresh and usable, thus reducing
application—will improve. You will break the cycle of the high cost of maintenance. Flow pipelines
technical debt. are a single budget item and eliminate
the high overhead costs associated with
Flow involves five principles: (1) Only deliverables count; traditional project and change management.
(2) Have a good sponsor; (3) Have a good team; (4) Have
a good place to work; (5) Always promote antifragility. We The Flow structure is broken down into
further break down these principles into practices and skills. a Flow sponsor and a team. A single
sponsor supports teams of producers and
One way to think of Flow is as a slim version of actors. The sponsor provides inspiration,
Scrum/DevOps—without the project distinction and just direction, and imagination. The sponsor
doing daily tasks. is ultimately responsible for the work
product of the teams.

Producers define the work, manage the

backlog, and present activities to actors.
The team on the Producers are a combination of former
project managers, business analysts,
Golden Gate bridge Scrum product owners, and subject
matter experts. Producers generally work
works on that in teams of two to four people. Their main
job is to break down the work into daily
bridge—every day—but microservices that actors can complete in
one day. They are developers, installers,
that work doesn’t stop security experts, and people who work
in quality assurance and computer
any of the 12,000 operations. They perform and implement
the work the producers give them. Actors
work in teams, of which three or four
vehicles from using are full-time workers and one or two are
available on demand. Both producers and
it—every day. actors work in self-directed teams.

Copyright © 2020 by The Standish Group International, Inc. 13

 FOOTNOTES
FN1: Technical debt is the cost to maintain existing applications, features, functions and even hardware that
have lost their value and no longer serve a useful purpose for the organization. Technical debt is depicted in
rising IT costs, but it’s often hard to recognize within the general IT inventory, and even harder to eliminate.
The tradeoff is often to just pay the debt and then invest in new application development. However, this
creates a cycle of ever-increasing technical debt, which leads to bigger IT budgets and increased staff.

FN2: Fragility is a hallmark of systems that fail to thrive as a result of stressors, shocks, volatility, noise,
mistakes, faults, attacks, or failures. In software applications, the goal has always been to make systems
resilient as well as robust. However, this concept has actually made software harder to modernize or keep
current because of the ever-growing base of code; this increases technical debt and fragility. Killing off unused
features and functions and adding new functions allows applications to “wander” more naturally and makes
them less fragile. It’s a concept that is fundamentally different from what we think of as “resiliency” [8].

FN3: Absorption Theory comprises three broad concepts—continuous change, decreasing complexity, and
conservation of familiarity—that will increase the adoption of features and functions in software projects [9].
Absorption Theory describes the ability of an organization to successfully grasp business and technical changes
without disruption.

Copyright © 2020 by The Standish Group International, Inc. 14

REFERENCES
[1] The Standish Group, “Modernization: Clearing a Pathway to Success” (Standish Group, 2010). Can be
accessed by Standish general members in the research report section of the Standish website.

[2] The Standish Group, “Modernization in Place” (Standish Group, 2014). Can be accessed by Standish
general members in the research report section of the Standish website.

[3] Jim Johnson and Hans Mulder, “Go with the Flow: Envisioning a Successful Pipeline of Software Projects”
(Standish Group, 2019). Can be accessed by Standish general members in the research report section of
the Standish website.

[4] Jim Johnson, “Decision Latency Theory: CHAOS Report 2018” (Standish Group, 2018). Can be accessed
by Standish premium members in the premium report section of the Standish website.

[5] The Standish Group, “CHAOS Report 2016: The Winning Hand” (Standish Group, 2016). Can be
accessed by Standish premium members in the premium report section of the Standish website.

[6] Jim Johnson and Evan Sorensen, The Good Mate (Standish Group, 2018). Available in the Standish store.

[7] Jim Johnson, The Good Sponsor (Standish Group, 2016). Available in the Standish store.

[8] Nassim Nicholas Taleb, Antifragile: Things That Gain from Disorder (Random House, 2014).

[9] The Standish Group, “CHAOS Manifesto 2015, The Law of Diminishing Returns”
(Standish Group, 2015). Can be accessed by Standish general members in the CHAOS report
section of the Standish website.

[10] Jim Johnson, “CHAOS2020 Beyond Infinity” (Standish Group, 2020). Can be accessed by Standish
premium members in the premium report section of the Standish website.

15
 ABOUT THE STANDISH GROUP
The Standish Group is a primary research advisory organization that focuses on software
development performance. Using our extensive primary research, you can improve your investments
in software. We are a group of highly dedicated professionals with years of practical experience helping
organizations improve.

ABOUT THE CHAOS RESEARCH

The Standish Group collects, adjudicates, and approves between 2,500 and 5,000 new project cases per
year. Each organization profile has 24 data points, and each project profile has more than 80 data points. In
addition, there are 12 worksheets for each project. The CHAOS database is used to create reports such as the
CHAOS 2020 Report as well as general queries, single-project assessments, future portfolio predictions, and
performance benchmarks.

ABOUT THE AUTHORS

Jim Johnson is the founder and chairman of The Standish Group. He has a
combination of technical, marketing, and research achievements focused on mission-
critical applications and technology. He is best known for his research on project
performance and early recognizing technology trends. Jim is a pioneer of modern
research techniques and continues to advance in the research industry through case-
based analytical technology.

Hans Mulder Prof.dr.ing MSc BA is Standish European research director and

professor at the Antwerp Management School. As the founder of his own company,
Venture Informatisering Adviesgroep, he is on the management and executive boards
of various IT companies. He is regularly engaged as an IT expert when conflicts
between companies need to be resolved in or out of court.

Copyright 2020 by The Standish Group International, Incorporated

All rights reserved. No part of this book may be reproduced in any form or by any electronic, mechanical, or manual
means, including information storage and retrieval systems, without explicit permission in writing from the publisher. In no
circumstances can this work be retransmitted in any form, repackaged in any way, or resold through any media.

PLEASE RESPECT INTELLECTUAL RIGHTS! Published by: The Standish Group International, Inc.
66 Tern Lane, Centerville, MA 02632 508-760-3600 www.standishgroup.com

Copyright © 2020 by The Standish Group International, Inc. 16

View publication stats