Most organisations are either going through or planning major change. The challenge is balancing the amount of change an organisation can handle internally with the speed of change generated externally by digital technology, customer expectations and disruptive marketplaces.
This, now more than ever, is resulting in organisations making the decision to stop projects mid-delivery.
Stopping projects is nothing new but it seems more organisations are making the decision to either stop a project, or descope a stream of work within a programme, as it is deemed that it is not delivering benefit, taking too long, costing too much or is required to make space for a higher priority change.
It could be argued that this is a result of organisations being more agile (in a non-project methodology use of the word) to business needs, but decisions to stop are often made without appreciation that immediate cost savings may negate any investment or benefits and actually cost more in the longer term.
Sometimes the decision to stop things and say they will be handled in a different way creates an extra cost or overhead and becomes a legacy item that is never properly addressed. Most organisations have a problem with older systems/ways of working and projects that haven’t been completed and then start another project without learning from the past.
When stopping or descoping happens, there needs to be a proper impact assessment done to re-assess business need or strategy, impact on benefit and cost (both to date and due to the decision to stop). The question this poses is, in a climate where changes are more frequently stopped mid delivery and not completed, are IT organisations giving the right level of consideration to any project or programme before it starts?
All traditional methodologies emphasise the importance of initiation, strategic fit, benefits, impact etc but the assumption is that the project or programme will complete, delivering its scope and benefits, not stop mid-way through. While agile methodologies are more amenable to stopping, they aren’t appropriate for all types of project and not all IT organisations (or often their partners) are set up to deliver in that way.
Also, while many, generally more complex projects will have stages/phases/tranches, and thus should have a clear idea of the outcomes and benefits that will be delivered, Design-Build-Test-Deliver projects may have no benefit until delivery.
Initiation should also include consideration of what outcomes and benefits will be delivered and at what stage, which then in turn can drive decisions on how to phase the delivery and what will be expected at each phase. Thus, any logical stopping points can be identified, and project funding can potentially be aligned accordingly.
Based on this, the Stakeholders can then be made aware of any potential stopping points and held accountable for the impact of stopping at each stage of delivery before starting. This then aids the organisation in making it more flexible to outside influences such as strategic changes, new technical developments, undelivered dependencies and ultimately, the decision to stop.
Accordingly, change management (and portfolio management, if relevant), processes need to factor in the potential stopping not only of the current project but also any parallel projects used for planning assumptions or incoming dependencies.
Stopping of projects that you have based assumptions or incoming dependencies on can also have an impact. Decisions to decrease budget or change of scope, equivalent to a stop, in one project can result in increased costs or decreased savings and benefit in another project and thus for the IT organisation.
Making sure that the change process is aligned to the stopping points or phases within the current project, will help to assess any decision to stop.
Finally, formal closure remains critical. The decision by IT organisations to stop projects early can have a huge impact on future projects and the delivery of strategic benefits. Yet when a project stops, resources are generally moved onto a new project without the right level of effort going into proper closure, identification of what benefits have been delivered and what needs to be completed or rectified.
Project closure must be a core part of a project that has been stopped. In the same way that it is important for a project to have a post-delivery plan to realise benefits and ensure adoption, the same amount of effort and planning is required to address any gaps, compensating for missed benefits or communicating incomplete deliverables when a project is stopped mid-delivery.
Change is constant: projects will start and be stopped. Planning ahead and closing out properly when a change doesn’t reach its optimal conclusion will help minimise disruption, while insuring that it doesn’t impact subsequent changes for the organisation.