software projects can go well... ask me how
TRANSCRIPT
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
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
1 on 6IT projects have a cost overrun
of 200% and a scheduleoverrun of almost 70%
Source: Harvard Business School - Why Your IT Project May Be Riskier Than You Think, 2011
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
“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
Source: McKinsey - Delivering large-scale IT projects on time, on budget, and on value, 2012
66%of software projects with cost overrun
Source: McKinsey - Delivering large-scale IT projects on time, on budget, and on value, 2012
33%of software projects with schedule overrun
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
HE WANTS TO MAKE AN IDEA COME TRUE OR
JUST TO SOLVE A PROBLEM
HE THINKS SOFTWARE CAN HELP AND PUT
ASIDE SOME MONEY…
TOM HAS A COMPANY PLENTY OF SOFTWARE
“EXPERTS” DEDICATED TO BUILD SOFTWARE
PROJECTS HE BELIEVES CAN HELP JOHN
JOHN AND TOM HAVE A MEETING…
JOHN EXPLAINS WHAT HE WANTS AND TOM
GATHER THE PROJECT “REQUIREMENTS” AS
ALWAYS DO
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
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…
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
AFTER FEW MONTHS AND SOME INSISTENCE, JOHN GETS TO HAVE A PRESENTATION OF
PROJECT’S ADVANCESHE DOESN’T UNDERSTAND WELL WHAT
HE’S SEEING. BUT HE’S STILL
CONFIDENT ABOUT HE’S GOING TO
OBTAIN WHAT HE’S ALREADY PAYING
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
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…
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…
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
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
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?
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 insteadto say what’s the problem
Software “experts” believe also they have whole truth for every problem. And it’s not true…
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
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…
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…
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
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
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 REASONAND A SPONSOR
2FOCUS ON END USERAND 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
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 THINGSBEFORE WE TAKE A LEAP OF FAITH
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 WELLNOT ONLY A SIMPLE REGISTRATION
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
6MAXIMIZE CREATIVITYAND 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
7CREATE VALUE IN A AGILE WAYLet’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
Paso 1 – Discovery and empathy
Who’s really my user?What matters to this person?
What’s his behavior?
Paso 3 – Ideate
What can I think to cover these needs?
How can I get out of the general rule and be disruptive?
Paso 6 – Build
How can I provide value as soon as possible?
How can I assure the quality during the process?
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……
COLLECT ANALYZE DESIGN BUILD BUT HERE ALL CHANGES…
Option 1: “As usual”…
…but unfortunately we know the results
When DESIGN THINKING meets AGILE
Discover, define and ideate
Prototype and test Build and deliver (without changes)
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
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
We prototype and validate with users…
… reducing development time and changes risk
These are traditionally the most time consuming phases in a
software project
�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
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
IMAGES / CREDITS
HTTP://THENOUNPROJECT.COM/
JAVIER CABEZAVICONS DESIGNLORENA SALAGRE
CHISTOPHER HOLM-HANSENMUNDO
JACK DUNHAMNICOLAS VINCENT
CREATIVE STALLPETR PASASOV
MUSKETJONATHAN LI
BOHDAN BURMICH
ANBILERU AMALERUARTHUR SHIAIN
GREGOR CRESNARSHMIDT SERGEI
ICON FAIRUMESH VGIUNLIMICON
KARTHIK AATHISDAVO SIME
SARA