Usually Software projects don't go pretty well. Here's the explanation about the way we can increase the success rate combining Design Thinking and Agile methodology.

1. Software projects can go well…
ask me how
Dani Cardelús - 2016

2. NUMBERS
AND FACTS

3. 142.000M€
is losing every year European Economy due to IT project failure.
Around 5% of his GDP…
Source: Gallup - The cost of bad project management, 2012

4. 75%
of business and IT executives anticipate their
software projects will fail
Source: Geneca - Up to 75% of Business and IT Executives Anticipate Their Software Projects Will Fail, 2011

5. 1 on 6
IT projects have a cost overrun
of 200% and a schedule
overrun of almost 70%
Source: Harvard Business School - Why Your IT Project May Be Riskier Than You Think, 2011

6. 17%
of IT projects go so bad that they can threaten the
very existence of the company
Source: McKinsey - Delivering large-scale IT projects on time, on budget, and on value, 2012

7. Then...
How may projects go wrong?

8. “Go wrong” means:
Projects are “obviously” delivered
late, are finished with a cost
overrun or with less than the
initally required functions
Projects are cancelled before his
planned end date or anybody use
the result once delivered

9. Let’s take CRM systems for instance…

10. 29%
Source: Virginia University – Coursera “Agile meets Design Thinking”, 2016

11. 47%
Source: Virginia University – Coursera “Agile meets Design Thinking”, 2016

12. More than 50%
Source: Virginia University – Coursera “Agile meets Design Thinking”, 2016

13. 56%
Source: Virginia University – Coursera “Agile meets Design Thinking”, 2016

14. 70%
Source: Virginia University – Coursera “Agile meets Design Thinking”, 2016

15. Globally…

16. Source: McKinsey - Delivering large-scale IT projects on time, on budget, and on value, 2012
66%
of software projects with cost overrun

17. Source: McKinsey - Delivering large-scale IT projects on time, on budget, and on value, 2012
33%
of software projects with schedule overrun

18. PROBLEMS
AND SINS

19. Let me tell you a story…

20. JOHN IS THE CTO OF AN IMPORTANT
DEPARTMENT INSIDE A LARGE CORPORATION
MANY PEOPLE REPORT TO HIM DAILY,
CONFESSING HUNDREDS OF COMPLAINTS AND
POTENTIAL IMPROVEMENTS

21. HE WANTS TO MAKE AN IDEA COME TRUE OR
JUST TO SOLVE A PROBLEM
HE THINKS SOFTWARE CAN HELP AND PUT
ASIDE SOME MONEY…

22. TOM HAS A COMPANY PLENTY OF SOFTWARE
“EXPERTS” DEDICATED TO BUILD SOFTWARE
PROJECTS HE BELIEVES CAN HELP JOHN

23. JOHN AND TOM HAVE A MEETING…
JOHN EXPLAINS WHAT HE WANTS AND TOM
GATHER THE PROJECT “REQUIREMENTS” AS
ALWAYS DO

24. TOM PREPARES A TECHNICAL AND ECONOMIC
BID TAKING AS A BASIS WHAT HE
UNDERSTAND THAT JOHN NEEDS
AFTER A HARD NEGOTIATION, THEY REACH AN
AGREEMENT

25. PRIOR TO WRITE A CODE LINE, TOM’S TEAM
SPENDS A LOT OF TIME DETAILING WHAT THE
PRODUCT SHOULD DO
AND THE TIME GOES BY…

26. TOM ASKS JOHN TO VALIDATE THE HUNDREDS
OF PAGES THAT CONTAIN THE
PRODUCT/PROJECT DETAIL
JOHN DOESN’T UNDERSTAND THE DOCUMENTS. BUT HE
TRUSTS IN TOM, WHO ENSURES THEY DESCRIBE
EXACTLY WHAT IS ASKING FOR

27. AND THE TIME GOES BY…
TOM’S TEAM STARTS TO BUILD THE PROJECT

28. AFTER FEW MONTHS AND SOME INSISTENCE,
JOHN GETS TO HAVE A PRESENTATION OF
PROJECT’S ADVANCES
HE DOESN’T UNDERSTAND WELL WHAT
HE’S SEEING. BUT HE’S STILL
CONFIDENT ABOUT HE’S GOING TO
OBTAIN WHAT HE’S ALREADY PAYING

29. AFTER A LONG TIME AND, AS TOM SAYS,
“IRRELEVANT” DEVIATION IN DATES, TOM
DELIVERS WHAT THEY’VE BUILT
IT’S TIME TO VALIDATE TOM’S TEAM STRONG
EFFORT

30. JOHN DISCOVERS THAT THERE ARE MANY
THINGS FAR FROM HE EXPECTED AND ASKS
TOM TO CHANGE THEM

31. AFTER SOME MINOR CHANGES, TOM ASKS
FOR MORE MONEY IN ORDER TO COVER
PROPERLY “ALL” THE CHANGES
HE REFRESH JOHN’S MEMORY ABOUT THE
DOCUMENTATION THAT HE VALIDATED AT THE
BEGINNING…

