When doing business analysis and process/solution design, I have encountered various situations with clients. Each of these situations required me and my team to come up with smart ways to come up with a desired future view, with the right consensus from the key stakeholders of the client.
Some of these ways failed terribly. Some succeeded. Which, of course, triggered me to try to understand what may have caused this. My preliminary analysis has brought many points, and I want to cover one of these in this blog-item: how to pick the right analysis & design approach for the given stakeholder situation.
Recently I was interviewed, and the interviewer asked me when I would choose what type of analysis & design approach. We came up with the following model:
Two axis (how I love these models :-)):
1. Stakeholder availability
This one is a clear one, and often an issue for process or solution design teams. In many situations, the time we want from our stakeholders is more than they can or are willing to give us, due to other priorities.
For instance, in a previous project, the department we were working for, was also struggling with a reorganization, a management change and various changing legislation, that all needed attention. The result: we had limited access to key subject matter experts. Trying to schedule long workshops would not have worked.
2. Stakeholder ability to envision what they want and to formulate it
This one is more tricky. It has to do with the complex mix of people involved in your project. How much knowledge do they have of the current situation? How open are they to innovation? How much knowledge do they have of their pain points? How much capability to see other ways/possible improvements?
For instance, in a previous project, a bank wanted to adopt a document management systeem, with scanning software, to digitally route documents and create more complete customer views. Their knowledge and experience in document management, and in these IT-changes was very limited. Asking them what they wanted would not have given valuable answers. Even in terms of requirements, they needed a lot of work.
My belief is that in the combination of these two variables, one can find four main approaches for analysis and design of a desired future.
A. High ability, High availability: co-creation
A dream for many designers. Working with people that know what they want, and might even know how they want it, and enough time to dive into details. For me, the approach in this situation is co-creation, in which the competences of the stakeholders combined with the A&D-team are leveraged to come up with the desired future. I usually work with groups and iterations, using facilitated sessions and various work-forms.
In some cases, the A&D-team could even revert back to a pure facilitation-position, but many times still will need to bring in feedback around feasibility.
In my days of BPR/Rapid Application Development, we often could run 2 - 3 week workshop weeks, where we had a full team of stakeholders. Great times, but I see less and less of this, unfortunately.
B. High ability, Low availability: rapid elicitation and design validations
This situation I encountered at a Investment department of an insurance company. These people were security traders, were earning lots of money per hour for the company, and could hardly be missed. They fortunately had a very sharp eye on the issues and required changes in processes and IT-systems.
In this model I choose for one-on-one short interviews and quick validation sessions using very concrete results (prototypes).
C. Low ability, High Availability: Empowerment and stepwise 'Co-invention'
This is a situation I am currently in with a client. We are getting time from a number of people, with sufficient knowledge of the current situation, some knowledge of pain points, but also a lack of understanding of possibilities. And even: in same cases they have gotten used to certain pain points and take them for granted.
Their ability to envision and formulate a desired future is limited (but growing!)
The key point is: people can, and often like to grow. Another key point: all people can contribute value. It is easy to fall in the consultant arrogance-trap 'They don't know, so we will tell them what they want'. This often fails. And if it succeeds, certain gems that the stakeholders could have brought, are lost.
The approach we have chosen in this situation: empower these people with knowledge (solution concepts, technology, requirements formulation, etc.). And work with them, to define, in steps, the desired future, firmly from their perspective and starting points. Make them discover parts of it, by feeding them with concrete possibilities, and then translate back to requirements. In our situation this approach has given many new insights, that were also unknown to us!
D: Low ability, low availability: Trust based best practice injection
So you are given a client, with no time, a burning need, but no real capacity to define the desired future (only to a certain high level extend). Ouch. In this case, the key factors are trust and the availability of certain best practices, proven to work in the client's context. The approach is to adopt a certain best practice framework, and simply go do it. Implement, perhaps in pilot forms, and then learn, adapt, and extend.
A third factor: the domain/technology knowledge of your team
A factor that also influences these choices is the knowledge and experience in your analysis&design team.
If the knowledge in your team is high, all approaches above will work.
Is the knowledge in your team low, then....
- Option A is only possible, if the client accepts your team as purely facilitating (and your team learns very quickly)
- Option B will become demanding. Challenge: how to get the respect of these visionary professionals?
- Option C will become time-consuming, as both the client and your team will need to learn. Challenge: do you have the time, and does your client have the money and willingness?
- Option D will become very risky, don't go there.
My conclusion: pick the right approach for the right condition! And tell me what you think....
No comments:
Post a Comment