The Reality of Project Management Debt: What It Is and How To Avoid It

Have you ever taken over a project and realized you don’t know where to find the SOW or deliverables at all?

What about all those times you’ve picked a project back up after launch to add a feature and had to do your best impression of Sherlock Holmes to dig out what went down on the project before it launched?

If you’ve experienced these things, then you’ve experienced project management debt.

The idea of content debt and technical debt are decently well-known in the world of web projects.

Technical debt refers to the extra work that builds up as a result of code that’s implemented due to the ease (in time or practice), rather than implementing the overall best solution.

Content debt is similar—often less apparent than technical debt (as it may not cause a piece of software to break outright), content debt is a result of content that is poorly created, nonexistent, out of date, duplicated, out of alignment with current standards or processes, or content that has outgrown its container.

Poor development or maintenance processes, outdated code or content, and difficulty in updating either of those things can all lead to a build-up of debt on the content or technical side.

There are various articles out there describing in detail how these things happen, how to identify these different types of debt on our web projects, and whose responsibility it is to manage those debts, often falling to the project manager or technical lead on a project.

Project management debt, as far as I know, has never been addressed. But it is a real problem on our hands and in our projects. Project management debt is the accumulation of additional post-project work due to lack of complex analysis or decision-making on a project during its lifespan.

This work could come at expense of the stakeholder’s time and money, or at the web agency’s expense—in either case, costing either party lost time, money, and even potential lost functionality in the site after the project launch.

Below are a number of scenarios where project management debt can accumulate and occur. This list is definitely not meant to be all-encompassing, but more of a starting point for all of us to start thinking about the decisions we make on projects, the power we’re granted in making these decisions, and the conversations we should be having with our teams, stakeholders, and management/leaders as we’re working to better ourselves as project managers.

Project management debt as a result of unclear decision-making:

We make all sorts of decisions with all levels of collaborators during a project’s lifespan—that’s a big part of our jobs. However, if particular decisions made on a project are not logged or documented in a way that is transparent and easily accessible after the project, it can create project management debt for ourselves, our future co-PMs, or other team members.

Logging information about decisions made on a project helps explain why a deliverable, specification, or project might look different or take a different path from the original plan—it creates context for future users of the project data.

Having access and transparency into these decision-making contexts creates a traceable project history for any eventual stakeholder or project manager pulling project analyses or beginning phase 2 (or 3, 4, or 5) down the line.

Communication-related project management debt:

Project communication and expectation setting are a huge (if not the main) part of our jobs as project managers. Maintaining up-to-date and transparent communication records of a project’s status over email, chat, or through our project management tools is just as important as the actual communication involved in our jobs.

Following up to calls or in-person meetings with a brief written reference of decisions made and key points discussed keeps everyone in the loop on projects, and provides context for anyone joining a project midway through or picking it back up after launch.

Without this sort of reference, an entire aspect of a project history is lost and can create massive project management debt for anyone touching this project or related projects in the future.

Building that context back up from missing or piecemeal communication records will not only take time, but will also likely be much less accurate so late in the game.

Post-project loose ends that lead to project management debt:

Loose ends on a project could mean things like a list of post-launch or phase 2 bugs or features to be addressed, questions that were not answerable immediately during the project itself, training sessions for stakeholders on a new website or content management system, or any “opened door” that was not closed or answered during the course of a project.

These types of loose ends should be referenced or recorded somewhere in the project materials—like an additional SOW, in project management software, or in a document somewhere. This helps future project managers and team members on a project understand what the stakeholder’s context might be on requests after launch and can help prioritize account management work after a project launch.

Tie up all loose ends or document those left open before leaving, handing over, or transitioning a project to closed to keep things clean and transparent.

Project management debt due to (lack of) technical documentation:

Every project is unique in some way, and this includes the technology that makes it tick. Make sure your team follows technical documentation standards for themselves and track what technologies were used on the project, any custom or difficult integration work done in development, and that all site logins and administrative accounts are up-to-date and saved as of project launch.

This is one of the most expensive types of project management debt when these steps are skipped over—but it’s also one of the easiest to remedy and document before a project is over.

Documenting and keeping clean logs of technical decisions and paths on a project can help a teammate jump right into a needed update or bugfix down the line, avoiding any amount of overhead in decoding how the system works without documentation.

Keeping a project well-documented and transparent throughout its timeline helps avoid project management debt as a whole.

While this is only a starting place in addressing the concept of the types of debt our projects can take on, there are real and easy things we can do to avoid this issue as much as possible from the start.

I’d love to hear more about other thoughts on project management debt, if you’ve experienced it in some way on your own projects, and if you think it’s a real issue that’s out there on our projects.

Drop me a line through my contact form and add your email below to get even more project management insight into your projects!