Why software delivery teams don’t meet deadlines – and why that’s ok?

Let’s face it, in software development, deadlines are missed. VERY often. Does this mean that the team can’t handle the scope or that the project manager is poor at estimating? Not really. Platinum Software Development, a global company with 1000+ satisfied clients in its portfolio, believes that there is a choice to make between high-quality but time-agnostic software delivery and deadline-driven production… The first option should be your go-to choice. And here’s why.

Reasons for failing deadlines

  • Engineers have to learn over and over

The IT sector is advancing every day. There are hundreds of specializations, over 700 programming languages, frameworks and platforms, each suitable for different tasks. Today’s innovations can quickly change, become ‘legacies’ or die by tomorrow. That’s why developers, testing engineers, solution architects and other tech professionals have to constantly learn, refresh their knowledge, improve their competencies and hone their skills.

As a result, up to 30% of engineers’ working time isn’t spent on primary tasks such as coding, maintaining the code or testing; it is spent on studying technologies, tools and system documentation. 

In the case of up-to-date technologies and frameworks, the learning process isn’t that difficult. But imagine that your client wants a solution running on the legacy platform and its15-year-old code, with no relevant documentation. The engineers would have to dig much deeper and spend time exploring the old stack. 

In fact, there are no A to Z specifications that will eliminate all questions and predict all possible errors or challenges. Programming is a creative process and each task resembles artwork – it’s unique. 

  • There is much unknown

Modern software is not simple, nor out-of-the-box. Clients require complex and non-trivial solutions that feature APIs, microservices, various programming languages and frameworks. 

To architect the product and deploy it within a certain timeframe, the delivery team needs to know all the requirements, peculiarities and limitations of the business, as well as to get a clear understanding of the solution’s future. How will the service upgrade? What number of users will there be? What functionality is going to be added? All these questions should be answered before the development kick-off – at the discovery stage. 

Deep research doesn’t end here. Before implementing a solution, the project team and the stakeholders have to be sure that the particular hypothesis is correct and that the product built upon it will bring business value. So, developers write prototypes and test solutions to determine the best choice. If the prototype works and the client is satisfied, the team can take it further. If not, the cycle will need to be repeated. 

  • Let’s add this… and this…

If the development team is building cutting-edge software, it’s often hard to cover and specify all the features of the end product during the discovery and estimation phase. As a result, engineers deal with piling up, ad-hoc requests and out of scope tasks. 

When on-the-fly, requirements are dictated by changes in business, product, security, or legalities that cannot be ignored – the production team will have to implement them, replanning activities and shifting deadlines.

  • We are humans

The delivery success is based on the three C’s: communication, collaboration and coordination, which are impossible without comprehensive human involvement – 57% of projects fail due to breakdown in communications, according to this study.

Were the developers not given requirements on time? Did the customer hire a new product owner who lacked the expertise to make appropriate decisions? Or maybe the key stakeholder is simply in a bad mood today. Such things happen, inevitably affecting productivity, performance and timeframes.

Don’t track time – track value

The reality is that there is almost zero chance of meeting deadlines and sticking to the roadmap 100%. The world’s top games such as CyberPunk 2077, Battlefield and Resident Evil went live far behind their initial release dates. This is just as true for large blockchain projects – EOS, Tezos, Ethereum 2.0 and many, many more. Nevertheless, failing the deadline did not prevent these projects from becoming successful.

You shouldn’t build fast, you should build an outstanding product that brings value to the clients and multiplies their business. It’s the key aspect of software delivery. 

This is where the dateless and value-based approach comes in, focusing on robust functionality and quality, rather than time-tracking. 

Don’t be misled by the word ‘dateless’. It doesn’t mean that the team will have years to roll out the solution. On the contrary, engineers have even more responsibility and accountability because they must stick not to the final launch date but to scheduled regular product iterations. Agile, sprints, continuous delivery, release trains – all these describe a dateless approach. 

In general, it looks like this:

Pilot Version 1.0 > …Next Version 1.1 > …Next Version 2.0 > …Future Versions. 

To hit success with the dateless delivery, it’s essential to embrace the formula of ‘prioritization, planning and synchronization’. In cooperation with the client, the team should define which features are targeted for which release and then work towards this goal. 

What makes dateless delivery a better choice? The client will receive a working pilot version with basic functionality for presentation to its target audience (users, investors, etc.) – relatively quickly. With each regular iteration, the product will evolve further, acquiring new features and enhancements. Moreover, the release train model helps timely and quick response to critical ad-hoc requirements, without causing team overloads and burnouts.

In leveraging value-based delivery, there won’t be questions about whether the change will be implemented or not. The question will be WHEN – in this version or next month’s. 

To be an engineering company that cares for customers and helps them accelerate their business, you should always choose quality over quantity. No one needs software that’s developed on time if it doesn’t work, nor address business pain points. Commit to delivering software when it’s ready to go live, instead of when it should go live.

Related Post

Leave a Reply

Your email address will not be published. Required fields are marked *