JAD: Creating a Functionality Matrix

As promised in my previous article on JAD Facilitation Basics, this article will focus on the steps needed to create a viable functionality matrix, which will serve to summarize and prioritize the functionality for a proposed software system. Thanks to the recent reader who reminded me that this post was long overdue!

As a quick refresher, in a JAD context, the functionality matrix represents a prioritized collection of the major functional components of a proposed system. These functional areas were, hopefully, agreed to by all relevant stakeholders who attended the JAD session(s) that went into its creation.

Before we go further, it is important to point out something. As much as it pains me to say this, my way is not the only way, nor is it necessarily the best way. It has worked for me consistently in the past, however. Hopefully, at a bare minimum, this article will at least give you a framework on which to build your own method(s), or at least spark your imagination a bit.

Before creating the functionality matrix, I recommend having the scribe, or some other able-bodied person, take the controls of a laptop and fire up Microsoft Excel. Excel represents a fast and easy way to collect and tabulate data. Excel will become even more important later on, when we begin doing some calculations. If at all possible, I would recommend being in a room where the laptop can be projected onto the wall. By doing so, everyone in the room can participate in the creation of the functionality matrix.

At some point during the JAD session, you, as the facilitator, will lead the group through a series of exercises in order to capture the broad requirements of the system. For many new facilitators, this part is the hardest, however, it doesn’t have to be. It really, truly is amazing what happens when you simply ask “ok, what, at a high level, does this system need to do?” The general flow will be as follows:

  1. Brainstorm ideas
  2. Streamline the ideas by grouping or removing
  3. Go to step #1 and repeat as needed
  4. Prioritize the final list of requirement categories
  5. For each high level requirement area, go to step #1 and repeat as many times as necessary (to capture the detailed requirements).

When brainstorming requirements, it is important to capture each and every idea. Some ideas will be great. Some will be so-so. A few will be completely worthless in the end. But capture them all. By doing so, you are guaranteeing that every voice is behind heard; at least once. Many JAD sessions fail because consensus was not attained, or voices go unheard.

The process of brainstorming is used to quickly and efficiently capture a stream of ideas. It is not a time for discussion, and certainly not the time to argue one’s case. If you catch your participants doing this, it is imperative that you remind them of this! Capture first, discuss later.

It is practically impossible to instruct someone how to conduct a brainstorming session. The easiest way to learn is to participate in one. However, here is a small sample of the general flow of a session:

Facilitator: Ok, we are now ready to capture the high-level requirements of this new system. We are using a brainstorming session, which means no discussions, only ideas! We have 10 minutes for this, so just blurt them out. As you call them out, I will write them up here on the whiteboard. Mike, our scribe, will also capture all of the ideas on his laptop for use later on. Ready? Begin.

John: The system should offer basic RFQ functionality for our buyers.

Facilitator: Ok, good one (writes it on whiteboard).

Susan: We also need a more in-depth set of RFP functionality.

Facilitator: Ok, very good.

Roger: But aren’t those things sort of the same thing?

Facilitator: Maybe, maybe not. Let’s focus on gathering the rest of the requirements, then we’ll discuss the merits of each of them in turn.

Jane: We’ll need a news portal.

Facilitator: Got it.

Jane: And we’ll also need an online supplier directory.

Facilitator: Very good. Let’s keep going. Faster, if we can.

John: Permission marketing.

Susan: Invoicing and billing.

Randy: Broker integration.

Roger: Contract management.

Facilitator: Great! Let’s keep those ideas flowing!

and so on …

If you get the team working in a rapid-fire mode, you will be completely amazed at the sheer number (and quality!) of ideas that come forth.

As a footnote here, it may be helpful to have the team “practice” a brainstorming session first. First, pick some arbitrary inane topic. For example “the best way to hand wash a car,” or “we are building a house, let’s talk about what features this house needs to have in it.” Allocate 5 minutes to the brainstorming session, and let them go through it. This is a good ice-breaker as well. Give them some feedback on their brainstorming techniques at the end, and then move into the real session.

Once the time limit has expired (the time limit is completely arbitrary, although I recommend keeping it to 10 or 15 minutes at the most), and you have “broadly” captured the first round of requirements, it is then time to examine them in turn. Of course, anything the group feels is out of place, or nonessential, can be easily removed from the list.

Frankly, the easiest way to examine the requirements is to simply ask the group to comment openly on the generated list. Most of the time, they will logically begin funneling similar requirements into broader groupings, which is the ideal scenario. For example, RFQ, RFP, and contract management functionality might all end up in a bucket called “transactional requirements.” Things like “receiving” and “shipping” could be logically grouped into a broader “logistics” category. It is up to the group, through your leadership, to determine what the best number and type of categories to use.

Ultimately, you want to have a nice list of 5-10 (or even a dozen) high level areas, with each of them having perhaps a few sub areas within them. Once you’ve done this, you should start a second round of brainstorming. This time, however, the goal is to provide ideas around the current list of functional areas. We do this for several reasons, but the primary reason is that by seeing the list up on the wall, the participants will naturally begin to expound upon those ideas, and come up with even newer ones … or things that perhaps were overlooked in the first round of brainstorming.

