Project Management Lessons Learned During Jury Duty

Part 2—Communicate Complete Project Scope

 In Part 1 of this jury duty blog I discussed how, when called to serve for jury duty, I had no idea that so much of my time would be spent waiting for something to happen. I compared this wait time to what many of our business stakeholders experience waiting for their end product. In Part 2 I will examine the importance of understanding and communicating the whole project scope.

Communicate the scope before tasks

When we reported for jury duty, we were told to wait in a large room with over a hundred other potential jurors. We were shown a video about the jury process with high-level tasks, but not the scope of our service. It would have been helpful to know the entire extent of our involvement if we were selected, rather than how we would be sworn in or the details of going through security.

So what is scope? We have found in our project management training courses that some project managers confuse tasks with scope. Project managers often think of the Work Breakdown Structure (WBS) as a list of tasks, not a hierarchy of deliverables, and they assume scope means all the tasks that will be completed on the project.  Scope is not the activities that are performed, but rather the deliverables that are produced. Scope is comprised of things, of outcomes– nouns not verbs. In our jury example I would have liked to know that if chosen, my involvement would include jury panel selection, security screening, jury questioning (voire dire), jury selection, presentation of evidence, deliberation, and dismissal. This information would have given me the big picture and would have helped set my expectations.

On our projects we often focus on tasks before we understand the scope. We look at the end date and try to figure out the quickest path to get there—without always spending enough time getting agreement on what is going to be waiting for us at the end of the journey. There are lots of compelling reasons for this. For example, our sponsor and business stakeholders often provide not only the solution, but also the end date. So we question the value of spending time defining the problem, determining what solution best solves that problem, and how long that solution will likely take to build. Although we understand the risks of not meeting stakeholder expectations, of focusing on getting the tasks done on time, we often lack the courage to influence our stakeholders to step back and do the best thing for the organization.

Communicate the scope of the project, not just the scope of the end product

On most of my projects I have gotten sponsor agreement on the scope of the product. It was always clear what we were producing, which in my case was software. However, as a project manager I did not consistently communicate the scope of the effort to produce that end result. We certainly created project management deliverables, such as the risk plan, activity list, and the estimates, as well as phase deliverables, such as a data model, the business requirements document, and the system test plan to name a few. However, I made the mistake of “not bothering my sponsor with details” related to the internal deliverables, so that the business stakeholders were largely unaware of the massive amount of work that went into getting the software into their hands.

Performing jury duty was part of a larger project, but we had no idea what was included. We spent most of our time waiting in a hall outside the assigned courtroom. We had been only partially informed of our scope and were totally in the dark about the other related pieces. Every once in a while, as we waited in the hallway, the courtroom door would open and we’d catch a glimpse of activity. We saw police or family members, clerks—lots of comings and goings. However, we were not even sure this activity related to our case. As I wrote in Part 1, because we had so little information, all the time we spent waiting led some potential jurors to articulate their frustration about the lack of productivity of the lawyers, clerks, and judges.

Scope on Agile projects

One of the many aspects of Agile projects that I find appealing is the concept of transparency. Informing stakeholders is fundamental to and built into the Agile processes. Among the techniques used to promote transparency is the team wall, which is visible for everyone in the organization to view.

Included on the team wall is the product scope. Although we don’t often use the word “scope” on an Agile project, and although the scope can change after each iteration, it does exist. Scope on Agile projects is usually comprised of what are called user stories. These stories are high-level requirements often written to show the role of the end user, their goal, and the benefit to them. These stories are arranged in three columns or groups, including those that haven’t been started, those in progress, and those that have been completed.

I can only imagine the advantage to potential jurors if the scope of the jury “project” were transparent and if the process were handled in a more agile fashion. Let’s say, for example, the pending court cases were posted on a “team” wall. The scope of each case would be laid out like an Agile project, with the pending cases in one column, cases in-progress would be in another column, and those completed for the week in a third column. The scope of each case would be created, not just the scope related to the jury panel, but for the entire case. As new information became available, the team wall would be updated. When the jury panel was called, resources would be assigned to the case or “project,” and the team wall would reflect these assignments. Perhaps I should suggest this approach. Would anyone listen?