PMP® in Action (Part 10): The Morning After – Managing Technical Debt

Section 1: The “Band-Aid” Solutions Come Home to Roost

The Canadian launch was a success, but as Kapil Mehta walked into the 7Pro office on Monday morning, the “Victory Cake” in the breakroom felt like a distant memory. While the monitoring dashboard was green, the Technical Debt Log was deep in the red.

“Kapil,” Mohd Tariq said, pointing to a stack of code reviews. “To meet that ‘Hard Deadline’ for the launch, we took several shortcuts. We used hard-coded configuration strings for the Quebec servers, and we bypassed the automated regression suite for the mobile CSS. We called them ‘temporary fixes’ in Sprint 8, but now they are becoming permanent problems.”

Kapil sighed. This was the classic PMP struggle: the trade-off between Schedule and Quality. By fast-tracking the launch to satisfy Tim John, they had accumulated “Technical Debt”—interest that the project would eventually have to pay back.

“If we don’t ‘refactor’ this code now,” Tariq warned, “the system will become too brittle to handle the Phase 2 expansion to Europe. We’re essentially building a skyscraper on a wooden foundation.”


Section 1 Breakdown: The PMP & ITIL Lens

  1. Technical Debt: The cost of additional rework caused by choosing an easy (fast) solution now instead of using a better approach that would take longer. It is an internal Project Risk.
  2. Refactoring: In Agile, this is the process of restructuring existing computer code without changing its external behavior. It is essential for maintaining “Code Health” and agility.
  3. Balance of Constraints: Kapil is managing the Triple Constraint. He sacrificed Quality (temporarily) to meet the Schedule. Now, he must use Resources and Time to restore that Quality before the next phase.

Section 2: The “Feature vs. Fix” Stakeholder Battle

With the Canadian users active, Jason Vance (New Orleans) was already pushing for the next big thing. “Kapil,” Jason’s voice boomed over the morning call, “The feedback from the Toronto pilot is great, but we need to move the Phase 2: Europe Launch forward. I want the Euro-currency support and the ‘Smart-Wallet’ features in the next Sprint. We need to keep the momentum!”

Mohd Tariq leaned into the microphone. “Jason, we have a significant amount of Technical Debt from the Canada cutover. If we pile ‘Smart-Wallet’ code on top of the hard-coded strings we used as a ‘temporary fix’ for Quebec, the system will become unstable. We need at least one full Refactoring Sprint before we touch the European scope.”

Jason scoffed. “Refactoring? That sounds like internal housekeeping. The investors don’t pay for housekeeping; they pay for features. Can’t you just ‘fix it on the fly’ while building the new wallet?”

Kapil intervened. “Jason, think of it as Preventive Action. In PMP, if we don’t address these quality issues now, our Cost of Quality (CoQ) for the Europe launch will triple. We aren’t asking to stop; we are asking to ‘Harden’ the system so it can scale.”


Section 2 Breakdown: The PMP & ITIL Lens

  1. Preventive Action: An intentional activity that ensures the future performance of the project work is aligned with the project management plan. Kapil is arguing for prevention over future “Internal Failure.”
  2. Cost of Quality (CoQ): The total cost of all efforts to achieve product quality. This includes Prevention Costs (refactoring) versus the much higher Failure Costs (system crashes in Europe).
  3. Conflict Management (PMP): Kapil is using Smoothing/Accommodating initially by acknowledging the success, but moving toward Collaborating/Problem Solving by explaining the long-term technical reality to Jason.

Section 3: The “Refactoring Sprint” and the Definition of Done

After a heated debate, Kapil secured a compromise: a 10-day “Hardening Sprint.” No new features for the “Smart-Wallet” would be coded. Instead, the team would focus entirely on paying back the Technical Debt from the Canada launch.

“This isn’t a vacation from development,” Mohd Tariq told the team during the Sprint Planning. “We are updating our Definition of Done (DoD). For this sprint, a task isn’t ‘Done’ just because the code runs. It’s only ‘Done’ if it passes the new Automated Regression Suite and the hard-coded strings are moved to the global configuration file.”

Shakira looked at the backlog. “We’re essentially cleaning the kitchen while the restaurant is still serving customers. Since the Canada app is live, we have to refactor the database schema without a single second of Downtime.”

This was a high-wire act of Change Management. They weren’t just fixing old code; they were ensuring the Service Level Agreement (SLA) of 99.9% uptime was maintained while they “swapped the engines” of the plane mid-flight.


Section 3 Breakdown: The PMP & ITIL Lens

  1. Definition of Done (DoD): A shared understanding within the Agile team of what it takes for a requirement to be considered complete. Adding “Code Quality” to the DoD prevents future Tech Debt.
  2. Service Level Agreement (SLA): An ITIL concept. It’s a formal agreement between a service provider (7Pro) and a customer (QT Money) about the expected level of service (e.g., Uptime).
  3. Harden Sprint: A sprint dedicated to improving the stability and quality of the product rather than adding new functional value.

Section 4: The Outcome – A Scalable Foundation

By the end of the 10 days, the “Hardening Sprint” was a success. The hard-coded “Band-Aids” were gone, the automated tests were covering 85% of the codebase, and the system was finally ready for the European “Smart-Wallet” expansion.

“We lost 10 days of feature development,” Kapil wrote in his weekly status report to Tim John, “but we gained a 40% increase in System Reliability. We have effectively lowered our future Cost of Quality for the entire European rollout.”

The “Morning After” the launch wasn’t about champagne; it was about the discipline to fix the foundation before building higher.


Section 5: Summary – What Did We Learn?

  • Launch is Not the End: The period immediately following a Go-Live is when Technical Debt is most dangerous.
  • Advocate for Quality: A Project Manager must sometimes say “No” to new features to protect the long-term health of the product.
  • Prevention is Cheaper than Failure: Using the CoQ (Cost of Quality) model helps convince stakeholders that “housekeeping” is actually a financial investment.
  • Update the DoD: As the project matures, the Definition of Done must evolve to include higher standards of testing and documentation.

Leave a Reply

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