32. AFTER A LOT OF CUT AND THRUST, BOTH
AGREE TO STOP THE PROJECT AT THE LEAST
EVIL POINT FOR JOHN

33. WHEN JOHN SHOWS THE PRODUCT TO USERS,
THEY DON’T SEE THEIR PROBLEMS REFLECTED
BESIDES THE FACT IT IS COMPLICATED,
INCOMPLETE AND UNUSABLE
OBVIOUSLY, USERS DECIDE TO USE THEIR OLD
FASHION BUT EFFECTIVE EXCEL FILES…

34. Secret message

35. John have got something that…
More expensive
than he expected
Long-awaited for
everybody
Far from his initial
expectations
Nobody is going to
use it

36. John is going to think twice next time

37. Now, let’s accept that…

38. There’s a strong business case supporting the project
There’s a sponsor also behind the project
Developers get access to the right resources
Developers apply right methodologies
Developers use right tools and infrastructure
Project managers know how to do it conveniently
And unicorns exist

39. So…
What can goes wrong?

40. How the customer explained
it
How the Project leader
understood it
How the Analys designed it How the programmer wrote ir How the Business Consultant
described it
How the project was
documented
What operations installed How the customer was billed How it was supported What the customer really
needed
Do you remember the old joke?

41. All we commit sins…

42. Pride

43. Frequently we think for others believing we’ve got the
solution for everything
We don’t ask to “real” users, who have the problems and use the programs
We don’t validate our proposals with them
The list of requisites that describes what we “have to” do, usually don’t reflect real needs
We always fall into temptation to say what we have to do to solve something instead
to say what’s the problem
Software “experts” believe also they have whole truth for every problem.And it’s not true…

44. Gluttony

45. Frequently we try to take on more than we can analyze,
manage, treat or digest
We extend unnecessarily the time we get tangible and valuable things
We extend unnecessarily the time to make mistakes
Our control obsession drive us to spend too much time in non relevant details
Excessive detail means an exponential increase of time
Software firms leverage the projects to experiment and learn

46. Laziness

47. Frequently we don’t know what we want (and what we don’t
want either)
Software is something intangible. It’s hard to draw shape, color or size…
We prefer to take decisions basis in comparison, but that’s impossible in software matters
We prefer sit and see before to say yes or not
We prefer to make assumptions best before we go into details with any time consuming subject
And that’s something that falls typically into developers side…

48. I’LL NEED TO KNOW YOUR
REQUIREMENTS BEFORE I START
TO DESIGN THE SOFTWARE
FIRST OF ALL, WHAT WE
ARE YOU TRYING TO
ACCOMPLISH?
I’M TRYING TO MAKE YOU
DESIGN MY SOFTWARE
I MEAN WHAT ARE YOU
TRYING TO ACCOMPLISH WITH
THE SOFTWARE?
I WON’T KNOW WHAT I CAN
ACCOMPLISH UNTIL YOU TELL ME
WHAT THE SOFTWARE CAN DO
TRY TO GET THIS CONCEPT
THROUGH YOUR THICK SKULL: THE
SOFTWARE CAN DO WHATEVER I
DESIGN IT TO DO!!
CAN YOU DESIGN IT TO TELL
YOU MY REQUIREMENTS?
An example…

49. Envy

50. Frequently we want always what we see in neighbor’s house
although we don’t understand what is it for…
Everybody wants to come out well in the picture and be the most innovative ever
But technology advances faster, and things became obsolete quickly
In the other side, people don’t lie when they talk about software, but never say all the truth…
We always want newest.We always want what other sell us as perfect
Result: We ask for certain features only for technology excitation and not supported by a real business need

51. Greed

52. Frequently EVERYBODY wants ALL for the fair price things
value
We don’t know how much do the things cost and how much is their adoption
We don’t renounce to the maximum quality at the same price, even when it’s unacceptable
This is why we become obsessed with documentation.Just to say at the end, “I told you”
And at the end we’ve got what we paid for

53. And what it should be luxurious…

54. … becomes pure anger

55. SOLUTIONS
AND PENANCES

56. Which are the keys to find the
right solution?
These are…

57. It should exist a problem to solve
It should exist a need to cover
It should exist somebody ready to lead and fight for the project
It should exist an expect benefit (tangible or intangible)
It should exist a clear motivation and somebody to push…
…otherwise, better don’t start nothing
1HAVE A REASON
AND A SPONSOR

58. 2FOCUS ON END USER
AND PAY ATTENTION TO HIM
User knows what he likes
User knows what he doesn’t like
Empathy with users and learn from their environment is the key
Count with their criteria and validation is also key
We must avoid assumptions and go to the source
Let’s take a look and by verify ourselves instead of talk by references
We should count on him constantly during the definition and construction process

59. Let’s avoid unsubstantial chats and discussions
Let’s get on whit it and work hard
Let’s ideas come true with prototypes
Let’s give our opinion about these “high resolution” prototypes and move on
Trial and error
Identifying an early mistake is better than wait to the end
Fail is needed
3DESIGN AND TOUCH THINGS
BEFORE WE TAKE A LEAP OF FAITH

