Project Pain Points vs Needs: How They’re Different & Why it Matters

To truly succeed on projects, you first have to understand the problem your project needs to solve.

When you read that sentence, it seems obvious doesn’t it? But how we go about understanding the problem can make a huge difference to the overall project outcome.
The best way to start a project is to determine the “Why” of your stakeholders.

Why should this project happen?

This is the question we want out stakeholders to answer. But you need to ensure their answer is useful in helping you understand the depth and extent of their problem. It needs to give you the clarity you need to develop a useful solution.

In my training, the first question to determining the why is ‘What is your pain point or need?”

And before you ask this question, it’s important to know that there’s a difference between someone’s pain point and someone’s need.

Let’s explore that difference, and why it matters to the success of your project.

What is a project pain point?

A pain point is something which is causing your stakeholder a problem that they are directly feeling.

It has a negative impact on their work, their engagement, their productivity, their emotions, or all of those things.

It is causing them a pain that they can speak to and want to take action to fix.

What is a project need?

A need is something that your stakeholder has been asked to implement.

They may, or may not see the value. In fact, a need can sometimes be seen as an inconvenience.

The difference between a pain point and a need

When stakeholders feel directly impacted by a pain point, they want to engage with you because they want to ensure that your solution will ease or remove their pain.

They are more likely to turn up to your meeting requests. They will be more available to answer questions to make sure that the solution solves their problem. And they will be powerful advocates if your solution meets and exceeds their expectations.

On the other hand, a need may or may not have been requested by your immediate stakeholders.

They will generally not have the same sense of urgency to help you solve the problem. In their mind, a need is more of a nice to have or perhaps even, a nice not to have.

You want to know as early as possible in the project whether your stakeholders do or don’t see its value.

If they don’t see the value, they will typically be more difficult to engage. You might find that they don’t accept meeting invites or if they do, they either send a delegate who is less helpful to your needs or they just don’t show up. Stakeholders in this category can make information gathering, decision making, and project sign-off more difficult because they would prefer to resist the solution.

How do you find out if it’s a pain point or a need?

The first step is to ask!

Here are three questions to ask your stakeholders to help you draw out if you’re dealing with a project pain point or a project need:

  1. Is the current process or product causing you a problem?

If the answer is yes, you will want to find out the problems the stakeholder faces personally and how these impact their work.

2. Who has asked for this project?

Was your stakeholder involved in requesting the change the project will deliver, or was this request made by someone else?

2. Who has asked for this project?

This will tell you directly if they do or don’t want the project to go ahead.

What do you do next if you’re dealing with a project pain point?

If you discover that your stakeholder sees the project as solving their pain point, then the most important consideration is to ensure that they are actively involved in creating the solution.

You can turn your stakeholder into a powerful project advocate by:

  • Making sure you are clear on what is required to solve their pain, with tangible and measurable information
  • Keeping them informed throughout the journey the project will resolve their pain
  • Getting them to share project updates with their team – this helps them to feel proud about the project and spread the excitement

What do you do next if you’re dealing with a project need?

What do you do if your questions reveal the problem to be a need that isn’t wanted by your stakeholder?

To begin with, expect that your stakeholders may be apprehensive to your project needs.

It’s not likely to be personal, but you or your project signifies something they don’t want. They either see it as an inconvenience or possibly even a threat.

To get their attention you must understand and be interested to know why they don’t see the value.

It is not your role to convince them that the project is positive or otherwise. It is however in your interest to get them to want to engage and contribute to the solution.

What to ask (and communicate) next.

Past Learnings.

Find out if they have a past experience on the subject.
Learnings from previous similar experiences can significantly help project teams to start projects on a positive and much stronger foundation.

You might want to have a look at my article on a lessons learned process. Learning from a stakeholder who doesn’t immediately see value, gives them a reason to want to engage and share their experiences because it makes them feel valued.

Understand the Change.

LoremMake sure they understand why this change is needed and most importantly, “What’s In It For Them”.

The person or people to know this information best will be the project’s authorisers (sponsors). I would strongly recommend this information is provided by the authorisers of the project rather than members of the project team.

The project team should always take an impartial role and focus solely on delivering the greatest value to their stakeholders while meeting the projects commitments.

Open and Regular Communication.

To build trust, people need to know what’s going on.

Communication is key to make stakeholders want to engage.
But it can’t just be any communication.

Communication needs to meet an intention and in this case the intention is to have your stakeholders want to actively contribute to your project in the capacity you require.

Here are some suggestions of what you want to communicate.

  • What role will they play (directly or indirectly) on the project (making sure this meets your projects requirements). Will they be a Subject Matter Expert, an advisor, accountable, owner, to be consulted, approver, etc.
  • How much of their time will be required – including an idea of when they will be needed and critically, how this will help the project and your stakeholder.
  • How they can help to make the project a successful outcome for them and others within the organisation
  • Milestone updates and how this will benefit them (or how the project is closer to delivering them benefits)
  • Their user requirements related to the project’s needs, and the process the project suggests taking to deliver on these requirements.

The Difference Between Good and Great is Always in the Details

The first step to more powerful projects is an awareness of what factors are not supporting your success.
Are you missing the difference between pain points and needs in your projects?

It’s a subtle distinction, but like most things, the difference between good project delivery and great project delivery is in the detail.

What subtle nuances are not supporting your stakeholders and your project’s success?

How are you using subtle differences to deliver more powerful projects?

Want to know which small changes will bring big success for your project team?

Book a FREE 30-minute discovery call with me today and discover the subtle changes your team could make to improve their project success.

Get inspiration to improve your project delivery.

Subscribe for insights, tips and strategies to help you deliver powerful projects.