The Quality Problem Part 3: The Implementation of a Quality Structure

John A. Bellwin, JD, Accenture Senior Manager,  

Let me begin with a brief recap of our quality conversation:
  • Quality is: meeting stakeholder expectations. 
  • One stakeholder group is users with expectations of software functionality. 
  • A second stakeholder group is corporate leadership with cost expectations. 
  • Often there is a tension between users and leadership because users advocate more functionality and leadership advocates lower cost. 
  • The tension causes quality to suffer both on leadership and user expectations. 
  • Quality is improved when leadership is equipped to evaluate cost and functionality. 
In order to equip leadership, leadership has to be able to allocate cost to a specific functionality. 


Accurate estimates come from:

1. History - A record of how long it takes to complete a deliverable.
2. Consistency - The need for deliverables to be consistent across projects.
3. Similarity – The ability to compare project size based upon functional requirements.


Organizations that have a record of actual hours required to complete a deliverable can use this record to estimate future deliverables. There is resistance to time tracking (I know). One way to mitigate the resistance is to send a message to the organization that “we are not tracking your time, but rather we are tracking the time it takes to complete a deliverable”. People will be required to record time only when they are working on deliverables for which the organization needs a record of actual hours required for completion. This message helps shift the emphasis from a big brother tone to a "we are trying to make the organization better" tone.


Organizations can create consistency in their software development process with a methodology. The methodology identifies:

1. Deliverables (with a template).
2. Role that creates the deliverable.
3. Inputs that the role has at the time the deliverable is created (e.g. a design is an input to a build).

These three things in a methodology provide a foundation for consistency.


Organizations can evaluate similarity between projects by having a requirements process that identifies:

1. Data used by the organization.
2. Roles that use the data.
3. Steps that the roles take when using the data. 

The consistent identification of the data, roles, and steps involved helps to compare the functionality in one software project to a second software project. Plus, a strong documented identification of an organization's data helps in other ways too, e.g. leadership understanding of operational reporting.


The same three elements used in the requirements process (data, roles, steps) can also be used to define software functionality. To return to my grocery shopping list example, software that has the functionality of "adding grocery items by product" has one data class (product), one role (shopper), and one step (adding the item). 

Do It?

Some questions that may help leadership evaluate whether their organization needs to adopt a history, consistency, and similarity approach are:

1. Has the cost of unpredictable projects risen to a high level?
2. Is ambiguity in the definition of functionality hampering leadership's ability to understand what they are buying?

No one answer fits all organizations, but hopefully this approach gives a place to start.

Read: The Quality Problem Part 1: Defining the Problem 

Read: The Quality Problem Part 2: Proposing a Solution

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.