Minimum viable replacement presentation sIM presentation

Agenda
What marriages and projects have in common
Why Large Enterprise Technology Projects are so Painful
The Problem with MVPs When Replacing Legacy Technologies
An Introduction to the Minimum Viable Replacement Framework
Kev’s Five Steps to MVR Nirvana
Feedback
©2021 Kevin J Mireles 2

What percentage of large IT projects fail?

What percentages of marriages fail?

Why?
Expectations Reality

The challenge is too many people think we have
crystal balls filled with perfect insight
6
©Kevin J Mireles @kevinjmireles

When in reality we can see only the tip of the
iceberg, with 80% waiting to be discovered
7
?
©Kevin J Mireles @kevinjmireles

My goal tonight is to help you align
Expectations Reality
&
to Maximize Your Probability of Success!

So what are my qualifications?
©Kevin J Mireles @kevinjmireles 9

And what could be done
differently?
Why was it so painful?

1. Applied the MVP model to
replacing legacy systems
2. Thought could accurately
predict the future
3. Missed key risks by focusing
on averages
4. Failed to measure impact at
a customer level
Why was it so painful?
1. Use the MVR framework to
replace legacy systems
2. Accept uncertainty & adopt
probabilistic approach to
project management
3. Identify & solve for extremes
4. Quantify & integrate impact
into project plans & status
And what could be done
differently?
And these are my answers, which I’ll explain in detail to you!

MVPs are great when introducing entirely new capabilities to
new customers

But what if your customers already have a car?

And that’s customized just for them?

Plus, they are being driven by your largest customers!

+
And unless you get them to swap their old car for the new
car, you’ll still need to maintain all of your old legacy systems

Will the MVP concept work then?

Instead, embrace the Minimum Viable Replacement!
MVR

1
9
Minimum Viable
Product
• New Technology
• New customers
Minimum Viable
Replacement
• New Technology
• Existing customers
©2021 KEVIN J MIRELES
MVRs focus on replacing existing technology for existing
customers
versus

Minimum Viable Replacement
• What’s the bare minimum I have to do
do to migrate all of my existing
customers to the new version and retire
the old system?
20
MVPs & MVRs have different end goals
Minimum Viable Product
• What’s the bare minimum I need to
do to get an initial slice of
customers?
versus

• Will my existing customers switch from
their old version to the new version?
21
MVPs have to prove their value, while MVRs have to prove
they’re good enough to get customers to upgrade
• Is there a market for my product?

• Primarily compete with your existing
products
22
The biggest competitors for a minimum viable replacement
are the previous versions of the product
• Compete with other companies &
products

While as a percentage of customers, the number of
laggards may be small, the largest customers will
also usually be your biggest laggards

For example, which companies are still using mainframes?
©2021 KEVIN J MIRELES 26
Mainframes are used by 71% of
the Fortune 500
Joe’s hotdog stand
or

MVP G
MVP F
MVP E
MVP D
MVP C
MVP B
27
Minimum Viable Replacement = Sum total of all the MVPs
required to meet all customer needs required to transition
existing customers and retire existing system
Customer segment A
Customer segment B
Customer segment C
Customer segment D
Customer segment E
CustomersegmentF
Customer segment G
Segment Revenue Opportunity
Simplest
to
most
complex
Smallest
to
largest
MVP A

MVP G
MVP F
MVP E
MVP D
MVP C
MVP B
28
Plus any additional enhancements/ inducements required to
get stakeholders and customers to change and adopt new
systems and processes
MVP A Customer segment A
Customer segment B
Customer segment C
Customer segment D
Customer segment E
CustomersegmentF
Customer segment G
Simplest
to
most
complex
Smallest
to
largest

MVP G 1,2,3,4, 5,6,7, 8, etc.
MVP F
MVP E
MVP D
MVP C
MVP B
29
And if individual customers are large enough to have customer-
specific requirements, then an MVP/MVR has to be developed
for each customer
MVP A Customer segment A
Customer segment B
Customer segment C
Customer segment D
Customer segment E
CustomersegmentF
Customer segment G
Simplest
to
most
complex
Smallest
to
largest

