If you’re currently working with an underwhelming or failed software implementation in your government agency, while it may not feel like it—there is a significant silver lining to your present situation. You now know with a high degree of certainty the areas in which your project went astray internally—and of even more critical importance, those areas in which your current implementation vendor may have fallen short or continues to underperform with their service and delivery model.
Granted, this wisdom may have come at a high price, but the root cause audit you are now able to perform will establish an invaluable framework for your future success. Of equal importance, if an exit strategy is required to transition you from an underwhelming platform to a more mature enterprise solution, an effective audit will help you to tease out those internal organizational and technology assets that you can best leverage going forward to help defray the impacts of previous sunk costs. This is an important consideration for government leaders feeling as if they’re ‘stuck’ with an underperforming vendor, and thus mulling the long-term implications of maintaining a mediocre status quo—never an attractive proposition for citizens OR administration alike.
Certainly costs will vary according to the scope and complexity of the project, but it is important for government leaders invested in providing quality services to their citizens to know that currently stalled implementations are rarely as constraining as they can appear on the surface—with an effective Transition Readiness Audit often resulting in a concrete direction and newfound optimism for those organizations still resilient enough to embrace the right path to innovation.
One of the challenges in performing this type of project audit is defining where internal responsibilities end and external vendor accountability begins.
Because failed enterprise software projects often involve the failure to achieve a clear and common understanding on business requirements vs. anticipated feature functionality and user experience, failed projects can all too easily devolve into finger pointing exercises between client and vendor with both parties expressing frustrations with communication disconnects throughout the process. The most common expression of this is clients identifying system issues as ‘bugs’ or ‘feature gaps’ whilst the vendor insists on labeling them as a new development work (e.g. change requests). The root cause here is the lack of a common frame of reference on what exactly the product should look like on Go Live Date and beyond.
While not wishing to give a free pass to government clients that contribute to poor project implementations with incomplete, vague or ‘moving target’ business requirements, it is important to stress that the lion’s share of responsibility to ensure that business requirements pass muster as actionable workflows must reside with the enterprise software vendor. Just as a homebuilder must ensure that blueprints provide a common frame of reference and a clear construction plan for his prospective homebuyers, the implementation vendor (as the defacto subject matter expert for their software solutions), must ensure that the process to turn agency requirements into reality is a clear and communicative process providing ample opportunity for discovery and dialogue for all parties involved.
This mission is especially critical as the relationship evolves from one of product delivery to one of product support and optimization, and it here that government clients will often start to recognize the signs of a software vendor struggling with a poor service delivery model.
Next week, we’ll continue our ongoing series on How to Deploy a Digital Government Platform by showing you how to spot the ‘Warning signs that a software vendor is lacking with their service delivery model.’
