Follow us...

The Quality Problem Part 2: Proposing a Solution

John A. Bellwin, JD Accenture Senior Manager,

Problem: often corporate leadership does not have the tools to know the right price to implement software functionality. (See The Quality Problem Part 1: Defining the Problem.) This article addresses the solution to that problem.

So what is the solution? 

Start with a cost/benefit analysis (rocket science, I know). Let me focus on the cost part of that equation. First, answer three questions about the software functionality: 
  1. What is the data? 
  2. Who (what roles) uses the data? 
  3. What steps happen when the data is used?
Second, use the above answers to estimate the project:
  1. Design for functionality that requires two classes of data across two roles doing one step will require X hours. 
  2. Build for functionality that requires two classes of data across two roles doing one step will require X hours. 
  3. Test... 
  4. Deploy...
Now here is a significant appeal of this approach: it provides a structure for the communication with leadership. When leadership is not interested in the details they can ask: what functionality are you implementing? And then leave it at that. When leadership wants to know the details they can ask: what is the functionality, how many data classes, who is using this? The answers to those questions fit nicely into an evaluation of the benefit that the functionality will bring.

For example: suppose you are building software to track grocery list items. One part of the functionality is: adding product items to the list. This involves one class of data (the product), two roles (parents and children -- the children have security restrictions which prevent them from adding Froot Loops to the list), and one step (adding the item to the list). The estimate to design/build/test this software functionality is eight hours. 

However, suppose you want to add by "recipe" to the grocery list, i.e. pick a recipe and all the necessary items show up on the grocery list. This involves two classes of data (product and recipe), two roles, and one step. The estimate to design/build/test this software functionality is 12 hours. This structure allows leadership to decide whether "recipe" lists are really worth four hours of work.

So what does an organization need to implement this approach?

An organization needs three things:
  1. History 
  2. Consistency 
  3. Similarity
First, history, an organization needs to be able to track how long (in hours) it takes to do the design for a given number of data classes/roles/steps. Knowing how long a design/build/test takes enables an organization to predict the cost of the functionality. In order to have this history, organizations need a tool to track these hours. My favorite is Microsoft Project Server because of its strong work planning, time tracking, and excel based reporting capabilities.

Second consistency, organizations need a process that is consistently repeatable; this is one of the attributes that makes the history meaningful. In order to do this, a software development methodology is needed. The methodology needs to do three things:
  1. Identify the software development deliverables and provide a template for the deliverables. 
  2. Identify the role that will create the software development deliverable. 
  3. Identify the input deliverables that a role has when they are creating the deliverable.
Third similarity, the number of data classes/roles/steps identifies the similarity from one project to the next. This means that the organization needs to track data/roles/steps in its requirements and those requirements need to be in a tool that is accessible across the organization. Typically, I use Rational RequisitePro to get the job done. However, HP's Quality Center may work equally well.

Image: © Prusaczyk

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 Core Group in North America for the Program, Project & Service Management Capability. As a Quality Lead, John's work typically involves work planning, resource management, estimating, and requirements development/management. <