Software projects can go well... ask me how

Software projects can go well…

ask me howDani Cardelús - 2016

NUMBERSAND FACTS

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

Then...

How may projects go wrong?

“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

Let’s take CRM systems for instance…

29%

Source: Virginia University – Coursera “Agile meets Design Thinking”, 2016

47%


More than50%


56%


70%


Globally…


66%of software projects with cost overrun


33%of software projects with schedule overrun

PROBLEMSAND SINS

Let me tell you a story…

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

AND THE TIME GOES BY…

TOM’S TEAM STARTS TO BUILD THE PROJECT

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

JOHN DISCOVERS THAT THERE ARE MANY

THINGS FAR FROM HE EXPECTED AND ASKS

TOM TO CHANGE THEM

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…

AFTER A LOT OF CUT AND THRUST, BOTH

AGREE TO STOP THE PROJECT AT THE LEAST

EVIL POINT FOR JOHN

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…

Secret message

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

John is going to think twice next time

Now, let’s accept that…

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

So…

What can goes wrong?

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?

All we commit sins…

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…

Gluttony

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

Laziness

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

And what it should be luxurious…

… becomes pure anger

SOLUTIONSAND PENANCES

Which are the keys to find the right solution?

These are…

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

And what’s the way to overcome any obstacle along

the path?

This is…

Paso 1 – Discovery and empathy

Who’s really my user?What matters to this person?

What’s his behavior?

Paso 2 – Design

Which are the user needs?

Which are their insights?

Paso 3 – Ideate

What can I think to cover these needs?

How can I get out of the general rule and be disruptive?

Paso 4 – Prototype

How can I show my ideas?How can I prototype as “high

fidelity” as possible?

Paso 5 – Test

What worked?What didn’t?

How can I adjust it?

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……

BENEFITS

Two options…

COLLECT ANALYZE DESIGN BUILD BUT HERE ALL CHANGES…

Option 1: “As usual”…

…but unfortunately we know the results

Option 2: A new vision

When DESIGN THINKING meets AGILE

Discover, define and ideate

Prototype and test Build and deliver (without changes)

Ok then, but…

Which are the benefits?

We cover all the bases

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

We guarantee its future usage

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 reduce time… and money

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

Who’s the first to confess his sins?

thanks for your attention

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

[email protected]

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

Software projects can go well... ask me how

Software

Transcript of Software projects can go well... ask me how