Imagine the scene: A significant project is underway, and you are leading the detailed analysis. You create your business analysis work-plan, and decide to start the initial requirements elicitation by meeting and interviewing a few key stakeholders. You then plan to hold a series of workshops to refine the requirements and obtain sign off, perhaps bringing in some other domain experts along the way.
The project timeline is challenging, but you can just about make the deadline…
Then you realise all of your key stakeholders are away at a leadership conference for the next three weeks.
What’s a BA to do?
You know two of them quite well, and they agree to block out 20 minutes one day for a short phone call. They explain that the vast majority of the stakeholders are keen on the project, and will make time to see you after the conference, but they explain that since this conference has been in the diary for 12 months, it just can’t be moved. Nor can the stakeholders squeeze any more time for you during the conference, as the schedule is so packed.
As you walk back to your desk, you have that sinking feeling: “What on earth can I do for the next three weeks?” After all, surely stakeholders are key to requirements elicitation, right?
Well – yes and no. As BABOK reminds us, there are so many elicitation techniques, and whilst workshops and interviews are used extremely frequently, there are many others that we might choose to employ. In this article, I will describe three elicitation techniques you can do without access to your stakeholders. It’s unlikely that any technique will stand on its own, the key to good elicitation is using the right blend, but these three can be particularly useful when stakeholders time is scarce.
#1 – Domain Research / Competitor Analysis
When projects start, particularly when stakeholders are unavailable, it can be useful to ask the question “how do our competitors solve the problem we’re trying to address with this project”. Depending on the domain, it can be useful to visit their websites, stores or branches to get a sense of their products and processes.
- What have they done well, and not so well? What type of data seems noteworthy?
- What business rules do they seem to have employed?
The idea here is not to copy or re-use, but to get a sense of the likely requirement areas that might be relevant.
#2 – Document Analysis and Organisational Research
Large organisations often contain hidden information goldmines in the shape of process documents, previous requirements documents, business architecture diagrams and so on. It’s well worth asking what existing documents are available about the “as is” picture.
Often documents like this are left languishing on dusty shelves – so they might be out of date – but they can be a useful starting point. As analysts, they help us to formulate the best questions to ask when our stakeholders become available again. They might also help us to determine some of the existing process requirements which may need to be considered in any new or updated system.
#3 – Observation
On projects of all types, it can be extremely powerful to simply go and observe end users or workers, and see how their processes and systems actually work. End-users are normally extremely knowledgeable, yet sadly sometimes they fall into the “high interest, low influence” stakeholder category – they certainly care about the target solution (as they will need to work with it), but the decisions are being made elsewhere (perhaps by the sponsor, subject matter experts, and other domain experts).
When this is the case it’s even more valuable to see how they work, understand their day-to-day pain, and understand how they perceive the problem. This should always be done with fore-warning and permission of their managers, and it’s vital to build rapport and explain why you’re there. As with the other techniques mentioned, observation can help us to gain a greater understanding of the problem which we can refine by using other techniques.
And Then Validate What You Learn With Key Stakeholders
These are just three elicitation techniques you can work through without engagement from your key stakeholders. There are certainly others. These techniques can be useful when used alongside interviews or workshops.
One final point: the scenario I painted above was one involving temporary stakeholder absence, which is a challenge that we can work around. If stakeholders are continually unavailable, this might suggest a deeper-rooted problem and may require a different type of intervention by the project team. This might involve by gaining their buy-in (with the help of the sponsor), or maybe even delaying the project completely (if it isn’t essential to progress it now, and if availability will increase in a few weeks’ time).
In summary: stakeholder involvement is clearly crucial to elicitation, but there are other techniques that we can use too. The key is to use the right blend at the right time.