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
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
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
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
Practical Project Management Tips and Tools 