Extracting business requirements from workshop sessions sometimes feels like we should be qualified FBI agents, not IT consultants. We often talk internally about the soft skills required during client interactions that ensure we have all the necessary information to design and build great solutions. Detailed workshop time is the focus of these requirement gathering exercises and the techniques we employ at this stage are crucial to delivering on the clients expectations.
But what is it that causes us to miss things or misinterpret client needs? Why is it, that on a late night session the day before go-live, an innocent throw-away comment from the client causes the whole project team to drop their bacon sandwiches? “You need what?”.
During after-hours pub talk recently, a client shared his frustration of this problem and how it affected his own internal communications and projects. He called it the ‘Rabbit in the freezer’ enigma. It goes something like this:
Shopper: “Do you have any rabbits”
Shopper: “Oh, a friend said you had rabbits”
Butcher: “No rabbits”
Shopper: “Do you have any dead rabbits?”
Butcher: “No rabbits, no dead rabbits”
Shopper: “Do you have any rabbits in the freezer”
Butcher: “No. No rabbits in the freezer”
Shopper: “Most odd, because I’m sure I heard you had some. Are you sure?”
Shopper: “Well do you have any dead rabbits, brown and white ones, that were killed during the hunt last weekend, that Toby skinned and butchered into individual portions, popped into freezer bags, and are now stored in the deep freezer, just out back in the garage area, next to the beer fridge?”
Butcher: “Oh, those rabbits, why didn’t you say that?”
Or, if you don’t ask the right question, you don’t get the right answer. And because the wrong answer, or no answer, causes us problems down-stream, the joke evolved in our office that the ‘rabbit’ was inter-changeable with ‘hand-grenade’. I exaggerate to make the point; and despite frustrations, it really isn’t the butcher’s fault. In reality it manifests itself, not in completely new unknown hand grenades, but in subtle variations to processes or output that the client might reasonably have expected us to be on top of. And that is our challenge and our learning curve. How do we continually adjust and adapt our approach with different clients and different individuals to ensure that we find all the rabbits on first pass?
In natural project lifecycles we never face the same situation and people twice so there is no formula for a fix. Lessons learned certainly, but no check list that, once ticked, avoids all risk. There are however some usual suspects here. It’s rare to get individuals that deliberately with-hold information, but it has happened. Perhaps more common is that some voices get lost or are overpowered by more outgoing and vocal members of the project team. Or perhaps we are asking the wrong questions, not steering the conversation where it needs to go in order to extract the necessary responses. It is not about good or bad requirements, or in and out of scope debates, it is an issue of knowledge and understanding. To lean on Donald Rumsfeld here, we need to make sure that at the end of the day we have no known unknowns. And when I know them, I must be 100% sure that I understand them.
I don’t mean this blog to be the last word on avoiding these pitfalls, but I’ll share some tangible techniques we employ, as best we can, to minimise our rabbit-risk.
- To understand the conversation, we want to be part of the customers’ tribe. I think as with most practices, domain expert consultants are expected and provided, but every day is a school day, so immersing ourselves in the language of clients and maintaining a ready-to-learn mind-set ensures we engage on the right level.
- We try to keep workshop sizes compact and qualify hard with the client the personnel that will attend to ensure they are well briefed and understand the process and objectives. I won’t quantify what too big looks like, but we know it when we see it. In that case, we’d try to drive a breakdown of the work stream into something more granular to ensure we get a voice from all corners.
- We promote inclusion at all levels. Sure, the stakeholders and project sponsors are driving the direction and strategy, but I bet my house that whispering Bob, sat in the corner where I can’t catch his eye, and who hasn’t volunteered anything to the session so far, knows more about day to day operations than anyone. We need his input too.
- We invest a lot of time in internal cross stream discussions and knowledge sharing away from the client. Even with clear delineation between, say, a finance consultants’ processes and the order-to-cash team, it’s amazing how much cross-over there really is and how many process quirks or queries get ironed out with these discussions.
- We put two consultants in every workshop, in a ‘lead’ and ‘buddy’ structure. Again, that extra pair of eyes and ears really does de-risk any oversight or process gaps. They provide the, “Let’s look at this problem another way / Let’s ask this question differently…” option. Or even, “Adam, you forgot to ask about…”.
- If there is even of whiff of misunderstanding, let’s ask the same (re-worded) question twice. Qualify, qualify, qualify. This can be tricky. We want to extract well qualified information, whilst at the same time steering the client towards best practice and we also want to impart some value-add by bringing our own experience to the table. There is a fine middle ground between doing that and being patronising at one end or arrogant at the other. Spinning those plates successfully is the foundation of a great client / consultant relationship.
- It depends on the exact need, but we have a made a general move away from burdensome functional requirement documentation. Trying to capture every last requirement and scenario in written word is not always efficient, so we are often favouring early prototyping and playback to increase client engagement and weed out the gaps (rabbits) earlier upstream. This is an evolving change made possible by faster Cloud deployment cycles, particularly suited to near vanilla projects, but it is a change that we embrace and are keen to explore more in forthcoming projects.
Of course, it’s not fool proof. Being agile enough to adapt to unexpected changes in requirements, either new or unforeseen, remains a key part of the methodology and mind-set. One way or another though, I am grateful that the number of times I get a call from the project manager saying, “We’ve just found another rabbit in the freezer”, are now few and far between.