Download to read offline
Uploaded byDaniel Cardelús
Software projects can go well... ask me how
The document discusses the high failure rates of software projects, citing statistics that reveal significant cost overruns, schedule delays, and project cancellations. It illustrates a scenario between a CTO and a software company to highlight common pitfalls in project management, such as miscommunication and lack of user involvement. The text advocates for a user-centered, iterative approach to software development, emphasizing empathy, prototyping, and continuous validation to mitigate risks and enhance success.
More Related Content
![[DevDay2019] Lean UX - By Bryant Castro, Bryant Castro at Wizeline](https://cdn.slidesharecdn.com/ss_thumbnails/bryantcastro-43ddopresoleanux-190416065313-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Software projects can go well... ask me how
Software projects can go well... ask me how
- 1. Software projects cango well… ask me how Dani Cardelús - 2016
- 2.
- 3. 142.000M€ is losing everyyear 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 andIT 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 ITprojects 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 projectsgo 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 projectsgo wrong?
- 8. “Go wrong” means: Projectsare “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 CRMsystems 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.
- 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.
- 19. Let me tellyou a story…
- 20. JOHN IS THECTO OF AN IMPORTANT DEPARTMENT INSIDE A LARGE CORPORATION MANY PEOPLE REPORT TO HIM DAILY, CONFESSING HUNDREDS OF COMPLAINTS AND POTENTIAL IMPROVEMENTS
- 21. HE WANTS TOMAKE AN IDEA COME TRUE OR JUST TO SOLVE A PROBLEM HE THINKS SOFTWARE CAN HELP AND PUT ASIDE SOME MONEY…
- 22. TOM HAS ACOMPANY PLENTY OF SOFTWARE “EXPERTS” DEDICATED TO BUILD SOFTWARE PROJECTS HE BELIEVES CAN HELP JOHN
- 23. JOHN AND TOMHAVE A MEETING… JOHN EXPLAINS WHAT HE WANTS AND TOM GATHER THE PROJECT “REQUIREMENTS” AS ALWAYS DO
- 24. TOM PREPARES ATECHNICAL AND ECONOMIC BID TAKING AS A BASIS WHAT HE UNDERSTAND THAT JOHN NEEDS AFTER A HARD NEGOTIATION, THEY REACH AN AGREEMENT
- 25. PRIOR TO WRITEA CODE LINE, TOM’S TEAM SPENDS A LOT OF TIME DETAILING WHAT THE PRODUCT SHOULD DO AND THE TIME GOES BY…
- 26. TOM ASKS JOHNTO 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 TIMEGOES BY… TOM’S TEAM STARTS TO BUILD THE PROJECT
- 28. AFTER FEW MONTHSAND 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 LONGTIME 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 THATTHERE ARE MANY THINGS FAR FROM HE EXPECTED AND ASKS TOM TO CHANGE THEM
- 31. AFTER SOME MINORCHANGES, 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 LOTOF CUT AND THRUST, BOTH AGREE TO STOP THE PROJECT AT THE LEAST EVIL POINT FOR JOHN
- 33. WHEN JOHN SHOWSTHE 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.
- 35. John have gotsomething that… More expensive than he expected Long-awaited for everybody Far from his initial expectations Nobody is going to use it
- 36. John is goingto think twice next time
- 37. Now, let’s acceptthat…
- 38. There’s a strongbusiness 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 goeswrong?
- 40. How the customerexplained 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 commitsins…
- 42.
- 43. Frequently we thinkfor 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.
- 45. Frequently we tryto 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.
- 47. Frequently we don’tknow 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 TOKNOW 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.
- 50. Frequently we wantalways 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.
- 52. Frequently EVERYBODY wantsALL 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 itshould be luxurious…
- 54. … becomes pureanger
- 55.
- 56. Which are thekeys to find the right solution? These are…
- 57. It should exista 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 ENDUSER 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 unsubstantialchats 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 aboutdialog 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 TIMEAGAIN 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 LEVERAGECOLLECTIVE 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 INA 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 theway 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 usersand 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.
- 73.
- 74. COLLECT ANALYZE DESIGNBUILD BUT HERE ALL CHANGES… Option 1: “As usual”… …but unfortunately we know the results
- 75. Option 2: Anew vision
- 76. When DESIGN THINKINGmeets AGILE Discover, define and ideate Prototype and test Build and deliver (without changes)
- 77. Ok then, but… Whichare the benefits?
- 78. We cover allthe bases
- 79. Even though wecould 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 itsfuture usage
- 81. Result is somethingfruit 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 andvalidate with users… … reducing development time and changes risk These are traditionally the most time consuming phases in a software project
- 84. But watch out… Ifwe 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 firstto confess his sins?
- 86. thanks for yourattention
- 87. 20 years dedicatedto 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.
- 89. IMAGES / CREDITS HTTP://THENOUNPROJECT.COM/ JAVIERCABEZA 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