30
While avoiding customer breakage is key, you have to
balance the desire to meet your existing customers’
needs with the opportunity to serve new market
segments with different functionality
A Bird in the Hand? Two in the Bush
Someone is always going to be unhappy, the question is who, what
are the consequences and which tradeoffs are you willing to make?
or

The Five Steps to MVR Nirvana
1
• Assess whether you’re dealing with an MVR or not
2
• Break your project into its constituent components
• Define the segment MVPs/MVRS
3
• Identify & quantify sources of risk and opportunities
• Set realistic expectations regarding risk, timelines, scope, etc.
4
• Develop & execute strategies to maximize benefits and minimize
risk
5
• Iterate, iterate, and iterate some more

1. Assess: Is this an MVR?
Retiring legacy technology?
Requires migrating existing users to new technology?
Breakage is a significant risk?
Common examples:
 Merging and retiring existing systems post acquisition
 Sunsetting a legacy product
 Transitioning to a new underlying technology

Step 2: Decompose your project from both an execution &
adoption perspective

2
• Break your project into its constituent components
• Define the segment MVPs/MVRS
3
4
risk
5

MVP G
MVP F
MVP E
MVP D
MVP C
MVP B
34
Identify your customer segments and then the
capabilities/MVPs required for each customer segment
Customer segment A
Customer segment B
Customer segment C
Customer segment D
Customer segment E
CustomersegmentF
Customer segment G
Simplest
to
most
complex
Smallest
to
largest
MVP A

MVP G
MVP F
MVP E
MVP D
MVPC
MVP B
MVP A
35
Since you are dealing with enterprise icebergs, where 80% of the
work required is invisible, impossible to know exact requirements
Customer segment A
Customer segment B
Customer segment C
Customer segment D
Customer segment E
CustomersegmentF
Simplest
to
most
complex
Smallest
to
largest
Customer segment G

MVP G
MVP F
MVP E
MVP D
MVPC
MVP B
MVP A
36
The more customizations and changes required by internal and
external stakeholders, the more difficult the migration will be
Customer segment A
Customer segment B
Customer segment C
Customer segment D
Customer segment E
CustomersegmentF
Simplest
to
most
complex
Smallest
to
largest
Customer segment G

Step 3: Identify & quantify sources of risk & opportunities


• Break your project into its constituent components, both from an
execution and adoption perspective
3
4
risk
5

Use the KUCI Model to identify and quantify key sources
of risk and opportunity
Risk
Uncertainty
Complexity
Impact
Kevin’s

It provides the math and the logic to explain why most estimates,
project statuses and Gannt charts are just pretty lies
From Pretty Lies
• We know what needs to be done
• We know how to do it
• We know when it will be done
• We know how much it will cost
• It’s all right here on our Project
Plan!
To Ugly Truths
We have a hypothesis!

First, understand the relationship between uncertainty &
complexity
Risk
Uncertainty
Complexity

Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tasks
1 90%
2 90%
3 90%
4 90%
5 90%
6 90%
7 90%
8 90%
9 90%
10 90%
11 90%
12 90%
13 90%
14 90%
15 90%
16 90%
17 90%
18 90%
19 90%
20 90%
Probability Pop Quiz!
If you are 90% confident that each task
can be completed on time & with quality,
what’s the probability that the predicted
outcome will be achieved after 20 tasks?

Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tasks
1 90%
2 81%
3 73%
4 66%
5 59%
6 53%
7 48%
8 43%
9 39%
10 35%
11 31%
12 28%
13 25%
14 23%
15 21%
16 19%
17 17%
18 15%
19 14%
20 12%
Answer = 12%

