Project Failure - Typical Recovery Projects

These are some of the typical turn-around projects I have resolved.

A stalled project to develop a bespoke Oracle-based grant management system for a Housing Authority

Key Evidence:

High rate of rejected software deliveries; massive timeline slippage.

Diagnosis:

Informal business requirements and design on the client side. Inappropriate development methodology together with a long code/deliver/test cycle time.

Solution:

Client to formalise requirements gathering and sign-off. Implement Agile/DSDM methodology with on-site coding and greatly reduced cycle times.

An over-running project to develop and implement a Banking general ledger in time for Euro go-live in a Swedish bank

Key Evidence:

Client team reporting high rates of UAT test failure; re-insertion problems (old bugs re-appearing); low credibility of supplier.

Diagnosis:

Poor version control at supplier; cultural divide between the US development company and Swedish client project team.

Solution:

Deploy a British project manager to replace US incumbent and bridge the cultural divide, with 'tell it as it is' approach to software delivery. Enforce improved version control at supplier and require formal pre-release test results report from supplier prior to software delivery for UAT.

Development of a large personnel and payroll system for a Middle Eastern government.

Key Evidence:

Client team reporting high rates of UAT test failure; re-insertion problems (old bugs re-appearing); low credibility of supplier.

Diagnosis:

Lack of basic quality assurance processes at the software house, together with informal UAT planning & control, test execution, test results analysis and reporting on the client side.

Solution:

Formalise the UAT test process and test products; advise the software house on implementing basic QA processes and require formal test results from the supplier before code shipment to client for User Acceptance Testing. 

Stalling Project Reporting at an Investment Bank

Key Evidence:

A development department was failing to comply with the project reporting requirements laid down by the programme office. Staff were not complying with the project reporting requirements.

Diagnosis:

The development department was running many small development and enhancement projects, with very few 'high risk' projects. The project reporting requirements were onerous in relation to the risk of the majority of the projects in the department.

Solution:

The reporting requirements were a given, but an acceptable solution to all parties was to prioritise the projects according to overall risk, timeline and budget variance, and technical issues and report on that basis. This reduced the reporting workload requirement broadly to exception reporting only. The project team were able to buy in to this approach.