Best way to deal with difficult stakeholders?

Question

My CEO has moments where he is just very difficult to work with. He has a tendency to nit pick and when he nit picks sometimes he overreacts over something minor then makes a mountain out of a molehill.

A few examples:

1. I am currently product managing a digital product, as part of the job I am responsible for grooming the product backlog and on a weekly basis plan the team's work for the week. As part of the process, I have to show my plan for the week every Monday morning to my CEO. For the past couple of weeks he has been complaining that the work is not planned how he wants it to be planned, when I have on several occasions made it clear that the whole point of reviewing this at the start of the week is so that I can define the sprint goal. The trouble I am having is that I can't anticipate exactly what he wants, until we actually sit down together and review the product roadmap and backlog.

2. I am in the process of delivering a client's project, the normal protocol is for the CEO to review the first draft of the design work. Since this is DESIGN, it is very difficult to get it perfect the first time due to subjectivity of what a good design is, which is why he is involved in the process. I showed him the design, my designer did 5 versions, and he just kept complaining over minor things. Eventually he just told me to not show him the design work to begin with unless it is perfect. I was left scratching my head, trying to define what 'perfect' is.

In both instances, I sat down and handled the situation by being unresponsive, but deep down, it really annoys me and I am a bit concerned that he is never going to be satisfied. The question is: what is the best way to handle a stakeholder/CEO who just moans all of the time? Is there a way to reduce the moaning?

Answer 1

Stakeholder management 101: define the rules of engagement, define the two-way communication requirements, point out and resolve the inconsistencies in the stakeholder requirements--such as what you pointed out here--and whatever else you need such that you get what you need from the CEO and he gets what he needs from you.

Schedule a meeting or two and work this out. If he refuses to sit down to discuss or continues with inconsistencies, then you have a stakeholder risk and you need to develop other mitigating strategies, including a ton of documentation, ton of email CYAs, bringing others to the meeting to have witnesses, etc. If this returns marginal results, then work a mitigating strategy for yourself, which may include departure.

Remove the emotion as best you can and get creative with your mitigating strategies.

Answer 2

Summary

You must leverage your framework more effectively. This includes pulling your stakeholders into Backlog Refinement and explaining the iterative/incremental nature of the project's delivery framework.

You also need to increase the level of collaboration with the CEO. Being dismissive or using emotion-laden statements like "he moans all the time" are 100% counter-productive, and usually a sign of ineffective communication on both sides.

NB: While you didn't tag the question with agile or scrum, your mention of "backlog grooming" indicates it's some sort of Scrum-like framework. My answer will therefore be tailored for that.

Stakeholders Required for Refinement

I am responsible for grooming the product backlog and on a weekly basis plan the team's work for the week. As part of the process, I have to show my plan for the week every Monday morning to my CEO.

Ouch. No! If you're following Scrum, then the Product Owner should be leading the refinement ceremony, and inviting the rest of the team to participate. If you're doing Backlog Refinement all by yourself, you're Doing Scrum Wrong.™ More importantly, the input to the Product Backlog and the Backlog Refinement ceremony needs to flow from the stakeholders and through the Product Owner.

In your specific case, the CEO is a key stakeholder, but he's not actively participating in defining stories or refining your Product Backlog. This is a problem, because he's waiting until Monday (which is presumably Sprint Planning or your equivalent) to weigh in, rather than getting out in front of things in Backlog Refinement.

You should insist that he take part in refinement. Call it a "pre-planning" meeting if he's not an agilist, or invest the time to explain the differing purposes of the formal ceremonies of your framework.

Explain Iterative Development

[T]he normal protocol is for the CEO to review the first draft of the design work. Since this is DESIGN, it is very difficult to get it perfect the first time due to subjectivity of what a good design is, which is why he is involved in the process. I showed him the design, my designer did 5 versions, and he just kept complaining over minor things.

First of all, "the normal protocol" seems like a project smell. The client should generally be the one reviewing design decisions, because the CEO is not the one ultimately consuming the delivered product. It's likely that the CEO doesn't trust you or the team, and that's something that needs to be addressed. Furthermore, you need to find out why the CEO doesn't want the client reviewing the design. His answer may be useful in deciding how to proceed.

Secondly, regardless of who is reviewing the design, the team and the CEO are not collaborating constructively. That needs to change.

In an iterative delivery model like Scrum, work is done in increments. Whether the increment of work is a design or a slice of functionality is irrelevant. In either case, the team should do the work and then the stakeholders (in this case, the CEO) review it and suggest changes or improvements.

The CEO is free to make an infinite number of changes. It's his company. Your job isn't to stop him from making changes. Instead, your job is to:

• Make the cost of changes visible to the organization.
• Ensure that changes are introduced at framework inflection points like the Sprint Review or Sprint Planning rather than in the middle of an iteration.
• Ensure that everyone (including the CEO) agrees to respect the framework ceremonies, or is willing to accept the costs of introducing change outside the normal cadence.

So, how do you make these things happen? Collaboration and education! Here are some key techniques.

1. Have a conversation with the CEO about how incremental, iterative, and emergent development work together or separately, and how these techniques differ from traditional up-front planning systems.
2. Disintermediate yourself, and have the CEO collaborate with the designers on design.
3. Educate the CEO on framework ceremonies. Ensure he's introducing work during Backlog Refinement or Sprint Planning, and reviewing the increment during Sprint Review.
4. Introduce Acceptance Test Driven Design/Development to encourage a more collaborative approach to product specification.
5. Leverage testable specifications to objectively drive the designers' work, rather than trying to guess what is wanted.
6. Ensure that the team plans the work, rather than trying to digest the requirements and plan the work on the team's behalf.
7. Encourage the CEO to attend the Sprint Planning meetings so that he can see firsthand how his requirements enable or impede the team, and so he can be on hand to answer questions about the work planned for the iteration.

If the CEO is not on board with your current process, then you and he either need to agree on a new process that you can both live with, or you need to resign yourself to the status quo. You can't make anyone do anything, and if you can't collaborate then you can't succeed.

Answer 3

Make sure he has something to provide input on.

Your pitfall is the design-first phase. Apparently it is not an option to rethink design-issues later, so the design has to be perfect.

Tell him you're going to demo the desing in a working model. Start building the product and demo it.

If all goes well, he will at first ask you to adjust the design - and more and more often he will ask you to deliver functionality instead.

This way: * he can see progress * he is in control * he can see the design in a working product instead of documents