(% Probability of Success for Each Task )^(# of Variables) = Overall Probability of
Success as Initially Planned
(100%)^20 100%
(95%)^20 36%
(90%)^20 12%
(80%)^20 1%
(70%)^20 0%
The ability to forecast the future decays
exponentially making it impossible to
accurately predict outcomes for
projects that combine both uncertainty
and complexity!
Key Takeaway!

Which is why projects should start out red, and only change
to yellow and green after key milestones are hit
Cone of uncertainty
Source: wikimedia.org
Cone of uncertainty

No different than a marriage or any other journey into the
unknown – where the beginning is much different than reality
Source: wikimedia.org
Just because there’s high likelihood of failure and you know the road
ahead won’t go as planned, doesn’t mean you don’t get married!

Second, let’s define & understand the concept of impact
Risk
Uncertainty
Complexity
Impact
Kevin’s

Are all customers, scenarios & ultimately impacts the same?

No, some are much, much bigger than others!
$523,964
$260,174
$1,996
$0
$100,000
$200,000
$300,000
$400,000
$500,000
$600,000
0 200 400 600 800 1000
Rank
Revenue
in
millions

Walmart is 263X larger than smallest Fortune 1,000
$523,964
$260,174
$1,996
$0
$100,000
$200,000
$300,000
$400,000
$500,000
$600,000
0 200 400 600 800 1000
Rank
Revenue
in
millions

And 11 million times bigger than the average sole proprietorship or
13K times bigger than the largest small business
Business Size
Average Revenue
in millions
How many times
bigger Walmart
is
Zero Employees $ 0.046 11,390,522
1 to 4 Employees $ 0.387 1,353,912
5 to 9 Employees $ 1.000 523,964
10 to 19 Employees $ 2.164 242,128
20 to 99 Employees $ 7.124 73,549
100 to 499 Employees $ 40.775 12,850
# 1000 on Fortune 1000 $ 1,990.000 263
Walmart $ 523,964.000

Not only does impact tend to be hyper-concentrated,
it positively correlates with complexity & uncertainty
48
# of Brands
24
# of Countries
1,152
Potential
Permutations
X
=
48
# of Brands
24
# of Countries
12,000,000
Potential
Permutations
X
=
10,500
Locations X
24
# of Countries
24
Potential
Permutations
=

Which is why replacement projects tend to blow
up just when you think they are almost done

The KUCI Risk Identification & Quantification model can
help you avoid surprises throughout the project
Risk
Identification&
Quantification
Uncertainty
Complexity
Impact
Kevin’s

Key KUCI components
Risk
Uncertainty
Execution
How confident are you that you can deliver the
solution as defined?
Adoption
How confident are you that the solution delivered
will be adopted by your end users/customers?
Complexity
Variables
How many variables, e.g. tasks, teams,
technologies, user types, geographies etc. are
involved in the project?
Impact
Upsides
When/where in the project lifecycle/ user base are
the benefits concentrated?
Downsides
What can go wrong? What are the potential
downsides if not successful, and when/where will
the impacts be concentrated?

Uncertainty in software projects is primarily driven by two things
Probability of Technical
Success
X
Probability of Successful
Customer Adoption
( )
Can you execute the
work as defined?
Will the dogs eat the
dog food?

Which I’ve translated into an equation
Success
X
Customer Adoption
( )
% Confidence
in Team X
% Confidence
in Technology )
(
Probability of
Technical Success =
% Confidence in Team = % Confidence that the team has the technical skills, resources, cohesion and subject
matter expertise, etc. to successfully deliver a technically sound solution with the available technology
% Confidence in Technology = % Confidence that the technology chosen has the usability, stability, flexibility,
scalability, etc. to meet the project’s requirements

Confidence in Team Questions
Probability of Accurately Forecasting Success
Low confidence
Probability = 0-40%
Medium Confidence
Probability = 41%-70%
High Confidence
What is the team cohesion &
performance like?
New team. Struggling team.
Some experience.
Together <1 year
Stable high-performing
team
How much experience does the team
have with the technology?
Little to none. New area
software, form factor, etc
Some experience but still
learning
Experts. Done similar
projects previously
How much expertise does the team have
with the overall subject matter?
Little to none. Doesn’t
understand the business.
Some experience but not
experts.
Experts, understand not
only common use cases but
exceptions as well
Are separate IT ecosystems being
merged?
Separate ecosystems with
different data models,
business rules, etc.
Two or more similar
systems being merged
Enhancing existing
functionality
have with the specific existing systems &
processes?
Little to none. Never worked
on app & no documentation
Worked on it but not a
systems expert
Experts. Helped develop
system. Know where are all
the quirks are.
have with the specific users?
Little to none. Many different
types of users
Some familiarity Worked as a user
How much will the changes impact other
systems or other systems impact you?
High. Requires changes to
dozens/unknown #
Small changes No changes
If interacting with other systems, how
much control does team have over the
other systems.
Low. Need to request
assistance from group with
different priorities/
governance
Some. Can shape other
teams’ priorities but still
risks
High control. Complete
control over dependent
systems

Technology Confidence Questions
58
Low confidence
Probability = 0-40%
Medium Confidence
High Confidence
Is the technology proven?
Never at our company or to
solve similar problems with
similar scale, etc.
Yes, In similar companies or
our organization, but not in
exact same manner
Yes! Standard part of
technology stack
Has the technology been proven to
scale?
Never at our company or to
solve similar problems with
similar scale, etc.
Yes, In similar companies or
our organization, but not in
exact same manner
Absolutely! No issues.
How easy is it to develop for?
Don’t know. Not an easy-to-
develop for/in platform. Lots of
quirks & unintuitive
workarounds
Works reasonably well &
understand quirks.
Easy & developers like
it!
Has the technology been deployed
in a customer-facing manner?
No. Or Don’t know. Yes at other companies. Yes, within our company
Can it be easily customized to meet
our unique use cases?
No. Or Don’t know.
Should be able to but
haven’t fully validated.
Yes.
How stable/bug-free is the
technology?
Not stable. Buggy technology.
Should be fairly reliable but
haven’t deployed in our org.
Stable & bug free.
©2021 Kevin J Mireles

The second half of the equation is the probability of
successful customer adoption
Success
X
Probability of
Successful Customer
Adoption
( )
Perceived Work Required = Amount of work, e.g. additional steps, learning, change, etc. required to adopt
Power, Culture & Personality Factor = The various dynamics that determine someone’s willingness to try new
things, change existing habits/processes
Perceived
Value* -
Perceived Work
Required*
( +/-
10
) Power, Culture &
Personality Factor*
Customer Adoption =
Perceived Value = Benefit customer or users expect to receive, includes expected, initial & long-term value.
* Expressed as number between 1 & 10

Perceived Value Questions
60
Perceived Value Ranges
Low Perceived Value
0 to 5
Medium Value
6 to 8
High value
9 to 10
Does the product match and exceed current
capabilities of existing system critical to
core users?
No. Matches some but not
all functionality. It’s an MVP
not MVR.
Yes. Matches all
existing functionality
Matches & exceeds all
functionality
Are the benefits immediately visible to the
end user?
No. Requires work & or
training to discover
functionality
For the most part, but
requires some level of
discovery
Everything is completely
visible
Do you have a narrowly focused target
market with fairly homogenous needs &
traits or a broad range of users with
different needs/use cases?
Target = whole world. From
large to small, etc
Will serve a variety of
different users with a
variety of use cases
Laser focused on specific
subset of users.
Do you know who your most important
customers are?
No More or less.
Absolutely! Know each
& everyone by name,
role, etc.
What level of usability & value testing have
you done?
Testing? What’s that?
Tested interactive
prototype but not
functional.
Thoroughly tested
completely usable
prototype with key users
Does the product save time & money or
increase revenue
No.
No change from
existing system
Absolutely! Saves both
time & money!
How does the application impact key
customer metrics
Negatively impacts or no
alignment to existing KPIs
Somewhat, but not
directly.
Aligned to key goals, e.g.
closing new sales.

Perceived Work-Required Questions
61
Perceived Work Required
Low perceived work
0 to 5
Medium Perceived Work
6 to 8
High Perceived Work
9 to 10
Does the application eliminate the need
for a person to operate the system?
Completely automates the
process, so no UI or
operator required.
No change
No. Requires additional
people.
Does the application subtract or add
work for the user?
Eliminates time-
consuming steps! 
No change Adds work. 
Does the application require training?
No! Eliminates the user
interface all together
Some training would be
good but fairly intuitive
Yes! Lots & lots of
repetition to get good at it
but users will use it
infrequently.
How much work is required before get
value?
No work whatsoever or
someone else does all the
work.
Some setup required but
fairly straightforward.
Requires not just training,
but integration into other
systems, massaging data,
etc. before get value
Does getting value require
organizational & process changes?
No changes whatsoever
beyond eliminating steps
people hated.
Minor changes to
process.
Yes! Need to change
fundamental processes,
roles & Organizations in
order to get benefit

Power, culture, personality & other factors: What additional factors
will increase or decrease your probability of successful adoption
62
Decrease confidence
Subtract up to 30%
Neither good nor bad
No change
Increase Confidence
Add up to 30%
Power dynamics: Who has the
power in the relationship?
They do! They are your largest
customer & can easily switch
as there are lots of
competitors
They need you as much
as you need them
• You are one of their largest
customers and they can’t get
paid unless they use the new
software.
• They’re lower-level employees
with little power
Culture/Personality: Does the
organization culture/ users’
personalities embrace or reject
change?
Org has been working same
way for decades & embraces
tradition as core value
Willing to try new things
& changes when makes
sense
Org is always looking for new toys
and embraces change as
competitive advantage
Regulatory or other
environmental constraints
Regulations or other things
about the environment make
adopting new systems high
risk
Regulations require adopting new
system to comply
Money: How much will it cost
to make changes?
Customer has to pay lots of
money to adopt
Customer is paid to make
changes
Etc.

Which you can then use to forecast your project’s overall
probability of success as currently defined
Probability Technical Success
Probability of
Adoption Success
Overall
Probability
of Success
Team
Confidence
X
Technology
Confidence
X
Feature A 90% 90% 90%
=
73%
Feature B 80% 80% 80% 51%
Feature C 80% 80% 80% 51%
Overall
Probability
58% 58% 58% 19%

Step 4: Develop & execute strategies to maximize
benefits & minimize risk



4
risk
5

Start by focusing on the extremes

66
Traditional UX guidelines espouse focusing on the 20% of
the scenarios that meet 80% of your customer needs
For an MVP, it makes
sense to focus on the
20% of the capabilities
that meet the needs of
the majority

67
For an MVR focus on the
one percent that drives the
40- 60% of your revenue
or impact and 80% of your
complexity

68
The 1% have such vastly different requirements from the other
99% that trying to transform a system designed for everyone
else is almost impossible

69
Design & Architect for the 1% while delivering
for the 80% first
Identify the business and
scalability requirements for the
largest, most complex, highest-
risk customers/ scenarios first.
But deliver simpler solutions that
meet the needs of your less
complex customers first so you
can deliver value to market sooner
while building more complex
solutions for later delivery
Design 1st
Build 1st
Build 1st

70
Or develop entirely different systems to meet the very
different needs
Standard designs &
features for the 99%
Custom solutions for
the 1%
Shared Infrastructure
whenever possible

Step 5: Iterate, iterate and iterate some more


3
4
risk
5

72
Ultimately, successfully executing a Minimum Viable Replacement is a lot like
trying to get to the other side of a mountain range without a detailed map, not
impossible but much more difficult than your management expects, so good
luck and god speed!
– Kevin Mireles

73
Visit www.DontMakeMeWork.com to read more about Minimum Viable
Replacements or email Kevin@kevinmireles.com or connect with me on
Linkedin!
Thanks! Kevin Mireles

Minimum viable replacement presentation sIM presentation

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Minimum viable replacement presentation sIM presentation

Semelhante a Minimum viable replacement presentation sIM presentation (20)

Mais de kevinjmireles

Mais de kevinjmireles (13)

Último

Último (20)

Minimum viable replacement presentation sIM presentation

Notas do Editor