Why Most Software Projects Fail and How to Avoid It
I have been working with different software companies for over six years. From financial software companies, which focus on their own products, to software agencies, which build and maintain different projects for different industries and also worked as a freelance developer and have had my own clients.
Throughout all of those years experience, and in every one of the companies I have worked for, there is a pattern that always repeats itself.
Developers seem unable to properly collaborate with product people or the client directly.
However, whilst I was working as a freelance developer, something changed. Sure, at the beginning it was the same pattern, a list of features/tasks, and a deadline, but the more I met with a client, the more I understood their business and more importantly, the more I understood their brand.
The greater engagement I had with a client, the greater the opportunity to discuss and question certain features, measure the user impact, suggest other ideas, and in general, improve the quality of the overall product and fix the user’s pain points. Soon, we were able to forget about dates and focus on the product itself.
I would work together with the client and we would come up with many great ideas and the project would end up being extended, and yes, that can be chaotic from a corporate standpoint.
We moved dates!!!
We changed requirements, we changed the initial contract and we signed off on a new contract but the product was a success, the client was extremely happy and I believe, in the end, that was the real goal.
Had I done what I was asked for initially, the product would have missed out on a huge amount of value. Our job is not to do what we are told to do, our job is to create something that solves problems.
“Be stubborn about your goals but flexible in your methods” — Unknown
The problem with Software companies
When a developer talks to a client, they tend to be defensive, especially when it comes to receiving feedback. Everything the client says is treated as a threat and disagreements often occur. Developers seem reluctant and/or unable to collaborate…
Why is this?
Many circumstances seem to pit developers and clients against each other, making them enemies rather than allies. I believe the main reason for this behavior is that from the beginning of a project, developers are only given the requirements and the deadline. They then have to complete the tasks in a set amount of time in order to receive their payment.
That’s okay, but it’s not surprising why developers act defensively if the client starts to give feedback in an early review session and then complain that it didn’t reach the goal/revenue the company had expected, which is information that the developers were not made aware of before or during the development stage. If the client then suggests a solution, the developer feels threatened and may also be wary of missing upcoming deadlines.
Software development is rarely a streamlined process, from the initial idea up to the creation of a product there are many iterations, pivots and changes in between that you only get to see when you are in the development/building process
Developers may lie about feasible solutions depending on how much time it takes to build vs the value of the feature. They may say that a certain feature is impossible to create, refraining, and limiting themselves from even thinking of ways to make it possible. They will make excuses and provide the quickest and effortless solution possible.
Client/developer relationships are based on money, fear and necessity. The client provides a contract with the job specifications and developers work to fulfill the contract in order to get paid. When an issue arises (because, let’s be honest, they always do), developers will prioritize the deadline and the money thus creating a barrier between the two parties stagnating collaboration. In this way, the client will be the only one who cares about the product and the only one providing any valuable ideas and insight.
Meanwhile, the developers’ concerns are the missing-of-deadlines, coming under scrutiny from their boss and/or possibly getting fired.
As developers, we are sometimes unable to think outside of our current task in order to see how it connects to the vision of the product, we do only what we’re asked, we follow the specifications but we never think more than that. Even if we identify that the given specification may not be the best solution and could possibly cause other problems in the future, we are afraid to speak out because it will have a detrimental effect on our ticket completion rate. And after all, that’s how our performance is measured right? By how many tasks we complete?
Available options for developers:
1. Complain about the description of the proposed solution and work together to propose a better one.
Output:
- Zero tasks got completed
- Uncertain results
2. Solve the current task and do not ask questions.
Output:
- Receive the boss compliment
- The task got completed
- Kept the ticket/task completion rate high
- If issues come up later, they would be the client’s fault
Let’s consider a different scenario
From the start of the project, developers are included in business discovery. Clients and developers brainstorm ideas that bring value to the product and users. Developers are the tech experts and with no deadline discussed yet, everyone will feel free and dare to talk about crazy ideas, even if they have not done it before or think it would be difficult to build. A true collaboration will happen and everyone will be thinking about features and ways in which they can deliver the user the best possible product and experience.
After the discovery stage, developers will estimate how much time it will take to build each feature and the client will prioritize and choose which features give the most value to the user and/or will bring more revenue to the business. A deadline will be set and agreed upon between all parties, creating a commitment and alignment, everybody is invested.
With the latter approach we achieve:
- Everyone is on the same page
- Every opinion counts, everyone is part of the team and belongs to something big
- The developer’s mindset is no longer to complete the ticket or make the grumpy client happy. Everyone understands the big picture and will collaborate to make a great product
- Everyone is committed to the same, pre-agreed goal
- Everyone understands the business and what the key metrics are
- There’s a clear picture of what project success looks like
- When issues come up developers understand the whole picture and can be honest, suggest more creative, innovative ideas, ideas that may or may not fit in with the current deadline
When everyone knows the “why” and understands how the business works, everyone will go the extra mile together and truly collaborate to make the impossible possible.
At the end of the day, the client will fumble and re-prioritize tasks if needed, but the end goal is no longer to complete the task and get the monthly check on the table. The goal is now to make a great product, make the client’s demographic happy and make the business grow.
All of that will reflect in the success or failure of the product when we focus on the right goal, if the product user is happy, the MVP will bring in enough revenue, more features will come up, a new contract will be signed, ideas that were left behind due to time will be relooked at, more brainstorming with developers, final tweaks and amendments will be made. With everyone working together as a team with a clear mission statement, the results will be better, more targeted and refined products.
The bottom line:
- Hire people driven by passion
- Build awareness and empathy including the team in product discovery
- Make everyone feel they belong to something big, keeping the team engaged and excited about the people they impact and help, keep the vision alive in your team
- Build team empathy with the clients demographic, foster human connection, if possible meet the prospective users in person
- Celebrate small wins
- Be open and clear
- Prefer over-communication over poor communication
- Build trust
- Clearly define what success looks like for the developer role, Do not only measure ticket completion rates but how many times this person helped others, raised red flags or unforeseen blockers, etc.
- Make it easy for the team to collaborate/help each other
- Build an environment where people see failure as an opportunity to learn, grow and get better, this will promote creativity and fresh ideas
- Build different motivators at work other than simply “something I do to get paid”
- Invest in the Company Culture, Culture is the key in making employees feel like they are part of a family to create a sense of belonging
- When unforeseen blockers occur, outline tradeoffs, be honest with the client about available solutions and together reprioritize the backlog
There’s always an invisible barrier that divides developers from clients, stopping them from truly collaborating as they aim towards different goals, the solution, of course, is to align our visions and merge our goals so that we move forward together as a single unit, with a common purpose.
Like the content? Get my latest articles in your inbox! (Once a month email).
