Each participating organization typically enters the project with positive attitudes and good intentions. Unfortunately, they also tend to bring long-standing, outdated processes to the project that require cumbersome steps, leverage antiquated technologies and sometimes add excessive paperwork. The plot thickens. The more people who enter a project, the less efficient the team becomes. Talk to enough experienced implementation managers about this repeating condition and you'll get an earful...perhaps more.
Here's the very legitimate problem: software customers need to stay abreast of how vendors manage complex implementation projects. Unfortunately, too many of them rely on non-scalable methods such as spreadsheets, emails, PowerPoint decks and phone or video calls to track progress, deadlines, etc.
It's not just customers who are working in the past. Software vendors are guilty as well. As projects become more involved, the outdated spreadsheets and such serve little value for day-to-day task tracking and management. In fact, most would argue such tools only add time and effort to projects where hours are billed at far-above the minimum wage. High-demand workers spend their costly billable time pushing paper. It's time that adds costs to projects; billable increases that are rarely estimated in advance.
In engineering, they call this Technical debt or Tech debt, and in software it's been called something far worse. At best Ops debt presents itself like a lot of people generating "CYA docs" that don't help projects in any meaningful ways. The term Ops debt, coined by early contributors to the Baton Method, is catching on in the software industry...but not in a good way.
Ops debt accumulates faster as projects delay. The industry promise of faster deployments through SaaS is damaging the SaaS providers because while their software has improved, the methods for team collaboration -- specifically for software implementations --have not advanced at the same pace.
The Ops debt problem isn't limited to single projects that grow in scope, it's an equally challenging problem for software companies with a rapidly growing customer base, because what worked for making a SaaS provider’s first 20 customers successful likely won't work well when they've grown to adding 20+ new companies a month.