My Kindle book, “Project Management for the Real World“, is now available in the Kindle Store at
http://www.amazon.com/dp/B089KRDDVN
If you like this blog, you will benefit from reading this book.
Welcome!
The Project Management Institute (PMI) encourages its members to advance the profession. One of the ways to do this is by helping others increase their project management skills. The target audiences for this blog are professional PM’s early in their careers as well as those who manage projects but are not PM’s by title or trade. I will be posting every week or so, offering practical tips and tools on the full range of project management topics. I hope you will find this useful and help you advance your career.
Requirements Elicitation Techniques Part 14 – Summary
In the prior posts in this series, I introduced the following requirements elicitation techniques:
- Part 1 – Overview
- Part 2 – Acceptance Criteria
- Part 3 – Benchmarking
- Part 4 – Business Rules Analysis
- Part 5 – Data Modeling
- Part 6 – Document Analysis
- Part 7 – Interviews
- Part 8 – Non-functional Requirements
- Part 9 – Observation
- Part 10 – Prototyping
- Part 11 – Root Cause Analysis
- Part 12 – Surveys and Questionnaires
- Part 13 – SWOT Analysis
These are in addition to the Business Event/Response technique which I discussed in detail in a prior series of posts. These techniques can be considered a “toolbox” from which you can select the appropriate tools for the job. You will likely never use all of these in a single project. Based on the type of project you are working on, you will select the techniques that fit the size, background and scope of the project. Every Project Manager should have familiarity with these techniques and be able to apply them. They are core techniques in the Business Analyst’s Body of Knowledge (BABOK).
If you are a Project Manager and don’t currently perform the Business Analyst function, I encourage you to get training in this area. PM’s that can perform this function are immensely valuable to their organizations.
Feel free to leave comments on your own experiences as a Business Analyst. Include what worked well, what didn’t and why.
A reminder that my Kindle book “Project Management For The Real World” is available at
Requirements Elicitation Techniques Part 13 – SWOT
The acronym SWOT stands for “Strengths, Weaknesses, Opportunities, Threats”. It can be a useful tool to analyze a business process undergoing change. Honest evaluation from all parties is important here. The group undergoing the evaluation must not feel threatened by the analysis. Note that “Opportunities and Threats” are external factors beyond the scope of control of the assessed group.
As with all endeavors in the field of project management, always make sure you have first defined your objectives and expected outcomes of the analysis. This will ensure that proper use is made of the results.
The SWOT evaluation team should be comprised of a cross-section of middle and upper management of the business process owners, as well as those who actually participate in the execution of the business process. The team should be instructed to first identify the Strengths, Weaknesses, Opportunities and Threats independently to avoid group bias. Then the group is brought together to compare notes and agree on the final list.
You proceed to make a matrix with S and W as the rows and O and T as the columns. The cells are filled in by the evaluation team as follows:
- SO – How can the groups strengths be leveraged to exploit the potential opportunities?
- ST – How can the group use its strengths to ward off potential threats?
- WO – Can the group use an opportunity to eliminate or mitigate a weakness?
- WT – Can the group restructure itself to avoid a threat?
The answers are analyzed to determine cost of implementing vs. value and from that you can determine which of these the project sponsor wishes to include as part of the business requirements for the project.
Requirements Elicitation Techniques Part 12 – Surveys And Questionnaires
For some projects you may need to gather information from many people in a short time. When you have this condition, surveys and questionnaires can be very efficient.
First lets define the terms. A survey encompasses all aspects of the research process (design, construction, sampling method, data collection and response analysis). A questionnaire is a tool used for a survey and is a set of questions with a choice of answers.
Let’s look at the steps to conducting a requirements gathering survey:
- Design – You will need the answer to questions such as “What are the objectives?”; “What media will be used?”; “Who will it be sent to?”; “How long will be given to respond?”; “What will you do with non-responders?”; “Who will compile and analyze the data?”
- Construction – “Who will determine the questions to ask?”; “How many questions will be asked?”; “Will you allow open-ended responses?”; “Who will create and distribute the questionnaire?”. A tool such as Survey Monkey can be useful.
- Sampling Method – You will need to define the target population. If the entire population is sufficiently small, you can include everyone. If the population is large, you will need to use statistical sampling methods. Consult the statistician on your team or company for advice on the various methods.
- Data Collection – The method of data collection should have been determined in design. Collect and summarize the data as a prerequisite to response analysis.
- Response Analysis – This ties in to the objectives you defined in design. The method and people involved were determined in design. The responses are used to guide the direction of the requirements.
A reminder that my Kindle book “Project Management For The Real World” is available at
Requirements Elicitation Techniques Part 11 – Root Cause Analysis
The purpose of root-cause analysis is to determine the underlying source of a problem under study. Doing this will help ensure the requirements attack the real problem and not just the symptoms.
A critical element is to challenge the current business thinking and processes. You want to overcome the “we’ve always done it that way” answer to the question “Why do you do this?”. I recently managed a project where it took interviews with dozens of people to finally get the answer to the question of why the pay week started on a Saturday instead of Sunday where the sales week started.
The steps to root cause analysis are:
- Define the problem under study and understand the impact
- Analyze the problem to determine the root cause
- Agree on solutions to prevent the problem from occurring
One technique to analyze the root cause is the “five whys” to explore the nature and true cause of a problem. This means repeatedly asking “why” after a question is answered until you uncover the real root cause. It may be more or fewer than five, but five is a good rule of thumb.
You can create a visual of your “five whys” analysis using a “Cause Map”. A Cause Map is simply a block on the left that identifies the problem, an arrow labeled “why” going left to right to another block that answers the question, then an arrow labeled “why” going left to right to the next answer and so on until the root cause is identified.
Root Cause Analysis is a good addition to your requirements analysis repertoire. If your project is not addressing the true root causes of the problem definition then you are unlikely to achieve the defined business objectives.
A reminder that my Kindle book “Project Management For The Real World” is available at
http://amazon.com/dp/b089krddvn

