Project Management

Beware the Dangers of Technical Debt

From the Voices on Project Management Blog
by , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog


View Posts By:

Cameron McGaughy
Lynda Bourne
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Wanda Curlee
Christian Bisson
Ramiro Rodrigues
Soma Bhattacharya
Emily Luijbregts
Sree Rao
Yasmina Khelifi
Marat Oyvetsky
Lenka Pincot
Jorge Martin Valdes Garciatorres
cyndee miller

Past Contributors:

Rex Holmlin
Vivek Prakash
Dan Goldfischer
Linda Agyapong
Jim De Piante
Siti Hajar Abdul Hamid
Bernadine Douglas
Michael Hatfield
Deanna Landers
Kelley Hunsberger
Taralyn Frasqueri-Molina
Alfonso Bucero Torres
Marian Haus
Shobhna Raghupathy
Peter Taylor
Joanna Newman
Saira Karim
Jess Tayel
Lung-Hung Chou
Rebecca Braglio
Roberto Toledo
Geoff Mattie

Recent Posts

The Planning Paradox

Project Management: Talent or Skill?

Project Management Is The Great Equalizer

3 PM Lessons I Needed to Relearn

4 Signs You’re a Micromanager in Your Projects

By Lynda Bourne

Have you ever experienced technical debt on a project? As the debt builds up, everything looks good from the outside. However, when the crunch comes and that debt has to be repaid, a major reversal in fortune can occur.

Technical debt refers to the costs of having to go back and resolve problems that arise because an earlier decision was made to take the easy route, instead of the best one. By taking the easy option, the team incurs a debt to the project that will have to be repaid later. While the concept comes from software development, this insidious effect can be seen across industries.

The Crossrail project in London offers a current, extreme example. In July 2018, it was reported that on-time and on-budget completion of the £14.8 billon rail project would occur in December 2018. By August 2018, completion had slipped by a year. Currently, the delay extends to the end of 2020, with a cost overrun of 20 percent.

What’s the main driver of this delay and associated costs?

It appears to be decisions made to ignore problems in the signaling system development. According to Construction Manager magazine, while giving evidence to a government inquiry, Crossrail’s new chief executive Simon Wright said, “We were testing on incomplete systems. Productivity was under stress, but we fought hard to maintain the schedule and thought all along that we could find a solution to bring it back, just like we have done on countless other problems that occurred during the construction program.”

This is a classic example of management decisions building up a technical debt. 

In 2015, The Independent newspaper reported that rail experts and engineers were having difficulty creating interfaces for the signaling systems. At the same inquiry, Crossrail’s new chairman Terry Morgan said “problems that emerged were mostly due to difficulties with developing software to allow Crossrail trains to travel safely at speed through three separate signalling systems,” according to Construction Manager magazine. The problem was identified in 2015 and hadn’t been resolved by 2019, despite time and money wasted testing incomplete systems. In fact, the irrelevant testing probably added to the delay and costs by distracting people from the real challenge.

Fixing the problem properly the first time would surely have caused a delay and cost blowout between 2016 and 2018. But in all likelihood, the costs would have been lower, the delay would have been shorter, and the current furor surrounding the project would have been minimized.  

The problem with technical debt is that often, the people who need to know about a problem aren’t informed. We will never know what the chair and CEO of Crossrail (both sacked) really knew in the 2016 to 2018 period, or what their senior managers knew about the build-up of the technical debt in the Crossrail signalling systems. But the problem could have been avoided, or at least minimized, if the technical debt had been acknowledged. If people are unaware of technical debt, then they’ll be more likely to identify paths that will result in it being created.

To avoid this lack of insight, everyone in the project group, especially team members, must be in a position to offer insight into technical debt.

The project manager can then choose to act, or not. Aware teams bring up the subject of technical debt in planning meetings, and they keep focused on it. Aware managers pose questions such as, “If this proposed shortcut is the right choice, what is there to gain, and what are the challenges and future implications?”

As with financial debt, there are times when going into debt can be beneficial, but only if you can pay back the accrued debt and interest at the right time.

How much technical debt is your project running? Please share your experiences below.

Posted by Lynda Bourne on: July 19, 2019 07:52 PM | Permalink

Comments (21)

Page: 1 2 next>

Please login or join to subscribe to this item
Thank you for the great post Lynda. I have seen issues with "new" technology or equipment being used on a project for the first that was "supposed" to be cheaper to install, program and install, come back to cause more work and cost than if we had used the"old" equipment that has been time tested and we are experienced with. That is not to say we cannot expand our knowledge and options and offerings, I blame the issues on a lack of proper vetting, testing and research before moving forward with a new offering. Technical Debt sounds a lot like Rework!

