Project Debt: Recognize and Mitigate Effects

Project Debt: Recognize and Mitigate Effects

Thought Leadership | Princeton Blue

As typical to most new endeavors, we find ourselves urgently seeking short-term goals and immediate turnaround on investment. Management wishes visibility on progress and what better way to show progress then working (hands-on) demonstrations!

The cost of project debt can’t be ignored though on what becomes rapid, short-term iterations. Acknowledging that short cycles yields early truth on vision. Or, a measure of practicality between vision, capabilities, and reasonable expectations. What becomes of projects operating out-of-bounds of safe borders is initial success followed by unsustainable progress (as effort eventually unbalances early gains).

In drawing safe boundaries on practice we’ll take an initial look at the project debt brought on by insufficient investments on infrastructure. I’m thinking in broad terms here – where infrastructure includes:

  • Technologies supporting agile, continuous integration and deployment
  • Skills and know-how supporting necessary capabilities on technologies
  • Desktop development tools
  • Organization and leadership – both own and maintain the course on our project’s end goal.

Project Debt: The Ideal Scenario

Project Debt - The Ideal Scenario | Princeton Blue

Ideally, with a clear path ahead, the project delivers on increasing value alongside effort. Each iteration cycle, though requiring additional effort, delivers on value. Productivity is sustained and supported by our initial investments on infrastructure.

  • Productivity improves with each iteration – demonstrating increased efficiency and sustainable velocity
  • Value reflects effort. There are fewer mistakes and rework required – what is put into the project reflects positively as increasing value.
  • Clear alignment between teams. Increasing value demonstrates positive communication – the team is heading in the right direct as per vision and business needs.

Project Debt: The Unfortunate Scenario

Project Debt - The Unfortunate Scenario | Princeton Blue

Reason yields to impracticality. Per each sacrifice there are costs – and these costs inflate in concert, to bring our once ideal project to its early end.

  • Debt laden infrastructure cannot support growth. Maintenance effort inflates per iteration as re-work, though minor with good management, becomes a major obstacle.
  • Enhancements and additional features become impractical. With loss of agility (via poorly constructed code-base and weak infrastructure), business value falls out of reach – no longer achievable under the burden of growing maintenance overhead.
  • Productivity decreases. The teams are forced to choose between re-writes or the refactoring of risky, unstable code. However, the churning code-base brings on additional maintenance overhead with every version branch. A production release is now impossible as stability falls out of reach.

Project Debt: Mitigation

It’s impossible to avoid project debt because, ironically, perfection simply does not exist. The ideal project will never complete its goals. This is due, in no small part, to the relationship and balance of goals between business, organization, and the individual. Since the ‘ideal’ project represents an unbalanced relationship between these camps (primarily in lack-of-sacrifice), it to will fail – though not on technical grounds…

Simple recognition then, identifying and learning to navigate with a few anchors in the water, is our best method – staying on target with eventual success.

Project Debt - Mitigation

Project Debt: Tactical Considerations

  • Recognize where sacrifice is due.
  • Track cost on project debt so as to more accurately predict progress and manage expectations
  • Manage ‘debt inflation’ by offsetting expectations so as to reduce the negative effects each sacrifice has in relation to its others. For example, attempting unreasonable productivity from an untrained development team will only lead to downstream inflation of maintenance effort (additional debt). Best to reduce productivity early so that, as the team matures, encumbered maintenance debt is kept to a minimum. Maintainable code then provides a path through increasing pressure on delivery as late-project costs are realized (e.g. balancing sacrifice).

Valuable BPM-specific information like this should be shared, no? Share this with your friends and peers. Follow Princeton Blue on Facebook, LinkedIn, Twitter & Google+ to get focused BPM-specific updates.

Leave a Reply

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

Want to Learn More?
CONTACT US