Project Recovery

Conclusion: Many processes are relatively poorly designed and are not subject to effective governance. The reasons for this are many and varied: some relate to complexity, where there is a perceived risk associated with their criticality and whereby change could harm the business if they are altered; others are just not managed at all.

If your organisation does not understand how its business processes are architected, executives run the risk of fear influencing their judgement, rather than fact – the end result is ‘no change’ where change is needed. The COVID-19 pandemic has demonstrated the need for flexibility and agility in business processes to sustain and grow the business. The opportunities in the post-COVID-19 world, where many processes have been found wanting, are too great to be missed.

Successful organisations understand, manage and adjust business processes to meet the times. Having an effective business process management approach – where the process strategy is documented, processes are designed against set standards, implementation is monitored and managed, and controls are in place to manage the process lifecycle – is essential if your organisation is to achieve the best outcomes.

Conclusion: Projects in trouble or failing need to be assessed with two main possible outcomes: rescue or discontinue. Organisations should carefully consider whether shutting down a project is a better outcome. If the decision is to discontinue then it should be done in a careful and controlled manner which considers the impact on stakeholders, team members and any residual value that can be extracted.

Conclusion: Once a project is in trouble and the first response of escalation of commitment in terms of allocating time, budget and resources in an attempt to recover the project has not been successful, the project can be considered as not just troubled but in real crisis. Recognition of a project in crisis is the first step to recovery and often the most difficult. Next steps involve putting the project into triage and preparing the project for the detailed assessment phase which provides critical information, options and the potential important decision to kill the project or recover.

Conclusion: When projects start to show early signs that they may be in trouble, it is easy to have a knee-jerk reaction and address the most visible symptom. However, it is critical that CIOs and business executives (project board chairs and project sponsors) understand that early recognition and intervention is often less painful, less costly and less damaging for the organisation.

Conclusion: Organisations, large and small, have invested time and money over the past 5-10 years in improving ICT project success. Skilled project managers, governance groups, increased executive awareness and improved processes have all combined to improve the probability of a successful project. However, recognising when to cut the losses of a failing project is still a problem for many organisations. Either they never terminate a failing project or they delay in making the decision to terminate it. Either way the consequences can be devastating.

Conclusion: Recent Standish Group research1 has shown that project failure rates for IT-based projects have risen since from 19% in 2006 to 24% in 2009. Running projects successfully has become more challenging in recent times as the lingering effects of the GFC tempt project participants to cut corners. Strengthening methodology observance and project governance arrangements may result in some improvements in success rates. However, IBRS believes that greater benefit can be achieved by transcending such mechanistic approaches. We advise a holistic re-examination of candidate projects using our 6C2 approach, then re-configuring those projects where necessary to improve their chances of success.

Conclusion: Failed projects are newsworthy again. The most recent report from the Standish Group, which has studied over 70,000 IT-based projects since 1985, indicates that project failure levels reached new heights during the GFC. Prima facie, this is counterintuitive. Additional controls (such as closer scrutiny and reduced tolerance levels on spending) and cautionary approaches have typified executive responses to the GFC. However, cost-cutting to meet agreed targets and attempting to hasten project delivery in an already resource-lean environment will have contributed to this result.

Conclusion: As discussed in “Backup is not Archive!1 all IT organisations should evaluate deployment of an archival platform. However, based on numerous client conversations and a recent survey, it is clear there are significant project risks in implementing archiving. One-quarter of archiving projects take more than two years to implement and nearly half of IT managers state that they would not recommend the archiving product they had selected!

Conclusion: One of the more difficult aspects of the management of projects is the decision making process associated with shutting down troubled projects. There are a range of factors that can influence decision makers and prevent them from making a rational decision to close down a troubled project. These include project related influences, psychological and social factors as well as organisational pressures.

Why do many IT projects that are obviously in serious trouble go well past the point where they should have been shutdown? We can all give examples of where money and resources have continued to be invested in such projects, but do we understand the factors that can impact on decision makers and unduly influence what would appear to be the rational decision to close down a troubled project?

Conclusion: Stories of late and failed projects are legion within information technology. Whilst there are may be many reasons for project failure, a key root cause, largely overlooked in the literature, is failure to correctly enunciate user requirements. A less than satisfactory outcome at the requirements definition stage can only become magnified as the project proceeds.