Determining project requirements--best practices and tips

Introduction

When you take a project management class, you are likely to be told about the three major constraints of a project – Cost, Schedule, and Scope. You will then spend an exuberant amount of time developing, analyzing, calculating, and optimizing the schedule. Likewise you will review budget categories, analyze depreciation, and determine acceptable variances. However, when it comes to the scope section, very often you will get a 15-minute mandatory session on change control and how to avoid scope creep.

Okay… So what’s my point? Please bear with me for a bit longer. In one of the classes I teach I do a teambuilding exercise where the students, in teams, brainstorm reasons that projects succeed. The one answer that always makes it up on the list, in some form, is “well defined requirements”, in other words – SCOPE!

So, if defining scope is a critical part of succeeding on a project (and I would argue that it is, by far, the most important of the three constraints!), why don’t we focus more time and attention on it? Because it is difficult! Very often, customers don’t know exactly what they want, the “I can’t describe it, but I’ll recognize it when I see it” syndrome, or the language barriers between the customer and the project team makes the communication of the necessary requirements a nightmare.

That’s the problem definition (stating that Scope is difficult would have been more to the point, but I’m an instructor so even the obvious takes time to state).

Selecting an approach to requirements gathering

There are many types of requirements, as there are many approaches to capturing them. Before starting into the actual capturing of requirements, a plan for the requirements gathering process must be developed. Often the first step for that should be to determine what the roles and responsibilities should be during this phase of the project. While the project manager would normally be responsible for the requirements of the project, it should typically be the customer, or an analyst, who is responsible for the requirements of the product. Even though the same person may play both roles, their overall responsibilities are different and it is important to be aware of which role is involved in what steps.

The project scope defines how the product (or service) will be developed while the product scope defines the actual functions and features of that same product. The traditional focus in project management has been on developing a product faster, cheaper, and better. The requirements of that product though are often assumed to be correct. This is changing through the popularity of agile approaches where it is assumed that the customer does not have a clear understanding of what they want up front, but rather that requirements gathering is a discovery process, where the customer gradually discovers the product requirements through iterations, prototyping and modelling.

There are many good techniques to gather requirements, all of them have their time and place and it is good for the project team to spend some time upfront determining the right approach for the specifics of this project. Some of the techniques to consider are:

1. One-on-one interviews. An easy to arrange approach to requirements gathering that works well in a single-user environment where requirements are expected to be non controversial. However, it is easy to get side tracked in these interviews so the interviewer must have the ability to keep the focus on the topics discussed and to be well prepared.
2. Surveys. Surveys are a good technique to reach a large number of customers. Surveys must be kept simple and it is often difficult to get a significant number of the surveys to be returned. However, if the questions are specific and clear, the survey can serve as a great tool to take the pulse of the customer.
3. Job shadowing or observation. This seems to be a fast growing technique for requirements gathering and it works great when the analyst is not real familiar with the business or when the customer has difficulties verbalizing the requirements. It does tend to primarily focus on the as-is situation of the business so if business processes are changing or a new business is started, this may not give the desired result. It is also noteworthy that observation tends to change the behaviour of the person being observed, so the analyst may not get an accurate picture of the customer’s true problem.
4. Facilitated sessions, or as I will refer to them, JAD (Joint Application Development) sessions. This are designed for multi stakeholder situations where there is a need to build consensus between the stakeholders.

JAD sessions

Joint application design was pioneered by IBM in the late 1970’s and the early 1980’s, and popularized further by James Martin who made it a key technique for RAD (Rapid Application Development) projects.

So, what is it? Well, consider a traditional project (I’ll look at an IT project for example, since that is my background). First there will be a customer, often a functional manager, who will meet with you and get started, giving you some level project goals. Then you’re sent out on the interview circuit – find out what the purchasing department needs, see if the finance group has any requirements (thy usually do!), talk to the material management department, and so on through all necessary departments and divisions…. After that you lock yourself in a room to compare all the requirements, identify the inconsistencies, and try to figure out best way to deal with them.

In the best-case scenario, you make a few more rounds to all your stakeholders and get an agreement – at worst (and unfortunately this happens more often), you decide to “interpret” the requirements or maybe tweak them enough so they fit together. This will invariably result in a product that is less than the customer wanted.

However, by using JAD you would bring the stakeholders together into a number of sessions (normally two or four), where they, with the guidance of a facilitator, will determine and come to an agreement on the requirements. By having the stakeholders actually discuss and come to a consensus on system requirements, you are starting out with a greater level of ownership up front. If you also choose to develop and review prototypes during these sessions, you will greatly help the users visualize what the end product will actually look like.

Since JAD is a techniques largely focused on group dynamics and team synergy, it is important to get the right people involved. The key people for a JAD session are:

The Facilitator

