How to Help Project Stakeholders Avoid the Aspirin
Kent McDonald recently wrote an excellent article encouraging project teams to “ Get Out of the Building and Know Your Stakeholders' Problems ”.
This article really resonated with me, as it quite rightly recommends spending time with project stakeholders to understand their perspective or worldview and also to understand the precise problem that the project will help them solve. Put simply, the article highlights that it is worth investing time to understand the business, user, and customer needs that are driving the project.
In general, these are all excellent tips when working on projects, but they are particularly relevant when carrying out high-level enterprise analysis. One challenge that projects face is that there is often a difference between what stakeholders say they want, what they actually need, and what they can afford.
Layered on top of this, there’s often a focus purely on the important and urgent initiatives and projects —meaning that less urgent projects get sidelined until they become urgent, by which time it might be too late to implement a best-in-class solution. In a worst-case scenario, this could lead to an organizations’ IT estate and application architecture evolving into an unmanageable onion, with layer-upon-layer of tactical solutions (comprised of the technical equivalent of sticky-tape and string).
The great news is that as professionals within the change profession, we have the opportunity to stop this. We can help avoid these scenarios by asking the question, “Are we taking an aspirin here?”
Imagine you came home from work one day and had a headache. Chances are you’d reach for an aspirin or a painkiller, and the headache would cease for a few hours. However, if you still had a headache after a week, you’d probably make an appointment with a doctor. The point here is that aspirin treats the symptoms—not the cause.
Often, when we first speak to stakeholders, they tell us about all of the symptoms, which is natural; this is the day-to-day pain that they feel. However, developing requirements and solutions around these symptoms might be the equivalent of taking aspirin; the root cause will still be there. It’s therefore vitally important to work with them to understand the root cause of the business problem that they face.
There are many great techniques available to help us with this. The 5 Whys technique is simple, elegant, and effective. If you have a group of stakeholders, creating an Ishikawa (fishbone) diagram can be beneficial.
However you do it, remember to focus on the stakeholder’s worldview and remember to avoid the desirable, sugar-coated aspirin.
What techniques do you have for avoiding the aspirin in projects?
