On a recent project, I was sitting in a room full of subject matter experts (SMEs), trying to document a business process using the trusty Process Flow model, when trouble struck. Before the meeting, the team was “lucky” enough to discover process flows for the very process we were focusing on; the only issue was these flows were created a year ago and had since gone out-of-date. With these flows in hand, it seemed like an obvious choice to begin by reviewing them with the SMEs, to see what process steps needed to change. While this choice may have seemed obvious, it turned out that we were creating twice as much work for ourselves.
As the session began, I announced that we would review each step of the existing process and then discuss which areas, in sequential order, needed to be updated. Our SMEs nodded in agreement, but once I had finished walking through the old flow, I was met with a roomful of blank stares, followed by the following comments: “Wait a minute, where in the overall process does this happen?”, “What does step #3 mean?”, “Hold on, I’m not sure a report mentioned in the existing flow is still needed, I will need to contact another resource to confirm”…and so it went for 20 minutes as SMEs struggled to understand the old flow, and orient themselves in today’s current state process. What a mess!
Because we had scoped the project as a simple update effort, not a complete teardown and rebuild of the models, the team suddenly became strapped for time. It was only when I suggested that we step away from the old flows and start with a clean slate that our SMEs started to understand and contribute. While it may have taken an extra 15 minutes of in-meeting model-making time, we were much more efficient then we would have been if we continued to fight with the existing models.
This counter-intuitive example directly contradicts my established thinking about stakeholder elicitation. I had held it as an article of faith that no worthy Business Analyst or Project Manager should ever, and I mean EVER, enter an elicitation session with a blank slate. In my experience, a blank slate can be one of the most frustrating starting points for any group trying to define a solution. Without a clear starting point, how does a group of SMEs know where to go next? To counteract “Blank Slate Shock”, I always put together “straw man” models that would represent my best guess at the topic to be documented, and then let SMEs tear it apart, replacing any speculative info with the cold, hard facts.
But these cold, hard facts were just not materializing, so it was time to trash the rulebook and go rouge! With my blank slate in hand (on the projector screen), I began to ask questions like “What triggers this process?” Once I got an answer, I added it to the blank slate, moving on to my next question: “So now, what happens next?” Once we decided on an answer, I added that to the blank slate, rinsing, and repeating the phrase, “And then what happens next?” until we had reached the end of our flow, and our meeting time. Crisis averted!
It was then that I learned the two main rules of requirements elicitation: “Think on your feet” and “Always, always have a Plan B”.
business analysis, business analyst, Business Analysts, Elicitation, models, Process, product manager, project management, requirement documentation, requirement models, requirements, requirements analyst, requirements documentation, requirements elicitation, Requirements engineering, software requirements