Software quality is a C-Level responsibility

Quality counts… more so today than ever before. As recently demonstrated by major glitches experienced in the financial sector, an IT system that goes live with a glitch can damage an organisation’s reputation, profitability, customer...

Share

Quality counts… more so today than ever before. As recently demonstrated by major glitches experienced in the financial sector, an IT system that goes live with a glitch can damage an organisation’s reputation, profitability, customer confidence and loyalty.

Quality is, by definition, fundamentally subjective. What represents good or bad “Quality” differs depending on who you ask and their individual expectations and experiences.

In today’s highly competitive marketplace, organisations are facing more challenges than ever before. It is a constant struggle to stay ahead of the competition, reinforce the foundations for growth and etch out a place in tomorrow’s business landscape.

More than ever, organisations are looking to optimise IT delivery to support business outcomes. And, with social networking and mobile apps changing the way businesses interact with their target market, the ability to deliver business-led IT solutions faster and cheaper is fundamental to an organisation’s success.

A considerable challenge for many organisations is the flawed approach in the design, development and implementation of IT systems. It is expensive, time-consuming and rarely delivers what the business needs or, indeed, expects first time around. This is where quality comes in.

What is “Quality” and, what is “good” Quality?

Quality should be specific and measurable; an objective way of measuring how successfully an IT system delivers the business outcomes for which it was designed. Quality should be considered from the start, focusing on preventing issues and removing defects as early in the software development lifecycle as possible.

Quality is not, as some people believe, the same as Testing. And, Testing does not equal Quality.

Testing is a way to measure Quality. Focused on defect detection, it is often Testing that highlights poor or unacceptable Quality which leads to rework. And, it is the substantial and unnecessary cost of rework that often highlights the need for an organisation to improve.

As for what represents “good” Quality, it is different for every organisation. It takes consideration of many relevant and contributing factors that may or may not include the business objectives, the desired business outcome, customer satisfaction, risk, regulation, compliance, cost and functionality, to name but a few.

In the context of IT, at a more granular level, “good” Quality may be measured using cyclometric complexity, code reuse, maintainability, scalability, function process-steps, performance, usability, look and feel, adoption rates and more. Whilst the list is limitless, an organisation will use specific measures that fit with its organisational needs.

The definition of what represents “good” Quality for an organisation should be a joint venture between IT and the business - a definition that is directly aligned to business objectives. Typically “good” Quality may be measured by speed to market, overall cost of IT delivery, engineering efficiency, organisational agility and risk, to name but a few.

Who is responsible for Quality?

Whilst Testing is not necessarily a C-level discussion, Quality certainly is, and it is the CIO or IT Director who should assume the lead role. It is, after all, an appropriate approach to Quality that will see IT playing a critical role in helping create a new leaner business model, one focused on maximising the business benefit delivered by IT.

A holistic approach to Quality should comprise a set of activities shared across the entire lifecycle - a Quality “wrapper” - not relying on any single phase or activity (i.e. Testing) to take sole responsibility.

Each activity should be expected to contribute towards Quality both tactically (i.e. the specific responsibilities of the activity) and strategically (i.e. contributing as one part of the whole to the end result).

Whilst the CIO or IT Director should take ultimate responsibility for Quality, the leadership team should comprise senior IT and business stakeholders as well as representatives from all contributing IT and business functions. At the very least, representatives should participate from Project Management, Business Analysis, Users, Development, Test, Infrastructure and Support.

Quality is not simply a measure of the end result. It is a way of life. An attitude. A philosophy. A belief system. As such, it needs to be embedded in an organisation’s culture from the top-down.

Behaviour begets Quality. Without a leadership team that has the ability to garner support for and influence the adoption of a more effective culture and approach to Quality, it will not be possible for an organisation to realise the far reaching benefits associated with such a move.

It is of critical importance for all those involved to understand they have a role to play in ensuring successful delivery - not just of the project or programme but of the business outcome.

By encouraging a shift in human behaviour to improve communication and collaboration, it is possible to create a highly motivated and committed team and, as a result, realise significantly improved Quality.

If all involved know what role they play, they will know if they are doing the right thing, aiming for the right target, and won’t be working at cross-purposes. Furthermore, providing a compelling vision answers the question “Why?” and, as a result, brings all involved together in a common objective, inspiring teamwork, excitement and commitment.

Summary

Adopting a holistic approach to Quality not only saves time, effort and money, but also enables organisations to reach extremely high levels of customer satisfaction, engineering efficiency, and quality.
Improvements in Quality must be appropriate and pragmatic, be as much about “Why?” as “How?” and focus on preventing issues and removing defects as early in the development or project lifecycle as possible.

Posted by Ben Fry, Retail Banking & Insurance Team at software testing and quality management company SQS


Enhanced by Zemanta

Find your next job with computerworld UK jobs