One of the greatest challenges for anyone in Information Technology is managing scope. Scope creep is a bane to a project’s success metrics. Scope creep occurs for a variety of reasons like poor change control practices, not understanding project objectives, poor requirements practices, poor communication and even poorly skilled project team members, project managers and business analysts. In a JAD session, where everyone is offering their thoughts and opinions, scope creep can crawl in almost before anyone realizes a topic has veered off course.

In Chapter 3 of the book “Writing Effective Use Cases,” Alistair Cockburn talks about an “absurdly simple and remarkably effective” method to control scope that he learned from consultant Rob Thomsett. The method is so simple, yet proven to be so effective, that it personally led to a true “AHA!” moment for me. The method is called the in/out list. It draws a boundary for meeting participants between what is in scope and what is out of scope for the discussion.

Introduce the in/out list right after establishing the ground rules. Write it on the white board or on flip chart paper and post it for all to see. Allow it to remain visible for the entire discussion. Use a new in/out list at the introduction of any new requirements discovery activity since topics in focus are likely to change every few hours. Give details about the points that are in scope for the current topic of discussion and explain that the out of scope items will be discussed at an appropriate time in a future meeting. Give the audience a chance to acquiesce to or contest the in/out list. Allow time for the group to debate any opposition and concede to consensus.

During the course of the topic’s discussion, someone may bring up an entirely new item for reflection that had not been thought of before. Allow the group to decide if it is in scope for the day’s activities or not. If it is, add it to the in/out list and ask what needs to be dropped to make up the time difference. If the group says no, log it as an open issue and make sure to schedule it for another meeting. The in/out list is effective in any kind of meeting, not just JADs.

The JAD continues with cycles of eliciting, analyzing and documenting requirements. The analysis at this stage is preliminary. A much deeper analysis comes later and will be discussed in the Chapter 6. Analyzing requirements is as much about finding ways to improve business processes as it is about satisfying business need. It is okay to challenge requirements that might not make sense in light of the objectives, current technology or implementation cost. Ask probing questions about why debatable business processes are the way they are and do not accept “because we’ve always done things that way” as the answer. Lead the participants into a process improvement course of action instead of letting them settle for the status quo.

The inclination to cultivate interpersonal conflict is the greatest disadvantage of the JAD. Disagreements between participants may occur in a JAD setting which cannot be settled within the confines of a single session. The scribe logs it as an open issue and the facilitator assigns the disputing parties the task of coming to a single source of truth and reporting the resolution by an agreed upon date. Validate all the activities against the objectives established early in the meeting. Identify the requirements’ critical success factors.

Good requirements are measurable and testable. For every requirement ask two questions: How will we know that the planned changes have been effective? How will success be measured? If break-out sessions are planned, make sure to debrief when they are over. Close the day’s activities by summarizing what happened and what was accomplished. Review any open issues and ensure that each one has an assigned resolver and a resolution date.

When the participants leave, the scribe and BA stay to add the day’s requirements to the BRD if the scribe hasn’t done this in real time during the session. Yes, it is possible to write most of the draft BRD while the JAD is in session. Multi-day JADs begin subsequent days with a review of the prior day’s accomplishments. When the JAD is completely over, follow-up on any remaining open items and complete the BRD. Before sending the BRD out for review by the participants, confirm its readiness through the quality review process described in Chapter 6. If JADs are run effectively and follow-up items resolved quickly, a final BRD can usually be delivered to the participants within 7 to 10 days post JAD, quality check and all.