Those responsible for software implementations — across multiple organizations — lack a shared language specific to this undertaking. No two organizations define problems exactly the same way, and as such we think our problems are unique to our product, customers, teams or industries. But that is simply not true.
Across software products and industries we are facing many of the same issues. Any of the following sound familiar?
- The sales team signs up customers that never actually go live and no one can clearly explain what went wrong
- Internal processes continue to be created that make each implementation more difficult than the previous
- Project kick-offs are premature and lacking people, processes and metrics. With good intentions we setup kick-off events, but rarely are we confident in knowing precisely who needs to participate, what they’re charged to do, and why
- No clear decision chain from the project onset, or consensus on how to communicate and address unresolved issues
- Stakeholders are left out the loop on good, bad, or indifferent news until it’s way too late
- No standardization regarding what types of information must be shared among the parties and how frequently
- Team members are frustrated by lack of tools to track and manage ongoing efforts within any given project, this only gets worse for those managing multiple projects
- The rules of engagement are either not expressed or not widely shared.
The Baton Method emerged from these problems that make for an unsatisfactory implementation experience, inhibit software usage, and eventually kill good projects. We surveyed 100 software project stakeholders, from CEOs to board members; from department heads to hands-on project managers, to learn as much as possible about how these folks described what’s just not working and [spoiler alert] rarely did those surveyed share the same vernacular. That said, here are four most common concerns:
- Failure to launch – the software customer signs up, but never goes live
- Ops debt – Businesses build processes that either don’t scale or only weaken the organization over time; coined from what an engineers refer to ‘technical debt’
- False Starts – When projects are not set up well from inception, the entire project suffers from onset through to completion or even project abandonment
- “Who’s on first?” – Stakeholders are not held to precise deadlines; left out the loop, so to speak, resulting in missed assignments, passing deadlines and other failures with critical deliverables.
Hopefully this summary is helpful. Our plan is to continuously improve the Baton Method and to regularly secure consensus on shared vocabulary and a vision for improvement. Once we all start speaking the same language, we can then move onto process standardization and advancing the emerging business technology tools that will advance the Baton Method.