Requirements Elicitation Techniques Part 10 – Prototyping
Prototypes are the shell of an actual production application and are used to provide insight into the look, feel and flow of an application. The main purpose is to gather requirements related to the user interface. A “throw away” prototype seeks to quickly uncover and clarify system interface requirements. It is especially useful in cases where the most efficient workflow can only be discovered with hands-on experience.
Some have made the mistake of thinking prototyping is all you need to do to gather requirements. This will almost always be a costly mistake! Other requirements techniques will need to be used to get a complete set.
When you obtain the user interface requirements using prototyping, the next step is to integrate these requirements with your use cases, scenarios, data model and business rules. Your new discoveries will usually result in changes to previously gathered requirements.
There are two categories of prototypes used to uncover functional scope:
- Horizontal Prototype – models a shallow and wide view of the system’s functionality. It typically does not have any business logic running behind the visualization.
- Vertical Prototype – models a deep and narrow slice of the system’s functionality. There usually will be some business logic built to uncover complex requirements.
It is a judgment call as to whether or not to use prototyping on a particular project. You must weigh factors such as the importance of the user interface, the clarity of the requirements gathered via other methods, the difficulty in building the prototype, and time constraints.
A reminder that my Kindle book “Project Management For The Real World” is available at
Requirements Elicitation Techniques Part 9 – Observations
In many cases of gathering requirements, there is no substitution for actually observing the process as it happens. You will find that often the way things are done contradict what is written in process manuals. These deviations are important as they usually reveal an inefficiency or deficiency in the process, and the user felt the need to employ a different method. This is valuable information for process improvement!
You should be aware that at times just the fact that a process is being observed can make the user change how they usually do things. It is important to make the people being observed comfortable with why they are being observed and the objectives of the observation. Openness and honesty are important. Solicit their input and suggestions.
As with anything project related, there needs to be a plan. You can make a simple form with elements such as:
- Process Name
- Observation date(s) and times
- Observers
- Location
- Purpose/Objective
- Notes
- Key Findings
The dates and times are important as you need to know if this is considered peak/normal/low volume time. This is a key consideration regarding the observation objectives.
After the observations are complete, you should meet with key project staff and stakeholders to discuss findings and their impact on the requirements.
A reminder that my Kindle book “Project Management For The Real World” is available at
Requirements Elicitation Techniques Part 8 – Nonfunctional Requirements
In this series so far I have addressed “functional” requirements. These are the requirements that address features, functions and processes for the new system. There are also many requirements that are not related to the features, functions and processes. These are called “Nonfunctional Requirements” and mostly address the quality of the delivered product.
Here are some examples of Nonfunctional Requirements:
- Performance – Response time, transaction rates, throughput.
- Operating constraints – System resources, people.
- Platform constraints – The target platform may have been predetermined.
- Accuracy – Some applications (e.g. Consumer Data Base) can tolerate some level of inaccuracy, while others (e.g. Taxes) have to be very accurate. This should be agreed upon in advance. Accuracy has a cost so it should be in line with the value.
- Maintainability – The effort required to make changes. Sometimes this will be sacrificed in order to meet a target date. Your Business Sponsor should be well aware of this decision.
- Portability – The effort needed to move to a different platform
- Availability – System up-time. Should specify the maintenance and upgrade windows.
- Security – Requirements of the protection of the system and it’s data.
- Usability – How difficult will it be to learn the system? How much training time is needed?
- Legal – Consult your company’s legal team for these. Your project could involve labor laws, privacy laws, etc.
Your organization may have standard templates for these types of requirements. If not, you should create the templates as part of your project. There should be lots of useful information from previous projects for you to use as source material.
A reminder that my Kindle book “Project Management For The Real World” is available at
Requirements Elicitation Techniques Part 7 – Interviews
Interviewing is a systematic approach to eliciting requirements. You can interview an individual or a group of people, in a formal or informal setting. You ask questions relevant to the project and document the responses.
Interviewing should not be the only technique you use to elicit requirements. You will not know all the questions you need to ask. That is why I am a big fan of the Event/Response method (I have a prior series of posts on this method). The flow of that methodology creates the questions you will need to ask to ferret out all of the requirements.
In a structured interview, you have a predefined set of questions. These will be based on how much you already know about the area under study. Here are some sample interview questions:
- What are the business objectives for this project?
- What are your biggest challenges?
- What worries you about this project?
- Who is impacted (good or bad) by this project?
- How are they impacted?
- Are their known changes or projects that impact this one?
- What business processes are impacted?
When interviewing, avoid “yes or no” questions and pay careful attention to the answers. It helps to have someone document the answers for you so you can focus on paying attention to the answers. They usually will lead to follow up questions that are not on your script. Be prepared to deviate from the script if necessary.
In an unstructured interview, topics are discussed in an open-ended way. You don’t have a script, so the answers are used to spring-board into subsequent questions.
If possible, you should establish in advance a trust and rapport with the interviewee. This will make them more comfortable to be open and honest with you.
A reminder that my Kindle book “Project Management For The Real World” is available at
Requirements Elicitation Techniques Part 6 – Document Analysis
Document Analysis is simply gathering and reviewing all existing documentation related to the scope of the project. It can be very useful in identifying the “as is” state as well as help to uncover Business Events for your Event/Response analysis.
There are three stages to document analysis
- Stage 1 – Identify the relevant materials
- Stage 2 – Study the materials, take notes and list follow up questions
- Stage 3 – Get answers, organize the information into your requirements format
One of the major cons of document analysis is that documentation is often not kept up to date. You will have to verify the validity of anything you plan to use.
Here is a list of documents which can be useful:
- Business Process Documentation
- Training / User Guides
- Functional specs of existing system
- Business Rules
- Organization Charts
- Emails
- Contracts
- Help Desk Incident Reports
- Project Documentation for prior projects in the area under study
- Existing user enhancement requests
A reminder that my Kindle book “Project Management For The Real World” is available at
Requirements Elicitation Techniques Part 5 – Data Modeling
Data modeling is a complex topic. Becoming a professional data modeler takes months or years of education plus practical experience. It is not my intent to teach data modeling in this brief post, but to show how it is related to requirements elicitation.
I introduced some of the concepts of data modeling in Part 4 of this series, “Business Rules Analysis”. The relationships between entities are the business rules and they are fixed in the structure of the data. Examples of these rules are “A Customer lives at one or more Addresses” and “An Address may contain one or more Customers”.
Entities can be found in the nouns in your requirements. They are people, places and things about which the organization wishes to store data. In the example above, “Customer” and “Address” are entities and are therefore capitalized in the rules statements.
Attributes are the elemental pieces of data that are associated with each Entity. In the logical data model, each attribute must be stored with one and only one Entity. The logical data model represents the business Entities, Attributes and Relationships without regard to physical implementation.
The physical data model represents how the logical data model will be implemented in a relational database. Here are two examples of the differences between the logical and physical data models:
- In the logical model, you can have “many to many” relationships as in the Customer / Address example above. In the physical model you cannot implement many-to-many relationships, so there would need to be an additional table to store each Customer / Address combination.
- In the logical model, Attributes belong to one and only one entity. In the physical model, attributes can be included in multiple entities due to inclusion on table keys or for performance reasons.
The data is an important part of requirements gathering. It is an important tool in Event Discovery, as you will ask data related questions such as “What does having this data allow you to do?” and “If I took this data away, what would it prevent you from doing?” Other Event Discovery questions are “What events cause this attribute to be added (or changed, or deleted)?”
I would recommend all Project Managers at least be able to read and understand an Entity-Relationship diagram.
A reminder that my Kindle book “Project Management For The Real World” is available at
Practical Project Management Tips and Tools 