Requirements Elicitation Techniques Part 1 – Overview

Planning

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 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 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 the series:

  • 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 Questionairres
  • Part 13 – SWOT Analysis
  • Part 14 – Summary

Requirements Analysis Using Event/Response and Use Cases – Event Discovery Part 1

Planning

In prior posts I introduced the Context Diagram and the Event List. In this and the upcoming series of posts, I will define some techniques you can use to discover events and complete the Event List and Context Diagram.

The very first place to start defining events is the Context Diagram. Every input arrow on the diagram represents an event to which your “business” must respond. Remember, our definition of your “business” is the boundary of the business area under study. Inside of the business bubble on the Context Diagram, you have control over the business processes and data flows. Outside the boundary, you can negotiate the interfaces with the Suppliers and Customers but have little or no control over their business processes.

Let’s examine an example of how the Context Diagram can provide events. For this example, let us say the Supplier is an Employee and the input arrow is “Travel Expense Details”.

Our first column on the Event List is “When this happens”. In this example, you would state “Travel Expense Report Submitted”.

The second and third columns are “This Source” and “Gives us This”. In this example, the Source is “Employee”, and “Gives us This” is “Travel Expense Details”.

The fourth column is “Then we do this”. These are the labels of the business processes your “business” will execute upon receipt of the “Travel Expense Details”. You might have a list of processes that looks like this:

  • Verify expenses comply with business policy
  • Approve/Reject Expenses

The fifth column is “Which creates this”. These are the outputs of each business process. The outputs of the first process listed above might be “Valid Expenses” and “Invalid Expenses”. The outputs of the second process listed above might be “Approved Expenses” and “Rejected Expenses”.

The sixth column is “… and we give it to …”. These are the recipients of the outputs listed in the fifth column. In this case the recipient of the Valid and Invalid Expenses could be “Employee’s Manager”. The recipient of “Rejected Expenses” would be the Employee while the recipient of “Approved Expenses” could be the Travel Expense Data Repository.

In the next post, I will continue the discussion of Event Discovery and show how, once you have a few events listed, you can use these events to discover more events and get the complete scope of the project.

The Project Management Plan – Overview

Planning

There are two main types of high level planning for a project: (1) The Project Management Plan; (2) The Project Activity Plan (aka The Project Plan). The Project Management Plan describes the approach for managing the project. The Project Activity Plan describes the work to be done to achieve the project objectives. This post addresses the Project Management Plan.

The Project Management Plan defines how the project is executed, monitored, controlled and closed. It addresses the management of scope, schedule, cost, quality, staffing, communications, risk, and procurement. Whenever matters of project procedure are in question, this document shall be the first source consulted.

This is a dynamic document and reflects the current thinking regarding the project approach based on what is known at this time. It is expected to be updated with new information as the project unfolds. Original and revised versions should be distributed to the entire project team.

The components of the Project Management Plan are:

  • Scope Management
  • Schedule Management
  • Budget Management
  • Staff Management
  • Communications Management
  • Risk Management
  • Procurement Management
  • Project Close Definition
  • Post-Project Audit Plan

In subsequent posts I will elaborate on each of these sections.

For large projects I highly recommend creating a Project Management Plan and sharing it with your sponsor and key stakeholders. This plan describes the “rules of engagement” for the project an will minimize assumptions and misunderstandings regarding project process. I have also found this to be very helpful if you are new to an organization. It is a way to document your understanding of the project management practices of that organization.