Lessons Learned on Jury Duty Part 1 – Why Do We Have To Wait So Long?!

The reality of a jury trial is different from what we see on TV or read in books, where the action moves quickly towards the acquittal or conviction of the defendant. On TV the opening arguments, the witness interrogation, and the closing arguments are all pertinent and exciting. Of course, on TV and in books trials are filled with action, with both sides winning points, stumbling, and articulating coherent and often poignant arguments. Oh, the fast-paced drama of it all.

So when I was summoned for jury duty, my expectation was that while there might be some down time waiting to be selected for a jury panel, once picked, things would move along quickly. Reality, not surprisingly, proved quite different. Perhaps some trials are filled with drama, interesting cross-examinations, and surprise endings. But my experience as a jury panelist was, for the most part, all about waiting.

What business analysis and project management lessons, then, can we learn from waiting? Here is the first one—remember that our stakeholders are waiting, too. Years ago the sponsor of a large project I managed handed me a Dilbert cartoon, the gist of which was that the less we know about something, the less amount of time we expect its development to take. My sponsor was telling me that he recognized the trap he was falling into–that because he did not understand the complexities of software development, he couldn’t imagine how it could take so long to develop the new application.

During jury duty, after 36 of us had been selected as potential jurors for a criminal trial, we were escorted outside the assigned courtroom to wait until we were called. Someone verbalized his frustration with the process. “What a waste of our time,” he complained. “No doubt the judge is having a martini lunch,” and so on. When we were finally seated in the courtroom, the judge explained the rules we were to follow and immediately dismissed us for a 25 minute break. The person who seemed frustrated before became infuriated. He poured out invective against all lawyers, court clerks, court officials, and public servants. It seemed to me, though, that there were several possibilities for the delay. None of us potential jurors knew what was happening behind the scenes, but that did not mean that there was no activity. It simply meant that we were unaware of what those activities were.

Most stakeholders don’t understand our processes and how long it takes to develop the end solution. After meeting with a business analyst or project manager, our stakeholders are often left to wait. We do our business analysis or project management work while they wait. We’re busy. The development team is busy. The product owner, if there is one, is busy. But the end users, having no idea of the complexities we face, just might be wondering what we’re doing and why they can’t have their end product sooner.
I worked on a project with a full-time product owner assigned, a retail buyer who was lent to us for the duration of the project. After spending a week collocated with us, she exclaimed, “I wish all the buyers could spend time in IT. I had no idea things were so complex! No amount of training in being a BA or PM could have prepared me for how much work is involved in getting the requirements and developing the system. I’m beginning to understand why things take so long.

Without training our SMEs or product owners to actually be business analysts or project managers, what can we do? One thing we might try is to offer our stakeholders the opportunity to spend time in our work areas. Offer them the chance to observe us. Throughout my career, both as a BA and a PM, I have learned invaluable information when I have been able to observe stakeholders working in their areas. Observation has provided an opportunity to better know some of my stakeholders. It has been a way not only to build trust, but get information I could not obtain in any other way. It’s been a chance to learn about work-arounds, as well as issues and frustrations end-users encounter with their systems. It’s one of the best ways I know to build trust while learning about the “as-is.”

When stakeholders spend time with us, observing us while we do our work, they have an opportunity to get a glimpse of our work from another perspective. The wider their understanding and the more complexities they observe, the greater their patience and acceptance are apt to be. By providing them an opportunity to attend all the non-elicitation meetings, to be present when we develop/review data, process, and use case models, to listen as we interact with and answer questions from other team members like the project manager and the technical people, we are providing a viewpoint that few people outside the development team have, and it’s a glorious way to build understanding and trust. So the lesson learned is the importance of trying to empathize with our stakeholders’ likely frustration with the waiting involved in their projects. Stay tuned for the next blog in which I will discuss the second lesson I learned from jury duty, the importance of communicating the whole project scope.

Don’t forget to leave your comments below.