The successful Product Manager distinguish competencies
31 August, 2018
Success in software development: When Design Thinking meets Agile
2 September, 2018
This is an open secret. A majority of the software development projects don’t finish as expected. You just need to dive into the web and gather some data we can use easily to endorse my words. Did you know how much money is lost by the European economy each year because IT projects failure? 142 million Euros. 5% of its GDP. In addition, it is globally estimated that 1 of every 6 IT projects has an 200% extra cost and a 70% delay. Even 17% of the projects are performed in such a wrong way they get their own organizations existence at risk. It’s something quite normal then when we say 75% of business executives (and IT) believe IT projects are born condemned to fail from the beginning
According these figures, it’s something reasonable to ask ourselves: How many projects really go wrong? To answer this question, first thing we must clarify then is, what does it mean to go wrong? A quite accepted definition in the software industry would be when these projects meet any of these assumptions: they’re obviously delivered late, over budget, with less than the required functions, they’re canceled before finishing or simply not being used never once delivered.
How many software projects really go wrong?
The second thing we should know is, this is a very difficult question to answer. Our response should be based on data and not over assumptions. So, we will take different studies on customer relationship management systems -or CRMs- develop and implementation projects. The AMR IT consultant estimates 29% from global number are wrong projects, a figure Forrester raises to 47% and Gartner leaves in an enigmatic more than 50%. Others like “The Economist” are even more pessimistic and raise the percentage to a worrying 56%, a figure that Butler Group consultancy increases to an alarming 70%. On a global level and referring to large IT projects, McKinsey consulting firm tries to relax everybody just revealing 66% of software projects are over budget and 33% are above time also.
Once we don’t have any doubt about it, it’s absolutely logical to ask to the experts: What are the problems we find to explain these failure rates? What are the sins we commit to deserve this? Perhaps the best way to understand this is with a wonderful and revealing story.
The software development process: A true 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 where 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 understands John is needing. 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. Tom’s team starts to build the project. And the time goes by again.
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. 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 refreshes 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…
What’s this story secret message? John have got something that is more expensive than he expected, is Long-awaited for everybody, is far from his initial expectations and nobody is going to use it. So, John is going to think twice next time before starting a software project. Most probably, John will be one into the 75% business executives don’t trust in software development.
Now, let’s accept that there’s a strong business case supporting the project, a sponsor behind the project, there are enough developers get access to the right resources, applying right methodologies and using right tools and infrastructure, there are project managers know how to do it conveniently and the fact unicorns exist.
So, if we consider all these cases have been accomplished along the project, what could have gone wrong? Let me be sincere here. We commit sins. All of us.
The software’s sins
Pride
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 requirements list describing 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…
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 drives 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 developer side…
Envy
Frequently we want always what we see in neighbor’s house although we don’t understand what it is 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
Greed
