Managing your technical debt - Convincing your customer
Balancing performance, budget and strategy: a guide to managing technical debt and ensuring the success of your digital projects.
Nobody's against virtue, but when it comes to loosening the purse strings, volunteers take a back seat. Every project has a sponsor, a need and a budget.
How do you get a customer to understand that he has to pay programmers to work on his code without getting any new functionality out of it? Part of a project manager's role is to be the liaison who understands the customer's needs and interprets them to communicate them in a technical way to the developers, but an important facet of this role is also to control costs and ensure that the expected scope is delivered to the customer on time and on budget.
It's the role of the project manager to open the discussion on the application's lifecycle with the customer, especially if the opportunity is given to him by the developers who identify and communicate modules with a technical debt. It's better to have a difficult discussion now than a disaster to deal with later... It's by highlighting the issues at stake that the best (informed) decision can be made.
What we see more often and what makes sense in a LEAN approach3is to maintain a certain amount of leverage. The choice is to maintain debt for the time being, in order to deliver more features more quickly. Whether it's to eliminate a legacy system earlier with its MVP, or to reduce the time to market and thus mitigate risks and test the market acceptance of a new product sooner, or for a proof of concept to convince stakeholders of the relevance and feasibility of the software to go after a larger project budget.
However, these shortcuts, while useful and relevant, should not become the norm. An interesting approach is to plan a contingency, the rule of thumb being to set aside an extra 20% or so in the budget, to slip user stories that address technical debt into the sprints. During the postmortem, we raise the technical debts that have been uncovered, but also celebrate those that have been addressed, as part of a healthy process for a " devX4"quality stories. When we plan the next sprint, we integrate these stories, prioritizing the parts of the code that are core to the software, and in particular those that are difficult to approach and scare off the devs. This is where the greatest gains are to be made, and conversely, there is little point in refactoring stable code or, worse still, unused code.
Displaying this sound governance to the customer will give him confidence that you are not an extremist purist, but rather a supplier committed to the success and longevity of the project, who is keen to make good use of the time and money available to enable him to maximize his investment and achieve his objectives.
An additional argument in favor of taking on technical debt is the importance of a quality architecture to enable us to build on solid foundations. Today, there's an incredible "hype" about AI, with everyone wanting to do something about it to boost their image and avoid falling behind the competition. Even federal5 and provincial governments6 reorient their programs7 to subsidize AI projects to the detriment of other innovation projects.
However 85% of AI projects fail8. As the experts say, to be on the right side of the statistics, you first need to identify the strategic need you're trying to meet, and define the expected ROI. But the second step is to lay solid foundations (performance and scalability of solutions, adapted, resilient and efficient infrastructure, automated and connected systems, quality, filtered and reliable data, single and available source of truth, etc.). These are all examples of potential places to target to eliminate limiting technical debts. Only after you've done all this can you hope to achieve the success you're looking for with your AI project.
What's more, although some of these improvements are back-end and intangible, they will also improve the UX (user experience), not least in terms of the application's performance. In other words, the effort you put into resolving your technical debt should be seen as a first step in the right direction, one that will win the loyalty of your end-users by offering them a fluid, easy and effortless experience that will set you apart from the competition and may even enhance your business model.
2 How to make sure agile projects don't go over budget | KuriosIT
3 10 Years Since 'The Lean Startup': A Product Developer's Perspective
4 Five proven approaches for a better Developer Experience in your organization | Thoughtworks
7 Budget Québec 2025: the government bets on companies specialized in AI - Les Affaires
8 AI, why do 85 % of business projects end in failure? - IT SOCIAL