Requirements Elicitation for Project Success

It is not enough just to ask a customer what he wants. Customers won't know what to say. Project success depends on the art of eliciting customers' dreams, ideas, and wishes, and turning them into project requirements.

Once we know who our customers and stakeholders are, we meet with each one, or with each group, or, if we can't meet with everyone, with a representative of each group. Most likely, we will meet with each customer several times, and with each stakeholder twice for elicitation, and at least once for testing and acceptance at the end of a project.

The goal of these meetings is simple: We want to find out what the customer wants, so we can include it in our Project Scope Definition, our statement of what we are making on the project.

Customer Requirements Elicitation

Our job with each customer is to explain the project and its goals, and elicit from them what they really want. We must assume that they don't know what they want, or they don't know how to express it, or, perhaps, they don't believe we will listen and don't want to tell us.

We explain the project briefly. If we can provide a prototype or picture of what we are doing, that is best. We have them engage, then we ask many detailed questions to get their perspective on how they will use it, how they can benefit, and what the possible problems are. We will do this for each group of customers and we will cover each and every feature of the product or service we are creating or improving. We are likely to meet with each customer group multiple times. We document each step of the way. We start big and work down into the details. We clear up anything that is vague. And, whenever they agree on something solidly, we get formal acceptance of that item - signed - and lock it down in the project plan.

Requirements Elicitation for Stakeholders

We go through a similar, but simpler, process with each peripheral stakeholder. We focus on the part of the project that matters to that one stakeholder. We work out a design with them. We get their signed approval. And then we don't need to bug them again until their component is ready for testing.

Over 2,000 years ago, Plato laid out the problem of requirements elicitation over 2,000 years ago by saying that quality can't be defined, we just know it when we see it.

But to find out what qualities something should have to make it of high quality, we have to help the customer do what Plato found impossible. We engage in a dialog with each customer to discover the features, functions, and qualities of a new or improved product or service. When we elicit those response and write them down, we have our product specification, or, in project management language, our scope definition.

In writing one of my books, Quality Management Demystified (McGraw-Hill, 2006), I explored the many solutions to the problem Plato posed that have been developed both in quality management (as defining quality) and in project management (as scope definition, requirements elicitation, and requirements definition). The best minds in project management and quality management have focused on this issue for one reason: To succeed in business, we have to find a way to do what philosophers have never been able to do!

In Project Management Success: Best Practices in Scope Definition, we discussed eight questions we must answer to define all the requirements of our project. To discuss this with our client, we must simplify it down to two:

• Functional Requirements: What must it do?
• Feature Requirements: What are the features, and what should each one look like, and what should it do?

The best way to elicit these from the customer is not with documents, but with prototypes, mock-ups, pictures, or diagrams. We want to create an environment where the customer encounters the product (or, at least an idea of the product) and shares experience and reaction. We need the customer seeing and touching something, and saying "This feels right," and "No, this doesn't work."

I have reviewed the results of dozens of projects that were installing Enterprise Resource Management (ERM) systems, a type of operations management tool. Very often, executives tried to cut costs by convincing the project manager to meet with departmental managers, and not with every worker. Every time I've heard of that mistake being made, the project failed: No exceptions, in large businesses, government, or medium-sized business. (Small businesses don't use ERP.)

It is essential to find out what workers are really doing - and what will help them do a better job. Management, even supervisors, do not really know how workers do their work!

To do good requirements elicitation, we must prepare for the meeting. First, we must prepare the prototype, mock-up, pictures, or diagrams that we will share with the client. We must also prepare a survey or list of questions that will help the client help us to define specific components, specific features, and definable qualities of these features.

When we meet, we focus on engaging the customer or stakeholder with the product or service as he or she will use it. Say we are introducing an improved tool to workers who hand-assemble precision products. The workers need to handle the tool, be comfortable with it, and know it will improve their work and speed of work. The managers need to know that the tool will improve productivity and be reliable. The executives need to know that this change will increase productivity, reduce production time, or reduce waste, and by how much. The quality assurance team will need to know that the new tool will not introduce new defects.

