As promised in my post on IT Facilitation Skills, this article will take a more “hands-on” look at conducting JAD workshop sessions. While there is no single “best” way to accomplish JAD objectives, I will try to present a format that has worked nicely for me in the past, in the hopes that it will give you some ideas as to how best to structure your own sessions.
JAD (Joint Application Design), is a software design process which attempts to bring together various business stakeholders (most likely users) and IT professionals in a highly focused workshop environment. Why do we prefer this format? Well, in the old days (gee, all of 10 or 15 years ago) most sets of functional requirements were cobbled up by business analysts and “tossed” over the wall to the software engineers, whereupon we were supposed to plop a handful of arcane ingredients into a big pot, mutter a few incoherent passages from Ken Thompson’s UNIX Philosophy and stir until some magic software solution poofed out of it. Alas, the road to JAD is paved with the morasses of projects past that have stemmed from poor requirements gathering.
Of course, the problem with this is obvious – business analysts are generally not technologists, and vice-versa. Business personnel are not necessarily adept at taking into account technical constraints/limitations, best practices, or the newest innovations. Likewise, technologists have not historically been overly proficient at cobbling together business requirements. It has been unequivocally proven that by bringing both sides of the house together to define the requirements that a vast majority of common problems and misunderstandings can be dealt with up front (where they cost $1,000), rather than in the 47th week of the project (where they cost $1.3M).
Make no mistake, JAD is not the panacea for software development, or even requirements gathering, for that matter. It can, however, provide a pretty good path of least resistance. Theoretically speaking, the big advantage of JAD is accuracy, or the ability to deliver a system with the functionality that is actually needed. In addition, JAD affords you with a dramatic shortening of the time it takes to complete a project (due to having tighter functional specs up front). Of course, your mileage may vary – I have found that having a very experienced facilitator goes a long way toward determining the eventual impact of the session(s). The use of JAD also improves the quality of the final product by focusing on the gathering of accurate requirements, thus reducing the likelihood of errors that are expensive to correct later on.
Much of this information is taken from “consulting 101” – if you have some business background, a lot of the initial concepts may be familiar to you. But keep reading – we’ll get vertical soon enough. I apologize in advance for this article’s length, but I don’t believe in “blogging for blogging’s sake.” I prefer my blog entries to have substance and value. I hope you will agree!
As any experienced facilitator will tell you, quite a bit of the work effort you will put in will occur well before the sessions even begin.
The very first thing that the facilitator needs to do is to ensure that he/she fully understands the context of the business problem being addressed. Note that I did not say that “granular industry knowledge” was necessary, nor did I mention anything about the facilitator having technical prowess. The focus here should be on understanding the context of the business problem.
What is the problem we are dealing with here? Who is affected by it? What are we trying to accomplish. What stakeholders will be affected by this system, and how many of them will attend the session(s)?
Once you have a grasp of the breadth of things, you will be in a position to direct the subject matter experts to drill down vertically into the problem. Interviewing various stakeholders is a good way to cobble up the knowledge that you need – this can usually be done pretty quickly.
Don’t be surprised, however, if you get to day one of the session and realize that you overlooked an important aspect of the group dynamic or the business problem. This can (and will) happen. Just prepare yourself as best as you can up front, and be prepared to augment that knowledge with things you pick up on-the-fly during the session.
As far as physical, tangible items goes, here is a list of items that I have found to be helpful during a JAD session:
As a starting point, I like to break down requirements gathering into two distinct phases – both phases consisting of facilitated JAD sessions. In the first JAD session, we will gather very high-level requirements and funnel them into what I call a prioritized functionality matrix. In the second session, we take that functionality matrix and generate draft use-cases from them.
For the first session, which I think is the most critical, I tend to follow a high-level agenda similar to the following:
We will discuss each of these items in more detail below.
For the second session, the agenda would look something like this:
NOTE: We’ll cover the detailed creation of the functionality matrix and use cases in separate articles.
Before beginning your session, the facilitator should work with the various stakeholder participants to identify those individuals who will fill certain critical session-specific roles. These roles are discussed briefly below, but it is incredibly important that these people be identified in advance, and are not surprised by their assignments on the day of the session!
The Facilitator: This is the easy one. This is the person leading (facilitating!) the session. For more info, see my article on IT facilitation skills.
Timekeeper: Simply put, this person is responsible for watching the clock and alerting the facilitator when sessions (or segments of a session) are approaching the pre-determined cutoff point. For example, the facilitator may decide to give the group 5 minutes to brainstorm solutions to a particular problem. The timekeeper might alert the facilitator when the clock hits 4 minutes (1 minute warning), and then once it hits the 5 minute limit. This can be done silently by a nod of the head or raising of the hand, or even verbally. Maintaining adherance to a time schedule will help keep people focused, and assist in keeping things rolling along.
Scribe: Outside of the facilitator, this person probably has the most instrumental role in the success of a session. The scribe is essentially the secretary – they keep track of all major outcomes of the session. This is similar to meeting minutes, but is more detailed. This can be done via pen and paper, but in most cases, it is probably best done on a laptop, where the person can switch around between Excel, Word, and other applications. Depending upon the makeup of the stakeholder groups in the room, this person may also be the one responsible for drafting the functionality matrix (in real-time, with input from others).
Parking Lot Attendant: Invariably, things are going to arise that are out of the scope of the session’s guidelines. In order to keep from getting off track and derailing the session, the facilitator may reserve the right to “park” those issues or questions in the “parking lot” so that they may be addressed later. I generally like to address the parking lot issues list at the end of the session (or at the end of each day, if the session will span multiple days).
SMEs/Participants/Devil’s Advocates: Everyone in the room, including the people filling the roles above. Remember, the more valued input you have, the more productive your session will be!
You may decide to come up with other ancillary responsibilities and roles – this is your discretion as the facilitator. Just be careful not to over-delegate to the participants – you want the principal parties to be focused on the task at hand, and not immersed in some other duties that will detract from this.
A Bit on Brainstorming
For those of you who may be new to the concept of brainstorming, I will simply refer you to the great entry over at WikiPedia. However, I will state that I am a big fan of whiteboards, and an even bigger fan of the big Post-It easel style pads. Those are great for capturing ideas quickly, ripping them off, sticking them on the wall, and moving along to the next idea.
It always pays to lay out the ground rules up front, so that everyone is on the same page from the beginning of the session. What these rules are, in the end, is up to you as the facilitator. In general, I like to use these as a starting point:
After I explain these rules to the group, I generally ask if anyone else in the room has any other ideas for ground rules to add to the list for the session. Occasionally, someone will throw something out there (no checking email during the session, turn off cell phones, etc.). Calling for other ground rules is a great way to begin empowering the participants, and to set the tone for the session.
Once the session roles and ground rules have been announced, I like to immediately state what the official “objectives” of the JAD session are. You would be amazed on the first day at how many people actually proclaim things such as “oh, I thought that JAD meant we were going to build the application together” or “I thought we were just going to talk about the need for the project, I didn’t know we were designing it!” The objectives I usually use as a starting point are:
The “system scope” is going to be defined largely by our functionality matrix (deliverable from the 1st session), whereas the use case models and domain model/glossary are going to be outputs from the 2nd session.
You may feel the urge to add additional objectives to this list. My only advice to you here would be to make sure to tie any new objectives to specific deliverables that will come out of your session(s).
I like to go through a series of “reaffirmations” before I lead the group into unchartered waters. I want everyone in the room, from the lowliest coder to the most senior executive, to understand why we are building this product, who it will affect and benefit, and what value it will bring to the market or stakeholders.
Reaffirming the vision of the project is first on the list. The “vision” could be anything, really, but it should be related in some way to the project. If your organization is following a PMI style project plan, then this is probably the project charter. If you are building a software platform for a startup company, then this is probably the actual vision statement of the company itself.
Next, I like to reaffirm the business drivers and business context. Why are we doing all of this again? What business problem will this project solve? How big is the market we are talking about here? What is the value proposition?
Let’s state all of this as a matter of fact – level the playing field by educating (or-re-educating) everyone in the room.
Critical Success Factors
At this stage in the game, we really haven’t done anything toward the actual design of the system. This is a good thing. All of this groundwork will serve us well as we move further into the process.
After the reaffirmations, I like to do a quick 5-10 minute brainstorming session where the group throws out potential critical success factors (CSFs). This allows the stakeholders to identify very succinctly those things that will make or break this project or product.
Consider these examples:
You get the idea. Don’t camp out in this stage – this should be quick, but also helpful in setting everyone’s expectations and understandings.
Current Processes (As-Is) / Future Processes (To-Be)
Once we’ve identified the CSFs, I like to do a very brief “as-is/to-be” analysis. This may or may not be something that every project will use, but I do find them useful in two cases. If you are designing a new product (or working with a startup company), then the “as-is” will probably represent the current state of the industry. If you are doing business process reengineering, and your software product will be a part of the future processes, then the “as-is” will probably represent the current business environment.
In either event, the questions you will ask will be the same:
Additionally, in either event, the “to-be” part represents the deliverables/outcomes of the project itself.
Why do we spend time on this? I have found that if all of the stakeholders, including the development team, have an understanding of where we’re going, and what things look like in the current state of affairs, the end result is a much more cohesive and functional product.
I usually spend 45 minutes on the “as-is” area, and another 45 minutes or so on the “to-be” area. I would recommend a break in between!
Getting weary yet? Don’t fret, as we’re nearly done with laying the groundwork! Only one last item remains. The final area that I like to touch on before leading the team into the design process is the generation of relevant assumptions. These are generated via a short (10-minute) brainstorming session. These should represent things that the project design team are assuming to be true, or in place. Generally, they represent inputs to the system, or owners of certain things. I like to brainstorm these up front, so that the group doesn’t keep disclaiming things all throughout the session.
One caveat here. If you sense that the group is starting to “haggle” or argue over the assumptions, then they apparently are not assumptions to begin with. In such cases, either choose to put the issue in the parking lot, or make a note to revisit it at a later time during the session, where it can be discussed in a more streamlined manner.
Congratulations, you’ve made it through all of the groundwork exercises. We’re ready to begin taking all of the information from the brains of the participants and funneling them into a prioritized functionality matrix.
The functionality matrix is essentially a prioritized grid of the major functional areas within the proposed system. The matrix can be developed using whatever tools you wish, although I recommend Excel, as I find its ability to do quick calculations for me (important later on) and conditionally formatting cell colors to be handy.
However, given the sheer scope of what is involved in creating a functionality matrix, I will save it for a separate article. Don’t worry, that article has already been written – it will publish a week from the date of publication on this article, so be sure to check in then for a more detailed walkthrough. In that article, I’ll also share with you the reasons for bringing several thousand dollars in fake money to your JAD session. :)
Hopefully, the functionality matrix came together in short order. Even the most demanding set of requirements should be able to be pulled together in no more than 2 days (but most often in an afternoon). Don’t forget to address any issues that were plopped into the “parking lot” before going home!
Next steps: Use Cases
Let the participants know that all of their hard work is about to be funneled into the next phase, where the individual use-cases will be developed. These will provide the “substance” behind the functionality matrix.
My final thoughts
I know this was a lot of information, and if you’ve made it this far, then I commend you! While I think all of these ideas are a fantastic way to approach your JAD sessions, I would like to say again, however, that these are not the only areas that you can explore. Use your imagination! Every session will be different, because every project is different. Just follow your instincts, and I’m sure you’ll do fine.
In order to make things a little easier for you, I am including a bare-bones Powerpoint presentation that lays out the flow of this type of JAD session (coming later this week!).
Cheers, and happy JAD’ing!