Connecting Requirements, Estimates and Work Plans

By John A. Bellwin, JD, Accenture Senior Manager

Textbooks say that information technology teams should:
  1. Develop requirements,
  2. Estimate the work based upon those requirements, and
  3. Plan the work based upon the estimates.
Bridging the gap between textbook and real-life execution can be quite a challenge. I bridge the gap by creating a connection based upon a documented understanding of:
  • Data Objects and their attributes
  • Roles that use the data objects
  • Actions that are performed by the roles using the data objects.
I am going to limit the scope of my explanation of the above to the development of application functionality. Later articles will address change enablement, technical architecture, application implementation, and the tools that can be used.

Developing Requirements

The example that I use to explain this idea is hypothetical software designed to create a grocery shopping list. Simplistic, yes; effective in conveying an idea that can quickly become complex, yes. Suppose you were going to build software that created a shopping list. Simple right? 

Requirement #1: The Grocery Shopping List (GSL) application shall provide users with a list of items to be purchased at the market.

When developing requirements, business analysts can start the conversation by focusing in on "items". What is an item?

Item - goods available for purchase at the market.

Item Attributes
  • Category (e.g. cereal)
  • Sub-category (e.g. Frosted Flakes)
  • Brand (e.g. Kellogg's)
  • Size (e.g. large)
The nice thing about this structure is that it allows users to say what they want "a list of items to be purchased" and provides the business analyst with the first set of questions: "what is an item?"

Second, who (the roles) will use the "Items" – can the kids add Ben & Jerry's ice cream to the list?

Third, what (actions) will be done with the items (usually at this point the audience figures out that they want the list of items sorted by the aisle that they are in (speeds up shopping time). If so, "aisle" needs to be added to the list of Item Attributes.

Granted, this Data/Roles/Actions structure does not work in every circumstance, point taken.

Quantifiable Structure for Estimating

As the requirements are developed using this Data/Roles/Actions structure, it provides a very quantifiable structure upon which to estimate. The core of the estimation is the Data Object—as the number of data objects increases, so does the estimate. As the number of attributes increases, so does the estimate. Complexity (which also increases the estimate) is based upon how many different roles can access the data and how many Actions can be performed with the data object.

Post Requirements Work Planning

I will spare you the tome of addressing work planning both pre- and post-requirements development and address only post-requirements work planning. 

With any work planning effort, I think that you have to decide on the metrics by which the project will be judged first. Please allow me to assume that the project will be judged against:
  1. Progress against creating functionality or
  2. Progress against creating deliverables.
Further assumptions include:
  1. The Data/Roles/Actions can be grouped into groups of functionality (e.g. #1 add items to grocery list, #2 review list in market, etc.)
  2. The functionality will be captured in deliverables (e.g. requirements, functional design, technical design, build objects, test scripts, etc.)
Once you have Data/Roles/Actions that can be grouped into functionality, functionality detailed in deliverables, when you add work planning structured by functionality or deliverables you have completed the entire connection of requirements, estimating, and work planning.

John Bellwin is a Senior Manager at Accenture, a global management consulting, technology services and outsourcing company, with approximately 236,000 people serving clients in more than 120 countries. John is a member of Accenture's Program, Project, and Service Management group. As a Program Management Office lead, John's work typically involves work planning, resource management, estimating, and requirements development/management.