Work is undertaken by organisations in two ways: business as usual (BAU) and change as usual (CAU). Today, organisations are continually in a state of change. There are many words for change. Innovation, disruption and transformation are regularly used to refer to essentially the same thing.
Change is typically instigated by way of a project. Almost all projects involve technology in some way, and for that, the term ‘digital transformation’ is regularly used. In some ways, a digital transformation is simply a significant change, delivered as a project, using emerging technologies.
But there is a problem. Projects don’t always run within scope, on time, within budget or with appropriate quality. What causes projects to fail so regularly?
In this multi-part series of articles, I take a dive into some of the reasons why projects fail and uncover some of the actions that can be taken to improve the likelihood of project success.
Project Fail #1: Execute the wrong projects
Before considering why a particular project may fail, there is a more fundamental question to ask. Are we executing the right projects? Organisations operate with finite resources. The strategic allocation of resources to the right projects is a critical success factor for the achievement of strategic objectives.
Organisations exist as groups of teams, undertaking programs of work. These programs can be broken up into portfolios, with portfolios consisting of multiple projects.
It is common for organisations to identify more projects that they are capable of executing with their available resources. Determining which projects deliver the best overall outcome can be complex, as some projects may be dependent on others, or conflict with each other. Duration, resource requirements, risks, budget and expected benefits are all likely to be different, making project selection more of an art than a science.
What is the optimum selection of projects to deliver the most bang for buck? This is often the first question to ask in striving for project success. Shifting goalposts contribute to the challenge.
Regularly ask yourself the question “Are we working on the right projects?” And consider, “Do we have the courage to stop a project and start another, if the overall outcomes will be better for the organisation?”
Project Fail #2: Don’t document the business case
Projects should be supported by well-constructed, considered and detailed business cases. In fact, it’s not usual that an initial business case be crafted to obtain approval for the expenditure required for a detailed and more comprehensive business case to be undertaken.
Business cases typically document expected project requirements for resources and costs, together with anticipated benefits. They answer questions like, “Why are we doing this project”, “How long will it take to complete” and “What will we get out of it at the end”?
But not all projects have the benefit of a well-documented business case before they start.
When preparing a business case, always consider the other alternatives available, rather than just the one proposed. Document why this project is the best way of achieving the expected outcomes.
Project Fail #3: Don’t identify the benefits
So, you’ve got a business case – great! Now, what will be achieved? It’s crucial to identify what benefits are expected to flow from all the hard work and effort that’s about to go into project initiation, setup and execution.
Benefits identification is an essential first step in benefits realisation.
It’s important to consider that a wide range of benefits can come from a project. There are core benefits – the primary reasons why a particular project may be undertaken, and other less important benefits that are intended to be achieved. Effort should be expended on ensuring the attainment of these ancillary benefits as well. It’s likely that a third category of unexpected benefits will also arise, but of course, being unexpected, they won’t have been identified before the project actually starts.
After expected benefits have been identified, if any of them include an expected improvement over the current system, make sure you create a baseline before the project starts. Otherwise, you will have no way to compare post-project implementation performance against the current state.
Project Fail #4: Don’t articulate the assumptions
Projects don’t operate in a vacuum. They exist within a complex network of organisational activity within a market full of external influences. Political, economic, social, technological, legal and environmental factors create risks and opportunities for all businesses.
It is good practice to consider what internal and external assumptions have been made when contemplating the project identified in a business case.
Assumptions should not only be documented but also tested. On what basis have the assumptions been determined? Who agrees with these assumptions? Which ones are more robust than others? How can we be assured that the assumptions made in the business case are the right ones?
Use scenario modelling and analysis to see the effects of a variation of assumptions on the project. For example, what will the delay in project delivery be if there is a loss of key project resources?
In the next article, I will look at Project Committees.
Gain the tools and knowledge to become an effective Queensland Government digital project board committee member with Queensland Government Digital Leadership: Digital Project Board Governance Masterclass.