In each case, we address the customer or stakeholder's concerns about the new product or service, not the product or service itself.

We may want to record each session. Certainly, we want to take good notes, with two note-takers.

The first step of our follow through from the meeting by revising the scope definition and product or service specifications. Then we show this to the customer and ask, "Did we get this right?" This may trigger additional clarifications, or even new ideas. We work with the customer to make the design as best we can, and then we get them to approve it. If we get conflicting desires or requirements from different customers, we work out the issue with everyone concerned.

We build a specification that maps functional requirements to features, then to specific details of features. We also add technical requirements, such as how this product fits in with other products or meets regulatory or technical standards. All of this allows us to create a technical specification of the product or service.

We then put this together into a revised, improved statement of scope. As we move forward in more and more detail, we progressively elaborate the scope definition of our project and its product or service.

Over the last four decades, many people working in the field of project management and quality management have built methods of requirements elicitation, trying to get clearer specifications prepared faster at lower cost. Joint Application Development (JAD) worked with a facilitator coordinating the customer and the IT group, and Rapid Application Development (RAD) accelerated that. This then developed into Agile programming methods, where the programmers work hand-in-hand with the customer department. Once you get the overall idea of requirements elicitation from this article, you may want to study these more advanced methods.

In business, a customer of a project operates at three levels:

• The executive is concerned with the effect of the project and product or service on the business, primarily in terms of increased revenue, decreased cost, and risks of liability. They are also likely to be concerned with the fit of this product or service into the overall image and strategy of the company.
• Management is concerned with the ability to meet production schedules and deliver good results. Will the project interfere with this? Will the product or service make it easier to achieve departmental goals?
• Workers actually use and work with what we develop. Or, if we are developing a new product, they will be making it in production. The details of how their work will change, and issues of learning the new tools or system are a central focus.

Of course, this is a list of general concerns. Each customer may have his or her own personal concerns, that may or may not be relevant to the function of the product or service we are creating. It is our job to listen to everyone, make something that will work, and make something that everyone will be willing to use.

If we succeed in eliciting requirements at all of these levels, then we know that our project will improve the company's bottom line (executive), meet departmental goals (manager), and be easy and beneficial to use (worker). Everyone will see the value of the project, and acceptance of the change will be much easier.

Our core requirements come from the central customer. Peripheral stakeholders are less involved with the project and its product. Typically, they will only use one small part of it. Still, that one part may be essential to the success of their part of the business. Peripheral to our project does not mean unimportant to the company.

As a result, we want to be just as thorough in our meetings with peripheral stakeholders as we are in meetings with core customers. The meetings will be shorter and simpler, but only because the part we are addressing is small; it is not the whole project. But on the part, function, or feature that concerns this customer, be sure to prepare (with a prototype, if possible), line up survey questions, and meet. Then write up the results and get approval (perhaps with changes) at the second meeting. Usually, two meetings for each peripheral stakeholder will be enough.

At that point, we can leave the peripheral stakeholder alone for a while. For how long? Until his or her piece of the project is done, and we need him or her to test it!

When we have:

• Elicited all customer requirements
• Elicited all stakeholder requirements
• Identified all technical and regulatory or legal requirements

and confirmed them, then requirements elicitation is complete.

There is one more thing we must do to complete the Scope Statement that is central to our project plan. We must make sure that all of the goals, functions, and features are well-defined, with objective, measurable goals. Please read Measurable Goals: Requirements Definition for Project Success to learn more about this.

Once the Scope Statement is complete, In a large or technical project, it is time to build the Work Breakdown Structure, (WBS) where, through progressive elaboration, we work out all of the details of every feature of every component of the product or service we are creating. On less formal projects, we can merge the Work Breakdown Structure and the Activity List, and get rolling a bit faster.