An Introduction to the Cost of Change and Technical Debt

Mike Griffiths is an experienced project manager, author and consultant who works for PMI as a subject matter expert. Before joining PMI, Mike consulted and managed innovation and technology projects throughout Europe, North and South America for 30+ years. He was co-lead for the PMBOK Guide—Seventh Edition, lead for the Agile Practice Guide, and contributor to the PMI-ACP and PMP exam content outlines. Outside of PMI, Mike maintains the websites www.LeadingAnswers.com about leading teams and www.PMillustrated.com, which teaches project management for visual learners.

SHARE
Request to reuse this
Add to my favorites
Topics: Agile, Applications Delivery, Estimating, Information Technology, Manufacturing

Problems seldom get better by letting them fester, whether it is tidying a cluttered room or fixing a rusty car. In software projects, the costs associated with fixing defects typically increase the longer we leave them, following a cost of change curve as shown below:

The curve shows that the longer a defect is left unaddressed, the more expensive it will be to fix. There are a number of reasons why the cost of fixing a problem increases over time, but two of the key factors are:

Over time, more work will have been built on top of the error or problem, so that more work will need to be undone to fix it and then redone again.

The later in the development cycle, the more stakeholders will be impacted by the defect. Fixing an error when it is just a specification might just take a minute; when it has been coded, tested and rolled out to thousands of users, the cost of a fix and redeployment can be very expensive.

In the early days of agile, people argued agile methods resulted in flat (or flatter) cost-of-change curves. This argument has largely been dropped now; instead, it is agreed that agile approaches help drive teams lower and more to the left on the curve. Agile methods focus on frequent verification and validation--both through active stakeholder participation (such as modeling, demonstrations and reviews) and through XP-inspired development practices (…

Please log in or sign up below to read the rest of the article.