Follow us...

The Quality Problem Part 1: Defining the Problem

John A. Bellwin, JD, Accenture Senior Manager, www.accenture.com

I can guarantee, absolutely guarantee, that any software development project in any organization can meet or exceed user functional requirements. However, every organization that sees the bill for this guarantee is going to say: "That's too expensive." The problem lies not in the fact that organizations will not spend this money. The problem is that leadership is not being equipped to effectively decide what is too expensive and what is not too expensive.

That said, I will make a confession to start: equipping leadership to make these decisions is incredibly complex, and smart and successful people have had lackluster results. This article is not going to be a panacea, but it might just make us a little bit better. So here is how I am going to structure the conversation in this three-part series:
  1. Define the problem
  2. Propose a solution
  3. Discuss the mechanics of implementing the solution.

This first article seeks to define the problem.

Risk

First, in equipping leadership, there are no absolutes (is that a contradiction?). It is a question of risk. The risk is that the quality of your software does not meet user expectations. If you are NASA or ESA developing software for a space mission, there is going to be little tolerance of risk. NASA is going to spend plenty of money to ensure there is very little risk (hopefully, anyway). 

Projects that develop software to manage my hotel points will have more risk.

The problem is that leadership is often unable to weigh the risk. Leadership may not be informed about the risks, leadership may not appreciate the risks, or leadership is told but simply does not have the tools by which to evaluate the risk.

Elements of Software Development

Before this problem starts looking like a behemoth, let’s talk basics. Every software development effort answers three questions:

  1. What is the data that will be used?
  2. What roles will use this data (aka security)?
  3. What steps will the roles perform when using this data?

And my perception is that a huge number of software development failures can be traced back to a failure to answer these three questions in a timely manner. The problem is that it is expensive to answer these questions. Add in the timeliness component and the problem becomes complex.

Do not take my word for it; here is a way to test it. Ask yourself this: does your software project have a documented answer to all (and I mean ALL) of the data that your system will use? And that documentation needs to identify:

  1. Class of Data (e.g. "Grocery Product Data") and
  2. Attributes of the classes (e.g. Grocery Products have a type, brand, size)
Steps and roles have problems too but I usually see the scary answers with data. And yes, I do need to give the Unified Modeling Language credit for this idea. 

Cost

It is expensive to answer these three questions. 

Answering these three questions in a timely manner becomes even more expensive. 

Any solution to quality challenges has to decrease the cost of answering the three basic questions and has to provide timely answers.

The Questions that are Not Asked

Leadership often does not ask: do you know what the data/roles/steps are? Often leadership needs to focus on strategy, on where their organization is going, and what that organization will be tomorrow. That focus does not leave room for the detailed data/roles/steps questions. 

However, leadership needs to strongly encourage team leadership to ask those questions. 

It is not an easy problem; next month I will suggest a structure for tackling it.

Image: ©iStockphoto.com/Mariusz Prusaczyk



John 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.