60. All is about dialog and observation
We don’t have to fear of making mistakes or asking
We don’t have to fear of assuming our internal miseries
Paper can wait…
Let’s confirm all what we are identifying on the field with specific actions
Let’s think globally first to gradually focus in what really matters
4UNDERSTAND PROBLEMS WELL
NOT ONLY A SIMPLE REGISTRATION

61. 5TEST,VALIDATE,TEST,VALIDATE…
TIME AFTER TIME AGAIN
The path towards success is not a straight line
The “understand > create > learn” process has to be as faster as we can do
Prior we validate, prior we advance…
And prior we detect errors
Applying this methodology we’re able to say what we like and don’t in reasonable times
Otherwise we fall into never-ending times and non existing feedback

62. 6MAXIMIZE CREATIVITY
AND LEVERAGE COLLECTIVE KNOWLEDGE
Let’s get out of our comfort zone
Let’s play without prejudices
Only in this way new solutions to old problems will appear spontaneously
Integrative thinking is the key
One hundred minds think better than one
Let’s leverage then collective knowledge and thinking
But don’t misunderstand these words…We must take decisions and advance at a reasonable speed

63. 7CREATE VALUE IN A AGILE WAY
Let’s build iteratively getting the user involved all the time
Let’s deliver valuable things to the user as soon as possible
Don’t wait until the end to make them enjoy
Don’t wait until the end to change things
Let’s check that the product we’ve designed together is a reality
It’s a transparency amazing exercise…
…let’s take advantage of it
WHILE WE SOLVE PROBLEMS

64. And what’s the way to
overcome any obstacle along
the path?
This is…

65. Paso 1 – Discovery and empathy
Who’s really my user?
What matters to this person?
What’s his behavior?

66. Paso 2 – Design
Which are the user
needs?
Which are their insights?

67. Paso 3 – Ideate
What can I think to cover these
needs?
How can I get out of the general
rule and be disruptive?

68. Paso 4 – Prototype
How can I show my ideas?
How can I prototype as “high
fidelity” as possible?

69. Paso 5 – Test
What worked?
What didn’t?
How can I adjust it?

70. Paso 6 – Build
How can I provide value as soon
as possible?
How can I assure the quality
during the process?

71. EMPATHYZE
Discover and
understand the
users and
organization
assumptions,
preferences and
biases related to
subject we want to
solve through
interviews and
observation
Identify and
interpret emerging
trends and patterns
observed during the
first phase, related to
the user needs and
insights
Develop sets of
divergent and
provocative maps
using creativity, data,
intuition and
research
Build tangible
representations of
reality bites in a
“high fidelity”
prototype way. Do it
with a significant
number of ideas to
obtain feedback
Share materialized
ideas with the same
users you’ve been
working along the
process to know their
reactions in front of
your “high fidelity”
prototypes
Develop and
implement the
selected idea in a
iterative and agile
way, following the
quality standards
accorded with users
DESIGN IDEATE PROTOTYPE TEST BUILD
Summarizing……

72. BENEFITS

73. Two options…

74. COLLECT ANALYZE DESIGN BUILD BUT HERE ALL CHANGES…
Option 1: “As usual”…
…but unfortunately we know the results

75. Option 2: A new vision

76. When DESIGN THINKING meets AGILE
Discover, define
and ideate
Prototype and
test
Build and deliver (without changes)

77. Ok then, but…
Which are the benefits?

78. We cover all the bases

79. Even though we could need to
make a roundabout, what we
obtain is always something valid
So, if we don’t arrive to the end of
the process, maybe the project
wasn’t necessary
Better this than realize it doesn’t
work once your finished

80. We guarantee its future
usage

81. Result is something fruit of an
understanding between
everybody. In this way, the
rejection risk has to be minimum
We assure in every moment the
user’s involvement…
…in despite of they need to invest
more time than before

82. We reduce time… and
money

83. We prototype and validate with
users…
… reducing development time
and changes risk
These are traditionally the most
time consuming phases in a
software project

84. But watch out…
If we omit these recommendations
(a reason, a sponsor, pamper the
users, prototyping…), we can fall
easily in an excessive iteration and,
consequently, lose all the well-
made advantages

85. Who’s the first to confess his sins?

86. thanks for your attention

87. 20 years dedicated to
Information Systems and
Technology
Many others dedicated to
Water Industry with different
hats
Passionate about Software,
Business Analytics, Marketing
and Business Development
Runner, reader and sporadic
blogger
Dani Cardelús
ABOUT THE AUTHOR

88. danicardelus@gmail.com

89. IMAGES / CREDITS
HTTP://THENOUNPROJECT.COM/
JAVIER CABEZA
VICONS DESIGN
LORENA SALAGRE
CHISTOPHER HOLM-HANSEN
MUNDO
JACK DUNHAM
NICOLAS VINCENT
CREATIVE STALL
PETR PASASOV
MUSKET
JONATHAN LI
BOHDAN BURMICH
ANBILERU AMALERU
ARTHUR SHIAIN
GREGOR CRESNAR
SHMIDT SERGEI
ICON FAIR
UMESH VGI
UNLIMICON
KARTHIK AATHIS
DAVO SIME
SARA