The cost of paying off technical debt is definitely extra work Michael, but this is different to quality issues and test/design failures. To look at your example, assuming the 'new' equipment used properly will save time and money overall, but needs proper training which has a short term cost. The type of decision that creates technical debt is the one that says to stick with the 'old' equipment to avoid the short-term consequences, and change over later. The production work is slower and more expensive ad you still have the cost of the changeover and training at a later stage (plus possibly a lot of additional costs changing out the old equipment and re-configuring other parts of the system to work with teh 'new' replacement. A short-term 'win' but an overall disaster.

Wonderful article and very relevant. Decision made on short term goal ignoring long-term effect on cost and time is always dangerous for overall project successful. You have nicely highlighted this issue by taking crossrail project. If problem is known, we should fix it first time effectively without any delay. We should not think over short-term goals while taking decision.
Thank you Lynda for valuable suggestions !!

Thanks, for sharing that story, Lynda. Stark reminder of the ripple effect of these decisions. Only so much can be swept under the carpet until there's a big lump and everyone is tripping over it :)

Great article Lynda. Technical Debt can be detrimental to projects if it accumulated until it reaches to a stage where there is no turning back point without extreme losses. As Andrew mentioned, such decision has a ripple effect.

Great Article Lynda. I do agree with you and there are so many projects with technical debt incurred. It comes down to doing the right thing that taking the easy option. It takes courage, authenticity, care and a blame proof environment to to get to the point. thanks for sharing your insights

Great article. Thank you for sharing this. This sound to me strange that management was not aware if proper risks & issues managements was in place. This should have been logged with relevant potential impacts and as this is so huge, I guess that management should have been made aware of it on the first day or when meeting agreed impacts threshold.

Almost 20 years ago, I’ve been facing a technical debt when the team wanted to use open source software libraries. This was quite convenient, cheaper than make or buy options and available right now. However, after some time, when going deeper with licensing, we found out that this was potentially creating an issue. We decided then to switch to some commercial product. This had a little impacts for design upgrade and code modifications as we were not too far on the product development cycle. This was a wrong choice and a good lesson.

Did I later sign for technical debt? Yes indeed, when, on the constraints triangle, cost increase were more acceptable than missing an intermediate milestone. What remains to me important is that this is properly documented (impacts, costs, schedule), shared and approved.

Good point Emmanuel, one of the unanswered questions is who knew what, and when they knew it. When the UK gets over Brexit there may well be a more in-depth inquiry.

A great thought-provoking article. Maybe another causal aspect to technical debt: "blind" escalating commitment.We get so caught up with "meeting" targets that were sold to our principals so we either lose the professional courage to speak up for fear of being shut down; or we don't want to be the ones to scupper the project by actively raising the challenges and what it takes to resolve them at the right time; or we somehow imagine the problems will go away or resolve themselves...

A valuable reminder of technical debt's dangers but unfortunately is widely prevalent. The reason almost always seems to be due to lack of integrity or not willing to take the responsibility when issues come to light. Quick wins and selfish motives push it under the rug for someone down the road to bear the brunt of the impact. As the article highlights, the negative impact on cost and schedule is far bigger and much difficult to recoup the losses when remediation is delayed.

Thank you, Lynda. This is enlightening. I recall seeing Crossrail as a celebrated project -- I think it was PM magazine that highlighted it. A number of big programs [read boards and CEOs] in industry make bets on technical debt and lose. How much different would the outcome be if the Crossrail chair and CEO had notified the project sponsor (ultimately, the British Government) of the risks, provided they were correctly assessed, we can only speculate. While you highlight the signaling systems, are there other deliverables that are at risk of causing significant delay?

Excellent article, Lynda,thank you for sharing

HI Jose, you are right of course, but the concepts I wanted to separate is the difference between problems of the organization's making (technical debt) and the occasional immutable issue that just has to be worked through. Bond St station in the middle of Crossrail which won't open until 2022 - but this delay was primarily caused by engineering issues and the chronic lack of access constrains the ability to accelerate the work - the workaround is designing the platforms to allow trains to run while the building works continue. Big projects carry big risks - this was one of them.

Great concept

Interesting points. Thanks.

Amazing read, thanks for sharing

Our legacy systems have High complexity which leads to more time spent in maintenance activities. No clear good architectural vision, loss of knowledge over a period of time and lack of up to date Tests and lack of documentation for the enhancements/fixes are some of the contributing factors for increasing complexity.

Good example BinRu - someone has to pay off the technical debt sooner or later, but it is not necessarily the people who crated it.

Page: 1 2 next>

Please Login/Register to leave a comment.


"Put all your eggs in the one basket and - WATCH THAT BASKET."

- Mark Twain