What do all projects have in common? Projects vary in terms of budget, timescale, and technical content, but ultimately all projects aim to meet a customer’s needs and aspirations.
A fundamental project risk is that these requirements won’t be satisfied.
Having been responsible for project management within government and more recently as a consultant, I’d like to share in this article some reflections on the challenges of defining customer requirements and ways to reduce the risk that the project outcomes will disappoint customers. I am going to focus today on business improvement projects because that is the kind we have experience with at Horizon Point.
And while there are many factors which affect project success, you have to start somewhere, and customer requirements (i.e. the purpose of the project) is a good first principle.
As a kid, playing the guessing game ‘20 questions’ on long car trips, we were allowed an extra closed question before our 20:
‘Is it bigger than a breadbox?’
The yes/no answer to this question is a helpful prompt. But the metaphor needs a bit of tweaking when it comes to defining customer requirements. For example, if you want to improve customer services and risk management by introducing a new software system, you can’t specify the physical dimensions of the output.
Your output will be a new way of working, possibly supported by new business systems and technology, ideally delivering better results for customers. It will create new knowledge and ways of working, and new types of organisational capacity.
There may be few – if any – physical outputs. Instead a new, intangible asset will be created. The intangible nature of the deliverables makes it more challenging to specify the requirements.
So the prompt is more of an open question:
‘What kinds of bread will be in the breadbox?’
This is where clear communications (including listening to the right people) comes in. We must be specific about what the project will – and will not – deliver for the end-user. We need to confirm, not assume, that the end users and the project team have a shared understanding of 1) the requirements and 2) what product it’s possible to deliver.
The specifications for a business improvement project are much less clear-cut than for buying a new car for example. If you order a hatchback and get a sedan, there’s not much room for argument about whether the car matches the requirements you specified.
In contrast, when it comes to a business improvement project….what if the new system (say, a Customer Relationship Management System – CRM) needs to be ‘accessible on mobile devices’?
Apps for mobile devices tend to offer a smaller selection of features and functions than the desktop version. The idea is that they offer the basics you need on the road.
What if:
- The vendor promises a desktop and a mobile version. The customer indicates they understand the mobile version won’t include all the features of the desktop version but will include all the important features.
- These discussions happen between the vendor and the head office project team.
- The customer’s operational teams have a different view about what features are essential and which are ‘nice to have’.
- The operational teams only find out at the end of the project, when the new system is being introduced, that they won’t be able to use Feature X unless they have access to a computer. They regard the project as having failed (that is, failed to meet their needs) even though it was on time and budget.
There is no perfect solution for this kind of project risk, but in my experience methods that minimises it include having:
- a strong voice for the end-user from the beginning, and
- a structured way of defining requirements.
Voice of the user
‘Senior User’ is a concept from the PRINCE2 project management methodology. The role of the Senior User is to understand and champion the requirements of the end user. Importantly, they have accountability with the rest of the project team for the project’s success. They can’t demand the impossible for the end-user regardless of budget and other constraints. And if the project is not successful in meeting end-user requirements they can’t blame others on the project team.
Whether the ‘Senior User’ terminology is used or not, I believe that the role of Senior User on the project team is essential in managing this type of risk.
In the example above, the voice of the user was only heard clearly at the end of the project.
That was the moment of truth when it turned out that there was not such a shared understanding after all of what exactly the project was going to deliver.
At this point a classic project risk ( ‘project results may fail to meet stakeholder expectations’) was realised.
Giving structure to requirements discussions
Again, there is no one step that can address this risk but I have found a good practice at the beginning of the project is to use the MoSCoW technique to discuss and document what is required and what can be delivered, and the priorities for each requirement.
The MoSCoW technique
| M | Must have | Critical. If not delivered, the project has failed completely, even if it has met other success criteria. |
| S | Should have | Strongly preferred. More than ‘nice to have.’ Should be delivered if this is reasonably possible. |
| C | Could have | Optional. Appropriate but not essential to project success. |
| W | Won’t have | A definite decision has been made that these will not be included. |
You need the main stakeholders in the room for this discussion including the voice of the end user. They will have competing priorities so it helps to have some structure to defining the criteria for these priorities, that is, agreeing on how to agree, before trying to agree.
There is nothing wrong with differing priorities but it is essential to operate as much as possible on a ‘no surprises’ basis.
Putting in time and effort at the beginning (before the project has approval to start) is a good investment which minimises that classic project risk ‘fails to deliver results expected by stakeholders.’ This kind of early investment in project governance can pay off in various ways. Here are some scenarios.
- It is established that the Must Haves can’t realistically be delivered by the project. This should enable a decision not to initiate the project. Or, to stop it, if it is already in progress, which is harder because of the embarrassment factor, and the sunk costs.
- If the project does not deliver the ‘could have’ benefits, that is not a shock.
- If it is established that important benefits will not be included (i.e. they are in the Won’t Have list) alternative ways of delivering those outcomes could be considered, outside of the scope of the project.
- Some of the non-essential items could be deferred to later in the business planning cycle (e.g. to the following financial year etc) rather than trying to fit everything into one project.
Starting well
These issues apply to business improvement projects of all kinds of scale and sectors. There is no cure-all methodology for project risk, but there are established methods which minimise the chances of failure and maximise the chances of success.
What I have learnt over the years as a project management leader, is that if – from the outset – your project includes a strong voice for the end-user, and a structured approach to agreeing on requirements, then you are off to a good start.
© Skillset Holdings Pty Ltd
About Horizon Point
Horizon Point is a management consulting firm supporting organisations to build capacity, manage change, and achieve their objectives. We are expert, trusted advisers on project management, risk and governance, strategy, and planning.
Contact us
If you’d like to discuss how this applies to your organisation, feel free to get in touch.
Andrew Lee
Director
Horizon Point