What Did the Senior Know?
It is important to remember that soft skills determine how our stakeholders judge our performance. This is not merely a case of an empty “image” or perception. Our soft skills actually make the biggest difference in our ability to elicit and build consensus around quality requirements. Most stakeholders WANT their projects to make sense, and don’t want to waste time. If we cannot handle “requirements nonsense” without giving offense, we lose momentum and influence with our stakeholders.
The following true story (all names and dates are changed or not revealed) illustrates the difference between “junior” and “senior” performance levels.
In 2007 a large government agency restarted a workflow automation project that had repeatedly failed for more than 10 years. Every attempt to deliver a set of acceptable, feasible requirements had resulted in nothing – zero, zip, nada. The most recent attempt had taken two years, and was contracted to a very large consulting firm. The only deliverable deemed acceptable after all this effort was a “high level” requirements document, barely more than a vision, a few business requirements and a smattering of technical requirements.
The diagnosis was that the problem the project was trying to solve was extremely complex. It was so complex that meetings to discuss requirements bogged down in endless discussions of seemingly infinite details. The stakeholders and the analysts were all overwhelmed by the complexity.
The solution was to narrow the scope and break it into more parts (good idea) and to elicit the requirements from stakeholders by using a GUI prototype. A new contractor was selected that had a junior BA with GUI prototyping skills.
Just before the project kicked off, the government insisted that a Senior BA be hired, and this was done. The junior BA was assigned to facilitate stakeholder meetings and create all the GUI prototypes, and the Senior BA (being the outsider on the team) was instructed to capture notes from the meetings and to produce the final deliverable requirements document.
As the stakeholder GUI sessions were held, it became apparent that there were misunderstandings between the facilitator and the stakeholders. The facilitator got trapped in discussions trying to explain the GUI and what it meant. The facilitator (a GUI expert) was convinced that once the stakeholders understood the GUI concepts that they would agree that the facilitator had gotten it right. Because of the confusion, the stakeholders would insist on GUI changes one week, and then they would insist on reverting to the prior version the very next week. Everyone was talking at cross-purposes, and intervention by the Senior BA was NOT welcomed. The Senior BA patiently bided his time, always collecting requirements, regardless of surface chaos. The contract was to produce a requirements “deliverable”, and as long as that could be done there was no need to insist on intervention – it was enough to offer suggestions and, then let it go.
This went on for weeks, causing great stress to the junior BA. The Senior BA continued to prepare the requirements for delivery and review with stakeholders, confident that correct requirements were becoming apparent in spite of the debates, and that these could be analyzed and presented in a clear way, eliminating confusion.
When the time came to present a “to-be” requirements model, the Senior BA was ready. In one afternoon, after weeks of unending debate, the Senior BA presented the requirements as they were understood from the many “GUI meetings”, but did so without using GUIs – can you guess how?
The nature of the stakeholder discussion immediately changed. Suddenly the stakeholders were excited to update the requirements and to hold the next review. While there were still disagreements and frustrations to be worked out, these were now focused on larger, more important issues. Instead of fighting minor issues related to data “labeling” vs. content, or the difference between a “workflow status” and the work’s physical location, stakeholders were now trying to decide what steps in the existing, broken process needed to change, which steps needed to be eliminated, and which needed to be enhanced.
What was the difference? How was trust lost by the junior BA, and how could they have gotten it back? What role could improved listening skills have played in helping the junior BA to get past the misunderstanding? Would the junior BA alone have been able to complete the requirements without serious errors and gaps, given the confusion around larger issues and too much focus on “small” issues? The Senior BA did nothing directly to resolve the issues – how were the issues resolved so quickly?
What? No answers? Yes, just questions. If you think you know some of the answers, please leave a comment.
To make up for this slime ball move, making you do the thinking, I offer a free joke (groaning is also best done with a comment, no threats please J):
Q: Why did the BA cross the road?
A: BOK, bok, bok, bok, bok!
Don’t forget to leave your comments below.