Stakeholder engagement – the collection and interpretation of representative stakeholder requirements – is a key enabler of success when redesigning processes. It is, of course, perfectly (and all too frequently) possible to redesign a process without taking into account stakeholder requirements but to do so presents a risk that is, with a little effort and structure, avoidable.
In my experience, the process redesign projects that fail because of “stakeholder issues” fall roughly into one of two camps;
Neither of these positions is desirable, and both can be mitigated.
Effective process design requires an understanding of the needs of all stakeholders, but before you can engage with them to understand their needs they need to be identified, and before you can identify them, you need to be clear on what it is you’re trying to accomplish in the first place.
I’ve lost count of the number of occasions I’ve helped clients pull back from near disaster because they didn’t take the time to answer the question: What are we trying to accomplish by undertaking this redesign activity? The reason this is so important is that it colours every aspect of the project going forward, including how you engage with your stakeholders and without answering this question, you can’t possibly hope to know if your project has been a success.
Once you have established your objectives, it’s time to identify your stakeholders. It’s worth taking some time to do this as they may include parties beyond the immediately obvious ones. At PMI, we use the SIPOC method (Suppliers, Inputs, Processes, Outputs, Customers) to do this. Using such a structure can help you to identify stakeholders throughout the process whilst remaining focused.
Designing your stakeholder requirements capture method does not have to be particularly sophisticated, but it does need to be structured and consistent to produce meaningful results. Typical methods include interviews and questionnaires etc. It’s important to resist the temptation to be biased as you write these, and try as far as possible to keep the same structure for each stakeholder.
Once you’ve captured your stakeholder requirements, you are faced with the most challenging element; interpreting the results and choosing what to act on. At this stage, achieving balance is everything; don’t let the stakeholder who shouted the loudest derail you. Remind yourself of what you’re trying to accomplish and select only those items of feedback that are going to help you to do this. Remember too, that the best-designed processes are both effective and efficient.
I’ve seen clients debilitate themselves with the best of intentions by putting the customer needs above all other stakeholders and failing to consider both efficiency and effectiveness of the resulting process. At the other end of the scale, I was recently told by a client who was redesigning a process that, having interviewed his stakeholder, he’d identified that the board wanted 20% savings and the customer wanted better reliability. He’d deduced that the two were not achievable, and as he worked for the board, the board won! Balance is key.
Finally, there’s the important job of letting stakeholders know what you’ve done with their feedback and why. Sometimes this is not practical or possible, but when it is, you should. Letting people know what the outcomes were is key to engaging them in the operation of the newly designed process.
You don’t have to please all stakeholders all of the time, but you do need to have data-based justification for your decisions. Stakeholders have the power to make your new process sink or swim, so whilst they might not always necessarily like what they hear, they will value you reaching out to them, and let’s face it, they’ll find out in the end anyway!
So, what lessons are there here for those involved in process design and improvement?
Like it? Share it!