Government Software Failure
Government software procurement failure is a serious risk and massive expense because state and federal agencies need software for public services across a range of industries including education, healthcare admin, infrastructure, and tax collection.
A major challenge is that the project planning, requirements tracking, and SDLC systems used by contractors and by government project managers are often not aligned. The desire to schedule software deployment dates years in advance often creates unreasonable expectations before the parties fully understand the complexity of the implementation or the risks.
Changes in political leadership can greatly influence the availability of continued funding. In addition, changes to laws and regulations can reshape the requirements of a software project already underway, and compromise the project’s feasibility within budget constraints.
Commercial Software Failure
Commercial software projects bring different challenges to customers and software developers/integrators. Commercial projects can be installation of a commercial off-the-shelf software (COTS) such as SAP, AVEVA, or Salesforce. Alternatively, a customer can hire a software developer to build a custom customer relationship management (CRM) project.
From the customer side, commercial software integration requires buy-in at the ground level from stakeholders including the end-user, the management, stockholders, and sometimes even vendors. Transfer of legacy data can present a tremendous challenge depending on how well structured the original data gathering and capturing process. Similar to government projects, the knowledge base of the management team overseeing the project can impact the success of the implementation.
From the developer side, the developer may decide to use a customer as the beta tester for a potential COTS offering. If responsibility for data management has been put on the developer, the business analyst from the customer needs to be available to explain the data and coordinate or clarify any areas which cause questions. Importing a catalog of data from a third party may offer a bigger challenge to the database management. The integration may have a fixed deadline but customer super-users (the customer users who will train the other users) may not have availability for the necessary training.
Communication of expectations and allocation of responsibility falls on both the customer and developer. If the developer wants to beta test a new product, has the customer been made aware of that plan? If the customer legacy data is badly corrupted, does assigning responsibility for data migration to the integrator make sense?
Because commercial software projects involve multiple parties, the trier of fact needs a company which understands both sides of the responsibilities which may cause a project to become delayed, struggle to launch, or fail outright. Quandary Peak has experts who have worked on both sides of the software implementation, and we can help navigate the facts to find what really happened.