Article - 7 Tips for Successful High-Level Requirements Elicitation

Submitted by Jamal Moustafaev on Mon, 05/18/2015 - 02:41

“If you don’t know where you are going,

you’ll probably end upsome place else.”

Yogi Berra

Tip #1: Understand the Importance of Requirements

Five out of the top eight reasons why projects fail are related to scope definition, according to the Standish Group. These include:

  • Incomplete requirements
  • Lack of user involvement
  • Unrealistic customer expectations
  • Changing requirements and specifications
  • Customers no longer needing the features provided

Further analysis of causes of “bad” requirements yielded the following results (see Table 1).

Table 1

 A study conducted by Barry Boehm (one of the leading thinkers in the field of software development) involved an analysis of 63 software development projects in companies such as  IBM, GTE and TRW and determined the relative costs of fixing an error at various stages of the project.  Results from the study, demonstrate a phenomenal increase in the cost of a mistake from one dollar at the Initiation stage of the project to $40-$1,000 range at the Closeout (see Figure 1).

Figure 1

 While this information is based on the software development industry, this trend, to a certain extent, holds true for most other industries.

The scope problem is not rooted in our inability to come up with detailed blueprints, bills of materials or design and architecture documents. The predicament lies in the initial stages of the projects, when we need to elicit a high-level initial set of customer problems, issues and needs, and propose potential solutions.

Tip #2: Start with Business Requirements

In order to answer what is a business requirement, let us first determine what requirements are not.  A business requirement is not a combination of e-mails, voicemails, sticky notes, and annotations in your notebook, verbal instructions from the customers and your superiors and/or “drawings on a napkin”. A business requirement (aka high-level project scope item) is:

Something the product or service must do or a quality it must have. A requirement exists either because the type of product or service demands certain qualities or functions, or because the client wants that requirement to be a part of the delivered product or service

Business requirements should be documented either in a standalone “Business Requirements” document or, at least, captured in the Project Charter.

Tip #3: Ask the Right Questions

The first step in every project should be trying to determine what is it that you are going to build or do for you customers, either internal or external.  Getting started in a right direction depends to a large degree on the type of questions you or your team members ask. For example, let’s assume that the first question posed by your management was:

 “Can you find a way to protect a group of people from the unpleasant elements of the surrounding environment?”

As a result of this exchange some of the possible solutions could be:

  • Shack
  • Typical family home
  • Buckingham Palace

But “what are we building?” is by far not the only question you should be asking at the beginning of the project. Table 2 lists the mandatory high-level questions that project managers should be prepared to ask once a  project is handed down to them.

 

Once the ballpark scope of the project has been determined we can proceed to more detailed questions (these could also fall into the category of Project Charter-level questions):

  • How big do you want the house to be?
  • Is it going to be a one, two or three-level home?
  • What square footage would you prefer?
  • What style would you prefer (e.g. Victorian, Tuscan, Contemporary, etc.)?
  • How many bedrooms do you need?
  • How many bathrooms would you prefer?

Also, keep in mind that all of the questions directed at the entire project in Table 6.2 should now apply to every scope item under discussion. For example, let’s review some of the questions a project manager can ask with respect to the number of bedrooms:

  • Why do you need five bedrooms?
  • Would you be OK with just four?
  • The budget you mentioned allows only for a four bedroom home; would you like to downgrade the scope or allocate more money to the budget?

Tip #4: Assign Priorities to Requirements

Since typically customers want significantly more features than the project budget and timeline will allow, it is also very important to assign priorities to the scope items or “features” discovered at this stage.  The suggested categories for the priorities are:

  • Priority 1 (“Must Have”) 
  • Priority 2 (“Should Have”)
  • Priority 3 (“Nice To have”)

Unfortunately the concept of assigning priorities is frequently misunderstood by the project stakeholders. Typically the  lion’s share of  features get stamped with the “Must Have” priority label right at the beginning of the process, thus eliminating any potential flexibility in future scope-related decisions.

Tip #5: Get Rid of the Ambiguous Language

Another important and very frequently overlooked aspect of the scope definition is the ambiguous language one can encounter in the project and portfolio documentation. These include words like: “fast”, “pretty”, “big”, “small”, “cutting-edge”, “usable”, etc. The danger of these words is that psychologically we are “trained” to accept them as normal, everyday concepts. However, when it comes to project management, words like these can act as deadly time-bombs. For example, the word “cutting edge” seems like a normal, even cool word to describe a product. And while it looks fine in marketing materials or TV ads, introducing this word to scope documentation can cause a lot of issues down the road.

The reason for that is, while everyone understands, more or less, what “cutting-edge” means, no two people have an identical understanding of the concept. These differences in understanding can lead to very expensive and time-consuming scope adjustments once the project moves into planning and execution stages.

When covering this topic in my executive training programs, you’d be surprised how many executives can provide a relevant example of their own.  Here is an example from one of these executives:  “We had a construction project budgeted at $500 million dollars. Because we allowed the word “cutting-edge” to sneak into the Business Case, our final bill for the project ballooned to $700 million. There always was at least one key stakeholder in the room for whom a given feature was not revolutionary enough! And because we initially made a commitment to being “cutting-edge” there was no way for us to back away from that”.

Tip #6: Understand the Difference Between the Problem and the Solution

When gathering the requirements project managers frequently come across stakeholders’ ideas for a solution rather than the description of the underlying problem. You should always strive is to interpret what is said thereby uncovering the “essence”. Let me provide you with an example.

My boss: “Risk Management is having problems with their desktop statistical analysis software. They are asking for an Enterprise Edition of the software and a dedicated server. Our initial ballpark estimates for this project are at $500,000 and we have neither the money in our budget, or the resources to accomplish that. You mission is to explain to them that they are not getting this stuff in the next couple of years!”

Me (going over to the Risk Management Department): “What is the problem?”

Risk Management people: “We have to store files on the shared server because of the privacy laws and access them through our desktops. Processing times are very slow. We have to upgrade to the Enterprise Server Edition and get a new server”

Me (calling Network and Infrastructure people): “But why is the processing slow? Is it the network or the overloaded server?”

Network people: “We checked the network and it does not appear to be overloaded”

Infrastructure people: “Are you kidding me?! The entire building is using this server. Of course it is overloaded and slow”

Me: “So, what can we do?”

Infrastructure people: “We will give them a dedicated NT server; we have one lying around here somewhere …”

Result: The $500,000 project was diminished to a $2,000 server and 3 man-days of work-problem solved.

Tip #7: Differentiate Between Real Constraints and Customer Preferences

For example, an information system designed to tabulate and report US presidential elections must be ready to operate by the first Tuesday after the first Monday in November of the next leap year. If the product is not ready by that day – it has no value for the next four years. This is definitely a constraint! A requirement to upload a photo of the new executive team member on to the company website by end-of-day Friday is typically a preference.

About the Author

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East.  Read Jamal’s Blog @ www.thinktankconsulting.ca

Jamal is an author of two very popular books: Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management and Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects.