Stakeholders: a different breed

During the course of my career I have had to deal with many-a-stakeholder. In an ideal world they get involved from the very inception and are provided with an opportunity to feedback and shape the project until completion.

However, this process does not always run smoothly. You get angry stakeholders and you get apathetic ones. Each type can be difficult to manage and it's often down to the strength of a Consultant's communication skills to keep things in check.

Below are some extreme personalities that I have come across. Okay, it reads like a work of fiction but I can assure you they exist within every large organization on the planet:

a) The Krug Protégé   - he (NB: this type is always male) read " Don’t Make me Think " by Steve Krug during his commute to work and had an epiphany. He now knows everything about user experience. No really, he does. That one little book changed his life and he is now using his company's web projects to "wow" senior management. That means challenging the minutiae of a wireframe and seizing opportunities to belittle consultants in a workshop - he who shouts louder and all that. Sadly the Protégé misread his beloved book and so absorbed is he in his own opinion and expertise that he does not value the contributions of others - especially not those users that keep schlepping in for testing and stumbling over the very functionality he recommended. Pah! What do they know? They haven't even read the book!

b) The Teflon Shoulder - Teflon has a prominent position within his/her organization - although the exact skill-set and reasons why they have clung on to such a role for so long are much speculated. One of the key suspicions is that Teflon is an excellent delegator and that means that all decision-making responsibilities are passed onto some other poor sod. Should that decision turn out to be disastrous for the organization - and in turn for the poor sod - well, that is certainly not Teflon's fault. The impact of Teflon in the stakeholder team is that timescales extend to infinity and beyond. There's a sharp intake of breath when the Consultant pushes for sign-off on just about anything because, as Teflon will tell you for the 100th time, it is not his/her responsibility.

c) The Bored Boss - The Boss is very senior. The minions within the company often refer to the Boss in hushed tones; such is his/her esteemed position within the organization. The Boss however is totally baffled as to why he/she is being consulted and involved in the user-centered design for this project. Isn't that what they employed Teflon for, for goodness sake? As a result the Boss will spend all meetings and workshops focused on his/her Blackberry, occasionally sighing or looking over their perched glasses as you try and whip up some engagement. Whether they are checking emails or trying to beat their high score on Brickbreaker, nobody knows. All you will know is that that deeply irritating scrolling sound will be the soundtrack to your frustration as you try to engage them within the process.

So as you can see from my over-dramatized descriptions above, not all stakeholders are equal. They are unique personalities and they need to be treated carefully. And no, you cannot get away with excluding them from the process entirely. Just as you want your user requirements to be met with user engagement, you need to do the same for your business requirements. That means putting both your kid gloves and "game face" on.

To make it a little easier I have found that there are a few golden rules that, when followed, go far to avoid poor stakeholder engagement. 

FYI: These tips are generally applicable to large organizations: 

1 ) Have a stakeholder strategy - now I don't mean go away and prepare a novel, documenting each stakeholder in excruciating detail, I just mean dedicate some time at the start of the project to thinking about who you need to engage and how you need to engage them. Start by brainstorming within your team and listing out all the possible stakeholders touched by your project. Alongside each name consider: to what degree does the project impact them, what their expected position is going to be, supportive/neutral/challenging and their degree of influence. Once this is complete you can work out the method of engagement you need to take and the communication style you need to adopt. Those with high influence and a more challenging style often appreciate face-to-face or direct telephone contact for example. A special person needs a more special and unique style of management etc. This will help everyone understand the general stakeholder landscape and will ensure that the entire project team knows the mode of engagement from the very beginning.

2) Set expectations at the beginning - now some stakeholders need to sign off on every key decision, but this degree of approval is generally sought from the person at the top and NOT from every stakeholder possibly impacted by the project. From the very beginning it is your responsibility to make this clear to everyone. You will not be holding workshops to get approval from each person on minor interface tweaks or color palette selections - no my friends, this is not a democracy! Of course, they will be encouraged to feed into the process but only in a very structured way via interviews or workshops that will be established to take place at key intervals in the timeline.

3) Understand the context - you need to swot up and understand what has come before this project - what ventures did they try and fail? Was anyone sacked because of what happened? Is there any brewing resentment in the corporate ranks? A lot of this you will pick up from the stakeholders themselves and it's a good idea to start the project with an introductory "get it off your chest" session. This allows everyone to get their voice heard and also enables you and team to understand both what to avoid but how to avoid the design solution you are implementing. It's also a great opportunity to get gossip and understand power plays.

 4) Meet commitments and provide follow up efficiently - to a stakeholder, especially one genuinely excited about the process, there is nothing more annoying that giving up 2 hours of time for a workshop only to never hear from the moderator again. If you want to really involve stakeholders in the process you have to keep open channels of communication. As we mentioned above that doesn't have to - and shouldn't mean - that we seek feedback on every single detail - but it definitely should mean that you maintain regular email contact and let them know how things are progressing. The end result is positive engagement that will spread throughout the organization.

5) Be flexible and open – my first step was decide on a defined strategy for engagement and I have also talked about set times for workshops and interviews. It all sounds quite rigid and structured but what I should also say is that you must be open and flexible when it comes to this process. Just as project scope's change, so do stakeholders and it's up to you to keep your ear on the ground and respond to criticism or praise from your client. Don't be afraid to change tack. Whether it's upping the number of interviews you have or the scaling down the frequency of communication remember that at the end of the day you are dealing with human beings - who also happen to be paying your bills. In all projects openness beats mystery any day.

So they are my top tips. Now over to you…

What kind of stakeholders have you encountered during your professional career and what techniques – non-violent please – do you have for dealing with them?

Thanks for reading!

Comments

• Anonymous
  June 02, 2012
  Well I recognise at least one of them! :0)