(My first post here!)
If you've been in this industry for any length of time, you've come across failed projects, or perhaps have been stuck on a few yourself. It drives an entire industry of project management tools to keep projects on course, and armies of highly paid consultants to protects businesses from costly mistakes, and in my opinion, a whole lot of snake oil and silver bullets to go along with them.
I've been involved with many, many projects over my career, and I've been lucky to spend time working with some great engineers at a number of companies, who have shared their own stories about what has worked and what has failed. And both my first hand experience and the second hand stories have all led me to the same conclusion.
Software projects rarely fail for engineering reasons, that is anything that is under control of the engineers themselves. The biggest cause of failure is simple communication - the client simply does not understand what they need, or that need isn't being described accurately in the contract and requirements. Usually the dev side will churn along and deliver what was requested, at least requested in writing, but it will not actually deliver on what the client wanted.
The number two cause I've seen, sadly, is plain deception. A company agrees to develop something at an unrealistic price, hoping that they can find a way to renegotiate along the way to cover the actual costs. A variation on this is when a company is being paid to develop the requirements, and then keeps charging to refine the requirements until the project becomes outdated and eventually killed. Even though the development process never started, I still consider it a failure since the client paid, sometimes in the millions, for something they never received.
Opinions and stories welcome!
Top comments (1)
Hi there! It's great to see your first post here.
I completely agree with your insights regarding the significant role that communication and understanding user demands play in project failures. In my experience, I've encountered situations where the requirements for a feature have undergone complete reversals, leading to the need for multiple rewrites. It can be pretty challenging when the client or product team struggles to accurately identify their needs and communicate them effectively. And it leads to frustration and de-motivation among the development team, as they strive to meet changing expectations.
I can't relate to the part regarding re-negotiations related to refinements. But I've seen cases where the marketing/product teams have over-promised without consulting the development teams on the development effort.
I believe it's crucial for all stakeholders, including marketing and product teams, to recognize that software development is a structured process that requires time, skill, and expertise. They must understand that a software developer is not just a code monkey who spits out code in exchange for money.
Overlooking engineering principles and processes can result in subpar projects that may not thrive in the long run. In some cases, they can become a burden for the developers tasked with maintaining them.