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 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
Requirements Elicitation Techniques Part 4 – Business Rules Analysis
According to the IIBA (International Institute of Business Analysis), a business rule is a specific, actionable, testable directive that is under the control of an organization and supports a business policy. Business rules should be documented independently of how they will be enforced.
“Operative Rules” are intended to guide the actions of people. They are typically found in an organization’s Standard Operating Procedures Manual. For example “an order cannot be placed if the billing address provided by the customer does not match the address on file with the credit card provider”. It is always possible that associates will not always follow an Operative Rule. When you are doing a current system analysis, you may very well find documented rules that are handled differently in each location. By finding out the root cause of why a rule isn’t being followed, it could present a good opportunity to change the rule.
“Structural Rules” structure the knowledge of the organization and cannot be violated. For example “an order must have one and only one payment method”. This type of rule is usually enforced systemically. They can be uncovered during data analysis by constructing an Entity-Relationship diagram. The relationships between entities are the Business Structural Rules.
Other examples of Structural Rules:
- A Product can be purchased by zero, one or many Customers.
- A Sales Transaction contains one or more Products
- A Discount can be applied to zero, one or more Products.
- A Customer may Purchase zero, one or more Products.
The “zero” relationship is of special interest. It is useful for uncovering additional requirements. For example, in the example above “A Customer may purchase zero, one or more Products” you may ask “How can a Customer purchase zero products?”
The answer may be “A Customer might only apply for a Store Credit Card” or “A Customer may only wish to be added to an email list”. These answers would generate follow up questions regarding the scope of the project.
A reminder that my Kindle book “Project Management For The Real World” is available at
Kick The Field Goal! What American Football Can Teach Us About Project Management
With the NFL season about to begin I thought I would share a project management lesson I learned many years ago from, oddly enough, watching an NFL telecast. The color analyst was the legendary John Madden.
Team A was trailing Team B 21-0 but it was still early (mid second quarter). They were confronted with a 4th down and goal to go situation from the 5 yard line. Fans of Team A, concerned with the large deficit, were no doubt screaming for their team to go for the touchdown. This is when Madden made the point that resonated with me from a project management perspective:
“I would kick the field goal here. The longer you are at 0 points, the harder it becomes to move off of 0. Once you have points you have something to build on.”
There are those in the modern sports analytics field who might argue this but that is not the point of this post. Madden’s comment made me realize that the longer a project goes without delivering business value (known as the “Business Objectives” of the project), the harder it gets to deliver them. Some of the main reasons for this are:
- Business or IT Management and Stakeholders continue to propose grand ideas which significantly increase the scope without going through formal Scope Change Management.
- The Project lacks a Charter or Definition with sufficient detail, making “scope creep” hard to define.
- The Project is trying to deliver the Project Objectives all at once instead of a phased approach which can deliver some business value earlier.
I recommend having well defined Business and Project Objectives. Manage Scope jealously. Deliver at least some of the Business Value as early as possible and in phases.
The longer a project drags on without delivering something, the harder it gets to deliver anything. So”Kick the Field Goal”. Get off of “zero” as soon as possible. Your business and project (and your career) will be the better for it.
A reminder that my Kindle book “Project Management For The Real World” is available at
Requirements Elicitation Techniques Part 3 – Benchmarking
The technique of “Benchmarking” is sometimes used in the Requirements gathering process. You compare your company’s processes and performance metrics to industry best practices from other companies. The knowledge uncovered in these investigations can be used in process improvement initiatives or to solve thorny problems you encounter on your project. I have managed many projects where a typical question in a meeting is “What does Company X do in this case?”. “Company X” is typically the main competition for your company and is usually recognized as an industry leader in the area under study. You may or may not get “Company X” to speak with you on a particular topic, depending on the relationship and the level of competition.
Benchmarking can save a lot of time on a project by avoiding the “let’s reinvent the wheel” syndrome. If someone else has figured it out, why waste your own time? Now you may find their solution cannot be completely adapted to your specific situation but there are usually as least some pieces that can be used and be very valuable.
Benchmarking is a supplementary requirements technique. It will never be the only technique you use but can add important additional information to the requirements process. On every project you should at least ask yourself if Benchmarking can add value to the requirements process.
Note: Part 4 of this series will be published on September 12.
A reminder that my Kindle book “Project Management For The Real World” is available at
Requirements Elicitation Techniques Part 2 – Acceptance Criteria
If you search the Internet for “Acceptance Criteria” you will see definitions like this: “Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer or external system.” There are no shades of grey, the condition either satisfies the criteria or not. There are no “90% satisfies”.
Acceptance Criteria should be established before development begins. The reason for this is that the criteria needs to guide the development. If you write them during or after the development, you will just be verifying what was built and not the customer intent.
Like all good business requirements, the criteria should be “what” not “how”. For example, you might state “Upon submission of the completed application a notification is sent to the Director”. You don’t want to state “Upon clicking ‘Submit’ an email is sent to the Director”. Avoiding implementation specifics opens up new possibilities for a design solution.
In many ways, the “Event/Response method” (see my prior posts on this topic) and “Acceptance Criteria” are very similar. With Event/Response, we document a triggering event, the data sent and who sends it, what we do with it, the outputs and who receives them. With Acceptance Criteria, many use the format “Given some precondition, when I do some action, I expect some result”. These are essentially the same things although Acceptance Criteria can be at a lower level (the Use Case and Functional Requirements level).
You do not approach your user or customer and ask “What are your acceptance criteria?”. This will mostly elicit blank stares. You will want to use other elicitation methods such as Event/Response and Use Cases, and derive the Acceptance Criteria from there. You can do this by prioritizing your requirements (e.g. “priority 1 = must have or cannot go live, priority 2 = can go live without it but must have within 1 month of go live, priority 3 = nice to have if it fits within the budget and schedule”). In this case, priority 1 requirements are the acceptance criteria for go live and priority 2 requirements are the acceptance criteria for project completion.
Some examples of Acceptance Criteria:
- If I am a System Administrator, I can add, update or delete accounts.
- I can search for users by last name and can enter a partial string and receive the results of all that qualify
- I can filter my staff by availability for a given shift
A reminder that my Kindle book “Project Management For The Real World” is available at
Requirements Elicitation Techniques Part 1 – Overview
In the previous series of posts I introduced my favorite requirements elicitation technique, “Business Event/Response”. Of course there are many other techniques which can act either as complementary to or in place of “Business Event/Response”. The techniques you choose depend on many factors including the type of project, knowledge depth of the Subject Matter Experts (SME), the availability of documentation, time constraints, etc.
A skilled Project Manager that is also a seasoned Business Analyst (BA) is a very valuable commodity. I encourage all PM’s to increase their BA ability by reading books, attending webinars and seminars, and putting their new knowledge to practice. There is no substitute for actual work experience in this realm.
Here are the topics I will address in this series of upcoming posts:
- 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
- Part 14 – Summary
A reminder that my Kindle book “Project Management For The Real World” is available at
