How to pre-empt tech debt pitfalls for your software development projects

Any digital transformation and software development project carries risk. And when it comes to tech debt, the risk comes not only from the technology, the code and the architecture of a system; but also from your people. Especially if your software was developed in-house by a small team that have been there from the beginning.

There are certain pitfalls that are sure to derail your digital transformation project but you can avoid these risks altogether with these three guiding principles:

1)    Be open to a done-with-you approach to bespoke software development

The ‘over the fence’ approach is by far the biggest mistake we see people make. This is where a client selects a partner and then says “You’re the supplier and we’re paying you, so please go off and do this for us, and tell us when it’s done.”

In some industries, this approach is useful(necessary even) but when it comes to transforming your tech debt, this hands-off style won’t get you the results you need.

Your software development partner needs to be fully embedded in your company, as an extension of your team. The knowledge and history that you and your teams have, is critical to getting under the skin of your business to create a comprehensive plan that will guarantee delivery.

The components of a done-with-you approach:

• A true, mutually-respectful partnership
• Involvement and time from you and your team
• Unrestricted access for your software development partner

‍

2)   Set realistic expectations for your software development team

As a leader, you’re under pressure to deliver. But if you’re unrealistic, you won’t achieve your plan and you’ll break people and processes in the process.

Implement this simple three-step process to bring everyone on board:

• Be realistic about cost and time. Involve developers, get their ideas and inputs and bring them on the journey with you
• Set crystal clear milestones to ground everyone’s expectations
• Hold people accountable to what they’ve committed

It may sound simple, but we’re frequently asked to rescue a failing project where developers don’t know what they’re working towards, haven’t been consulted about the project goals and outputs aren’t tracked and managed.

3)    Plan for consistent delivery

Delivery should be agile and consistent so you avoid a big ‘reveal’ at the end of a software project. We recommend using an agile methodology and a delivery cadence every 2weeks. Ideally, there should be no more than 4 weeks between deliveries in order to create a consistent rhythm of ‘show and tell:

• Aim for agile and consistent delivery
• Avoid a big ‘reveal’ at the end of a project
• Deliver something every 2- 4 weeks (max)  
• Change the deliverable to fit the time rather than extending the time

Of course, you may get push back from team members.If this happens, change the task and make it doable within a sprint instead of allowing additional time. This avoids team members getting out of their depth or being unable to balance their workload. Because long stints without delivery have a tendency to snowball, with problems getting bigger and eventually leading to a crash.

Adopting a done-with-you approach, setting realistic expectations and planning for consistent software delivery will help you manage risk so you deliver on time and in budget.

Want to guarantee project delivery?

Book a call with one of our software development specialists to find out more about our Discovery process which guarantees on-time and in-budget delivery.