Do it right or do it fast?  There's sometimes a price to pay for "Do it fast". It's called Technical Debt.

Probably the most famous example of technical debt is MS-DOS. Back in 1981, IBM asked Bill Gates for an operating system for its new PC. To deliver on time, he took QDOS, (QDOS stood for Quick and Dirty Operating System) and renamed it MS-DOS. Born quick and dirty, MS-DOS was loaded down with debt from its very conception, with a poor command set and limited features.

In the world of project management, on time delivery is a key measure of project success for most projects. As you rush to meet the deadlines, you may be accumulating debt silently, invisibly... but incessantly.

Technical Debt may appear as

o   No documentation or user guides

o   Low quality programming (unstructured, few comments, hard-coding)

o   Badly structured databases (redundant data, data errors)

o   Poor designs (poor architecture, not modular)  

o   Poor processes (inefficient, waste time, error prone)

Debt is typically associated with software projects, but it's not only about software - all sorts of project can generate debt.

Technical debt is often generated by the pressure to finish on time, but it's not just a question of speed. There are several sources of debt.

• Speed: rushing is probably the number one cause of technical debt.
• Short term view: Patching and mending. Non-architected solutions
• Fire-fighting: Focusing on backlog (not on the future)
• "Bleeding-edge" innovation: Learning as you go along
• Lack of skills: Putting staff with wrong skills (or no skills) onto complex tasks 

Why do we worry about it?

Technical debt is like financial debt... you can ignore it for a while, but the accumulation of debt will come back and haunt you.  As you build up debt, you end up with a mess - a patchwork or spaghetti that's difficult to understand or difficult to change.

That's a potential surcharge on everything you try to do - technical debt can slow down and complicate future projects. You may also end up with premature aging - the accumulation of debt can shorten the lifetime of your solution.

Don't Sprint into debt.

The main cause of debt is speed. Some project management methods focus on speed, notably most lightweight variants of Agile. Lightweight Agile methods such as Scrum can force you into debt if you over-focus on sprints and speed. You may deliver on time, but if you sacrifice other factors of best practice, such as design, planning or quality, then you could be accumulating debt.

There are two ways around this problem for Agile projects. You can try to make your lightweight method more robust (as described in the book "Managing Software Debt" by Chris Sterling) or you can use an enterprise Agile solution

How Enterprise Agile helps

Enterprise Agile methods such as DSDM Atern (sometimes branded as AgilePM) allow you to combine agility with architecture and design. Atern also has a project management toolkit to ensure a long-term approach (plans, business case, etc.) - these help to clarify the trade-off between speed and debt (and therefore to remove or reduce debt).

Whichever way you choose, and whether you use Agile or not, you need to be aware of debt. You probably won't be able to be debt free, but you should apply three golden rules:  

• Start today to pay back old debts (each new project cleans up some previous mistakes and clutter)
• Avoid new debt (do it right in future, balance speed with quality)
•  If a project does have to sprint into debt, clean up the mess ASAP