ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

Requirements Elicitation for Project Success

Updated on September 29, 2012

Requirements Elicitation: An Art Essential to 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.

Get Your Customer Thinking!

In good requirements elicitation, we get our customer really thinking about the project, the way a good interviewer makes his subject (in this case, Tim Armstrong, CEO of AOL) thinking.
In good requirements elicitation, we get our customer really thinking about the project, the way a good interviewer makes his subject (in this case, Tim Armstrong, CEO of AOL) thinking. | Source

Introducing Requirements Elicitation

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.

Finding Out What the Customer Wants Isn't Easy

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!

The Many Types of Requirements

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."

Meet With Everyone: No Exceptions!

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!

Prepare, Meet, and Follow Through

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.

Eliciting Requirements from Customers at All Levels

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.

Eliciting Requirements From Peripheral Stakeholders

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!

Are You Ready to Elicit Requirements?

view quiz statistics

Requirements Complete!

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.


    0 of 8192 characters used
    Post Comment

    • SidKemp profile imageAUTHOR

      Sid Kemp 

      6 years ago from Boca Raton, Florida (near Miami and Palm Beach)

      Yes, Dwachira! Even with the best of intentions, a customer can express needs poorly, leading to poor specifications, and a vendor can misunderstand. A picture is worth 1,000 words, and a prototype is worth 1,000 pictures!

    • dwachira profile image

      [ Danson Wachira ] 

      6 years ago from Nairobi, Kenya

      One of the reasons why many projects get late or worse still, fail is because of misunderstanding or misrepresentation of client's specifications. I like that you brought the idea of prototyping because it is one modeling tool that i find very useful in projects. Great article, voted up and useful.


    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at:

    Show Details
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the or domains, for performance and efficiency reasons. (Privacy Policy)
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)