As part of an organisational change endeavour, I’ve been designing and running a series of sessions for individuals taking up the Business Systems Analyst role within our projects. As I’ve been doing this I’ve been encountering specific ways of thinking about things that have been implied in my head but have been implicitly written down as this process has unfolded.
Collect, Question and Confirm
When developing the discovery session for the series I communicated how requirements gathering has a strategic sense of progress. This way of framing discovery impacts how the client is engaged, the nature of the conversation and the tools used and gives context to everything we do in discovery.
The way I framed this is via three pillars: collect, question or confirm. The discovery process is very much one of moving from left to right through these pillars.
Thinking this way provides a steering mechanism that drives the approach and supporting elements of discovery as you want to get to confirm as quickly as possible. The closer you can be to confirm at the start of discovery the better position all the stakeholders are in.
The impact on the conversation
Discovery is a conversation and you want that conversation to be as rich and accurate as possible at any particular time. This is because the deeper, richer and more accurate the conversation is the more trust that is built with the stakeholders.
The journey from collect to confirm is a journey of trust building
Spending too long in collect and question can be a morale issue for the stakeholders and team. Sitting at collection feels like you’re at the foot of a mountain you’ve yet to climb and you don’t really feel like you’re enjoying the views at the top and the leisurely walk down until things enter the confirmation stage and you start to reap the benefits of that.
The longer it takes to get to confirm also adds to the length of time before the stakeholders see value from the project whether it is revenue recognition for the internal stakeholders or the value propositions on which the ‘customer’ entered into the engagement in the first place.
So, how do you expedite the journey to confirm?
Maximise pre-sales
The biggest win is to have as significant a percentage of discovery within the confirm pillar coming out of pre-project engagements. We are going to assume this is a sales process here but it can be internal engagement opportunities depending on the nature of the project and the business environment.
Whether this is possible depends on the nature of the sales engagement as it could be anything from a blind tender process to one that has involved significant pre-sales consultancy and sandbox work that may have elements starting to edge into the design and build.
If it’s the latter you could be onto a win by carrying over the trust from that process and maintaining the momentum by making sure that process is used to get as many parts of discovery as close to the confirm pillar as possible. This you have to do, as in this scenario, if the transfer does not happen, trust can go in reverse.
While a heavy amount of pre-sales consultancy may have incurred a significant cost of sale you can make that cost worth every penny now.
You need collection artefacts
As well as framing progression through discovery I also wanted to give the various artefacts used within the project a better context than just being a long list separated out by stage. This proved quite easy to do and I believe it was more helpful in delivering the sessions than just a phase-by-phase understanding.
Ultimately, I suggested the various artefacts could be looked at through the lens of guide, control or collect.
Sometimes a document might serve two purposes. An example of this might be an interview guide, which can serve to guide those delivering but can also be a collection artefact if sent to stakeholders and subject matter experts.
The key thing is to have documents that facilitate collection at scale.
As an example, if you’re solution has a reporting element you may want an artefact to collect the business’s critical reports at scale across purpose, dimensions, metrics, etc, so these can be analysed and fed into actual requirements moving you to question and rapidly into confirm for the reporting element of discovery.
It’s highly likely you can architect documents along similar lines for other functional areas.
Accept you need to collect
Ideally, you’d not face an almost blind collection-at-scale situation. This might be for a number of reasons: –
- Pre-sales engagement and sandboxes
- Business vertical knowledge within the team
- The client follows repeatable or established patterns
All these things get you earlier into question and confirm, but it’s important to accept and realise that collection at scale is sometimes needed or may well be wise anyway to give your questions a very high level of specificity, authority and direction.
This is why the collection documents should be sent early in the engagement. You want to avoid extensive questioning before sending the mass collection documents because it’s proving slow as this can weaken the level of engagement the stakeholders have with your collection artefacts.
The other useful outcome of using the mass collection artefacts is, like a lot of artefacts in a delivery methodology, they serve a dual purpose. They are used for mass collection in the early phases of the project but move into control later as they become an understanding of the scope and serve a control purpose (supporting the official requirements document)
In Conclusion…
It’s useful to see the discovery process as moving through the pillars of collect, question and confirm. Primarily because you can then shape your approach, methodology and artefacts to get to a position of confirming as efficiently as possible.
You could even use these pillars as a visual to move elements of discovery across the pillars recognising reporting is in confirm, but data is still in question, etc.
The reason you want to do this is discovery is a conversation that builds trust and that trust builds the sooner the customer feels the team understands their world and their challenges and this becomes more true the more you’ve moved from left to right along the pillars.
This means you should begin this process ideally before the project starts so the project can carry forward the wins from that previous engagement and you should have artefacts in the methodology that facilitate mass collection when needed to allow the process to move to questioning with specificity, authority and direction.
