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 will 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, which is to articulate the problem and determine the scope of the solution.
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 going to deliver, which in my case it was software. However, I made the mistake of “not bothering my sponsor with details” related to the project management and business analysis deliverables. Sure, we created project management artifacts such as the WBS, risk plan, activity list, and the estimates, as well as business analysis artifacts like process, use case, and data models, and the business requirements document to name a few. However, by omitting the “details,” business stakeholders were largely unaware of the massive amount of work that went into getting the software into their hands.
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 entire scope of each case would be created, not just the scope related to the jury panel. 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. But I wonder which government official would listen.
So, the second lesson learned while on jury duty is the importance of first informing stakeholders what the project will deliver before telling them how it will be done Stay tuned for Part 3 in which I will talk about communicating updates.
Don't forget to leave your comments below.