Pursuing the wrong projects can be disastrous for an organisation. In the first half of this article, I looked at the various reasons that organisations end up pursuing change initiatives that should never have been started, or that should have been abandoned in favour of other ideas. These reasons were grouped under the following three categories:
- Strategic errors
- Project design and planning failures
- Failure to adapt
In this second part, I’ll look at what organisations can do to address these issues and to ensure the projects and programmes they pursue are the right ones to deliver on their strategic goals.
Strategic planning
Align changes with strategy
Before any change is approved for delivery, it must be obvious which elements of the organisation’s strategy are being addressed. If the organisation’s goals aren’t being fulfilled, the wrong projects are being undertaken.
In part, this hinges on the strategy itself being clearly developed and articulated. Techniques such as MOST analysis can be a great way to explore and understand strategic intent. Identifying the strategic behaviour patterns that will be adopted makes it much easier to align projects and programmes.
At the very least, the organisation must have some SMART objectives, and any initiative should clearly link to the fulfilment of at least one of these. It’s the responsibility of the change sponsor to articulate this link.
Agree a prioritisation approach
Most organisations will have a backlog of change initiatives that it hopes to deliver. Identifying which ones should be pursued next (and which ones put on hold!) can be a real challenge, particularly when there are various interested stakeholders all shouting for their project to be next!
One way of comparing projects can be to introduce a simple scoring system with several categories (such as risk, sustainability, profitability, customer value). Assigning projects points against each category enables you to rank every initiative in the list. This doesn’t have to be the final ranking – decision-makers can always argue why a project should be somewhere else on the list – but it gives you a pretty good idea of what’s most important.
Where dependencies between projects have been identified, you can manually shift these up the list.
Having a robust and transparent prioritisation approach is also really useful for eliminating pet projects!
Ensure changes have a clear business case
Make sure that your process for proposing and approving change initiatives actually includes steps for building and then evaluating a business case. Failing to do this guarantees the wrong projects will be pursued.
A business case can be as deep and detailed as required for the size of the proposed change. The bigger the issue or commitment of resources, the more scrutiny the proposal requires.
I’m wary of templates. They can be useful for prompting thoughts or reducing effort, but it’s easy to get over-reliant on them or constrained by them. However, adopting a template for business cases can ensure a degree of standardisation (enabling comparisons) and ensure that all angles are considered.
A business case needs to explain what is being proposed, and then present a comparison of the costs and benefits around adopting the proposal. This means it needs a reasonable explanation of the resources required to deliver the solution, and the financial costs involved.
The benefits should be categorised (perhaps using the same headings as for your portfolio prioritisation) and calculated as scientifically as possible. If the answers are only estimates, state how confident you are in them.
It’s also important to consider the opportunity costs and other negative impacts of not pursuing this change.
Business analysts are well equipped to map the benefits of a change initiative to the strategic goals of the organisation, and to explore the costs involved.
Project design and planning
Consider technology as only a part of the bigger picture when scoping and planning change
Technology is only ever part of the change and, I always argue, the easy bit! Failing to view it this way risks major gaps in project scoping and misplaced emphasis in implementation activities. It also limits buy-in from stakeholders, who are likely to see the project as “just an IT thing”.
Even if the bulk of the work on a project will be about implementing a system, it’s healthier to think of it as a business change project. This ensures the focus is on the value created for internal or external customers, and helps to make sure that project scoping includes all relevant activities and changes.
Some of this is about language and how we talk about changes. Don’t use the name of a system when naming your project. Instead, find a name that describes the problem that’s being solved, or how the business will be better.
Ensure adequate time and resources available
The business case should identify the time and resources required to deliver the change. This may only be rough figures at stage – a project manager will obviously establish the full detail in their delivery plan – but there needs to be enough detail to inform decision-making. The business case may even offer alternative possible approaches, such as using fewer resources but over a longer period.
Assuming the business case has identified the resources required, make sure that green-lighting the project means those resources are actually secured. Those with the authority to approve a project must also have authority to direct the required financial and people resources to deliver the change. This must include leaders of business areas whose stakeholders will be involved as subject matter experts in process design, requirements definition and acceptance of the change.
Have a plan (and commitment) to realise the benefits
Even when a project delivers its outputs on time and on budget, organisations often still fail to reap the expected benefits. If nobody can demonstrate the benefits have been achieved, there’s no way of knowing this was the right project to undertake. Assuming those benefits were clearly defined in the business case, this failure will usually be down to a lack of planning or accountability.
Someone has to be tasked with measuring the benefits achieved, and this will often need to be done over a period of time. The measurement approach should be agreed in advance, and will vary based on the types of benefits expected (e.g. increased sales, time savings, staff engagement etc.).
If headcount savings are expected, the leaders of the business areas concerned should have a plan in place to actually make the necessary changes to staffing levels and deployment. They need to commit to delivering those savings by a point in time, otherwise any efficiency gains are likely to be swallowed by other tasks.
The BCS International Diploma in Business Analysis includes a whole module and exam devoted to ensuring the benefits of any change initiative are quantified and realised. Business analysts are well-placed to helping organisations assess the benefits of any change initiative and build plans to realise them.
If for any reason the benefits fail to materialise, this needs to be brought to the attention of those that gave the green-light for the change in the first place. It’s quite possible that the project should never have been initiated, and lessons will need learning to prevent future repeats!
Adapt
Watch for changes in context
The world keeps turning while a change initiative is being delivered. A lot can change in the time it takes a lengthy project or programme to be completed. To avoid your project becoming irrelevant, three things are needed:
- Identify where risks and opportunities might arise. – consider what might change while the project is in progress. Techniques such as PESTLE analysis can be useful for understanding the key external factors. Think about assumptions which need to remain true while the project is delivered. Quantify risks by likelihood and impact.
- Make sure it’s clear who will monitor for changes – if it’s nobody’s job, nobody will do it! Decide who is responsible for scanning the horizon, and figure out how and when they will get their information.
- Make sure it’s clear how changes will be reported and examined – determine who needs to know that something has changed, and who can make decisions on appropriate responses. Should it be the same people who approved the project? Can the sponsor make decisions alone? How will this work with your existing risk management practices? Consider the various stakeholder perspectives that are likely to be involved, and (where possible) ensure some independent voices are included.
Agree in advance how “wrong projects” will be terminated
Continuing with a project that will no longer deliver the expected value is just compounding failure. Aside from the obvious operational and financial risks this brings, it can destroy the morale of all those involved and irreparably damage relationships with “business-side” stakeholders. There is no shame in cancelling a project that truly needs to be terminated.
Ensure that criteria for terminating both projects in general and this particular project have been identified and agreed in advance. If there is a project initiation document, make sure this information is included within its pages.
These criteria could include delays to delivery, lack of resource availability, or external changes invalidating the business case. Be clear on the thresholds that must be met.
Make sure the right people are aware of these criteria – whether that’s business analysts, project managers, developers or the sponsor themselves. Everyone needs to know how and when to escalate a potential issue.
Finally: engage a business analyst
Using a business analyst can give you a huge advantage in trying to achieve all of the points above. BAs bring expertise in strategy analysis, business case construction, change scoping and benefits management. They can also act as an independent advisor to help navigate a way forward with competing and conflicting stakeholder interests.
Even if you already use business analysts in your organisation, make sure they are in a position to analyse and advise at every step of your change lifecycle, thus ensuring you finally stop doing the wrong projects and pursue the right ones instead!