Being late is not an option!

In Quality: Fit For Purpose, we wrote that there are four major categories of quality: delivered defects, fit for purpose, cost, and timing. Several readers wrote to me directly to point out that all of these categories were interrelated (the word covariant was even used). In addition to the covariance comments, they pointed out that cost and timing are often viewed as capricious. I would like to point out that as soon as a team or leader accepts the work, says “yes” it doesn’t matter if the agreed-upon cost and timing is stone cold crazy.  I like the saying, “you bought it, you own it.” All customers measure quality based on their needs and what they think has been agreed upon.

Now on with the show!  

David Chappell proposed that software quality can be viewed in a framework that includes functional, structural and process quality.  Fit for purpose is a measure of functional quality.  Cost and timing are a measure of process quality. In Chappell’s model process quality is a measure of how the work was performed. Classic outcome measures of on-time, on-budget, and process and process quality assurance (PPQA) evaluations are examples of how process quality is measured. Process quality often impacts the business value of a product.  A perfect solution that is delivered before its time, or as many times happens, is late will have less value (inventory costs for early delivery costs and lost opportunities for late deliveries). We can easily imagine two organizations racing to bring a similar app to market, all other things being equal, the organization that gets there first has a significant advantage. While most internal IT organizations are not delivering software directly to the market, they are supporting the value chain that delivers the organization’s products and services, therefore, timing and cost performance can impact the organization’s bottom line. Cost and timing are often critical components to the perceived quality of the service delivered by software teams. Cost and timing are intertwined since labor is a substantial portion of the cost of coding, testing, and implementing software. Each attribute can have a different impact based on context.

Cost overruns – All organizations, regardless of size, have to make money or at least break even to keep their doors open. In most organizations, a manager’s performance on staying within budget can impact bonuses, promotions, and in some cases employment.  In some cases, large cost overruns can threaten the existence of a firm. Managing cost can range from a non-issue (within planned expenditure) to a catastrophic blow to process quality. Note: My experience suggests that significant under runs of planned expenditures happen so rarely as to be not worth considering.

Timing – The calendar is the metric everyone in every organization understand. Late and/or erratic performance meeting stakeholders’ and customers’ timing needs (regardless of whether the needs are rational or not) impacts the process quality. Like cost, the organizational impact of timing problems can vary from meh to catastrophic. As an example, earlier in my career, I worked for a major financial institution  Not delivering the software that allowed the firm to meet the deadlines for regulatory reporting was a major quality failure (and career limiting).

Cost and timing effect how the process quality software delivery is perceived. Software that is late and costs too much is never considered quality. The short cycles found in agile are a tool to help manage the perception of process quality (that assumes that short iterations are closely coupled with actually delivering software that is fit for purpose into production). In the end,   even a piece of work that is fit for purpose and has no defects but is late and costs too much is not quality!