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;
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 identifying, 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 the way in which 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 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 focussed.
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 is 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 is 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?
Rich Seddon is Managing Partner at Process Management International (PMI) and a specialist in strategy design, operational efficiency, management of change and customer focussed process design. He works around the world with clients in all stages of programme maturity.