The facilitator should be selected based on their ability to work with and lead a group of people in consensus building. They should be neutral to the outcome of the session, meaning that they should not have a vested impact in steering the discussion in a certain direction. This normally means that the project manager or the developers do not make good facilitators. Ideally, it should be a person that has a general understanding of the customer’s business areas, who is comfortable with modeling techniques that are to be used in the session and who can deal with a group of disagreeing people and move them along in the decision process.

While the facilitator is not the most important person for the project, they are the one with the most influence on the success of the JAD session itself. They need to be able to sense how the JAD team is functioning, to deal with conflicts, and to make sure that the goals of the session are being met.

The Scribe

The scribe, or scribes, will capture the key decisions, and the rational behind those decisions. If a 3-day JAD session is being held and at the end there is no documentation of the outcome, then everyone has just wasted 3 days. Have one scribe focus on conversations and one on models. This will improve the odds of catching everything important. The scribe must have good listening skills and must understand the business that is being discussed. You don’t want constant interruptions from the scribe, requesting clarifications of items that are well understood by the rest of the room.

The Analyst

The analyst is the person focusing on capturing the right information. Often the analyst will also be the facilitator, but when that happens they are playing two different roles. The facilitator is focusing on getting the group to consensus and to meet the session goals while the analyst is there to make sure that the right questions are asked and that the models correctly identifies the business. The analyst is really more of a subject matter expert on the customer’s business.

The Customer

Obviously you cannot hold a JAD session without a customer. While it is true that you may not be able to select your customer, there are ways to influence the selection of them. Identify the criteria that you are looking for and meet with management ahead of time and explain the importance of the role and the characteristics of the person that is needed.

There are other people that will be involved in JAD sessions as well. The sponsor should kick off the session and set the tone, Subject Matter Experts may be brought in for portion of the session to explain a process or a technology. The developers should also attend the session, but especially in the beginning it will important that play more of an observer role than an active role.

Having a successful session

Since the goal of a JAD session is to create team synergy and build consensus, the facilitator must create an environment where the stakeholders work well together and can accomplish the session objectives. To start off on the right track, it is important to have the sponsor or a key executive from the organization, attend the meeting and show management support for the project. This will ensure that everyone understands and supports the goals.

There must also be ground rules established for the JAD session. Ideally most of the ground rules are established by the participants themselves. This tends to lead to the team enforcing the rules, rather than the facilitator. Sample ground rules include:

1. Breaks and how to handle late comers
2. Decision process and how consensus is defined
3. What to do when a topic goes longer than the agenda
4. Rules to deal with participants monopolizing the conversation

One of the biggest difficulties during a JAD session is to stay on track and prevent the team from going off on tangents. A great tool for this is the Parking Lot. A parking lot serves two main purposes, first, it allows the team to capture important information that should be addressed, but not by this team at this time. The second benefit is for the facilitator. It allows moving a person off a topic which is not in line with the goals of the session. There may not be intent to ever re-visit the topic again, but by putting it in writing and making it visible, it may allow the team to put the topic aside.

The facilitator must be monitoring the team through-out the session to assess how well they function. All teams will go through a team development cycle such as Forming/Storming/Norming/Performing.

In the forming stage, the team is insecure and need a lot of guidance. Team building and clear assignments are important for this stage. In the storming stage the team is now trying to assess the competency of other team members and figure out where they fit. The facilitator needs to let the team storm, while making sure that the ground rules are being followed. In the norming stage the team is falling in to natural roles and responsibilities and the team starts to find its purposes. When that has been sorted out the team is in the performing stage. In real life the team will move back and forth between these stages and the facilitator should adjust their facilitation style based on that.

Implementing a JAD approach

To get started, select a core JAD team within your organization. Have them get up to speed on the various versions of JAD (as many as there are authors), pick one and start the education process, some of the key steps are:

1. Sell it to your management to the customer. If you don’t get buy-in this will fail, so make sure you put together a good sales presentation.
2. Train your core team on the techniques you’ll be using (could be Process Modeling, Data Modeling, Prototyping, etc.)
3. Train some facilitators (select people that can lead a discussion, not necessarily the ones that want to do the most talking)
4. Pick a pilot project. Pick something not too large, something that you can afford to learn one and work through.
5. Train all participants (the users in the sessions have to understand the technique)
6. Schedule and run the pilot session.
7. Do an extensive lessons and learned session.

If you plan it right, you should now have a great foundation for many future successes with Joint Application Designs. Good Luck!

Jonasson, H., (2007) Determining Project Requirements, New York, NY: Auerbach.

Wiegers, K.E. (2003) Software Requirements, 2^nd Edition, Redmond, WA: Microsoft Press.

Wood, J. & Silver, D. (1995) Joint Application Development 2^nd Edition, John Wiley & Sons, Inc.