Once this 2nd round has concluded, you should again lead the group through an open discussion of the requirements. Again, the priority here is to streamline the list – grouping and removing as needed. You can theoretically repeat this process any number of times, although generally speaking, 2 or 3 times is sufficient.

Once you’ve done this, you should now be in possession of the broad, high-level requirement areas for this system. You are now ready to move into the prioritization phase. We will brainstorm the detailed requirements shortly, but for now, let’s focus on the the high level requirement areas.

Remember in the previous article where I mentioned that having several thousand dollars in fake money would come in handy? Well, we’ve arrived at that discussion! There are lots of ways to lead a group through a prioritization exercise, but I am partial to what is known as the “$20 method”. In this model, the facilitator gives each participant $20 in singles. You can also do this without using actual physical fake money, but it is more fun to do it this way. Each participant can “spend” their $20 on whatever functionality they desire. The more money they spend on an area, the more important that area is to them. At its core, this is a simple exercise in “weighting”.

If John spends $8 on “logistics”, and $3 on “transactional functionality”, then that means John places a higher value on the logistics functionality within the newly proposed system. At the end of the exercise, it is interesting to see what areas people spend their money on. Often times, their areas align politically with their vested interests – so keep this in mind.

As you can see in this partial screenshot of our Excel model (click image to expand), the business side of the equation was represented by three people (John, Susan, and Mike). The technical team had 4 members present (Jeff, Roger, Jane, and Jill). They each spent $20 on the various high-level functional areas (Transaction, Workflow Management, etc.) You can also see some additional statistics to the right, such as simple summations and averages. Of note are the color coded cells to the far right, which indicate which control group favored a particular area – for instance, the technology team spent more money (on average) on Workflow Management than the business team.


I should point out that all of the functional areas are “important” if they’ve made the final list. Just because one area doesn’t get as much attention as the others, doesn’t mean it isn’t critical to the system. It is also important to point out that the final functionality matrix is not necessarily set in stone. Even though we’ve applied some basic statistical methods to capturing, grouping, and prioritizing the requirements, in the end, the business drivers may screen that a certain requirement be bumped up the list, or bumped down. Common sense, of course, should prevail. The functionality matrix is simply a streamlined viewpoint into the system requirements.

The same weighting method can be applied to the requirements under each major category. I generally use a separate Excel sheet for this. As you can see from the screenshot below, the four requirement areas under the larger “transaction” category are also prioritized.


You’ll also notice that at the top of the sheet, there is a small decision matrix. This four quad matrix compares technical complexity on the vertical axis, and business benefit on the horizontal axis. The four quadrants break down as follows:

Hopefully, this is self-explanatory. The idea is to figure out which quadrant each subfunctional area falls within. To do this, we need to establish some cutoff values. At the top left is a smaller version of the matrix with “cutoff” values in it. These values represent the cutoff values that affect the conditional shading of the cells in the main content area. The idea is that you should be able to quickly scan the content area to see which functional areas fall within each quadrant of the decision matrix. For example, the “contract management” functional area (under the larger “Transaction” category) has a business benefit value of 47.92%.

We got that by taking the average for that line item (10.00 + 8.75 + 10.00) and dividing that number by the total points spent (20, as in $20). That gives us a simple percentage. 47.92% of the business teams money went into the “contract management” functional area. Since our cutoff value is 30%, the shaded color is green (which according to the decision matrix, would indicate that the business folks feel that this functional area should be in phase one of the system). This area clearly has a high business benefit!

However, the technical team’s score is 45.83% – which is over the cutoff value of 25%. This means that developing this functional area will come with a high level of technical complexity (meaning risk!).

So now we have a situation where both sides of the equation (business and technology) feel that this area has a high value. This would push us to the upper right quadrant (shaded yellow). I know this all sounds a bit complicated – and it is. But hopefully this all makes some sense to you.

This post has run a bit long (okay, way long.) I will save the final bit (where we dive into the detailed requirements and finalize things) for another post. I’ll also provide some Excel templates for you to use as well.

Cheers, and happy JAD’ing!


  1. Holy cow this is good stuff! I can’t wait for the final article so I can get my hands on that spreadsheet template.

  2. Hi,

    While reading your article on JAD Facilitation Workshop Basics, I noticed that you might have also written an article on how to create Use Case Models following this session. Is that article available on your web site?


  3. Actually, a discussion on doing use cases was originally going to be a part of this article (the 3rd installment), but my mind wandered …. and wandered. :)

    It is on my ever-burdgeoning list of things to do, however.


  4. Scott, nice summary of the JAD session, I was the scribe for this session ;-)
    One of the key things about these session is to make sure that the actual developers and the REAL clients be involved (do not bait and switch after the requirements are compiled). These session create the relationships that ensure good communication continues to flow during the development. One other thing to keep in mind with these sessions is that it’s not about the resulting scores but rather the discussions that led to the scores that give the most value. The goal is that the developerment team become better versed in the domain and trully understang the priorities of the client.

    Because it’s sometimes difficult to access the all of the business folks (they were out trying to raise more money) I believe that on this project we insisted that the client name an authority on their end that could make on the spot decisions if development had questions.

  5. Joe Pfeiffer · July 25, 2008 at 9:57 pm

    Any Functionalty Matrix templates posted yet?



Leave a Comment

Your email address will not be published. Required fields are marked *