…It seems our recent white paper about the CIO research has really sparked a debate.

Chris Spagnuolo, a very well regarded blogger, wrote a piece about it on his site and more than 40 people have commented and debated on the topic. There were some really interesting points raised – one of which being that the reason there is CIO apathy towards quality is because many are working to short-term goals…

…A new survey of CIOs found that “40% of CIO’s reported a general indifference towards the quality of the software they produce.” Also see the blog post about the survey with some good comments. Interesting. Not surprising, but interesting…

best,
oana

Do people question airline pilots performing pre-flight checks? No.

By all means let people question our processes, but can IT really be called a profession if it does not have and can not justify good practice?

I think as a QA professional the best we can do is to educate Senior Management and build a business case in the language of ROI.

The basic vectors that fuels tolerance of less than high quality solutions is acceptance of risk vs overall IT costs. Risk acceptance is driven by overall company strategy, the CEO and board of directors. The CIO is charged with managing the IT infrastructure and deploying software and hardware solutions commensurate with the overall risk strategy of the company itself.

While certain areas may demand high quality solutions (HR, Government mandated compliance, Finance etc). Under favourable circumstances, the CIO may choose areas where lower quality solutions could be acceptable if there are elements of competitive advantage that accompany lower quality software tolerance. Early technology adoption for example may provide a clear business advantage for the company as a whole so long as the executives are willing to tolerate possible lower quality solutions. The potential business value may be high and the risks may well prove acceptable. This will require a high degree of communication and trust between the CIO, CEO and executive board.

One major concern for the CIO is that they and their IT organization will need to ensure that the executives are fully aware of all the risks and potential downside impact before embarking on a lower quality solution in the interest of improving time to market or dramatically lowering costs.

It would thus behoove the CIO to ensure that there is some published record of this agreement before embarking on such a venture.

Fact is, “Quality” can mean a lot of different things to a lot of different people… does it fill the business need? does it make us money? quality by itself has no meaning to it.

Once you start putting $$$$ to quality, they will care, but it has to be some really BIG beans!

Try talking about the maintence cost of software with a CIO, then you’ll get their ears perked up because that’s something you can wrap your arms around.

It’s also about costs. Take two developers: The first has 10 years of experience, a varied and extensive background, and is a solid architect. The second has 2 years of experience and thinks scrum is a rugby term. Which one do you think will produce high quality code? Which one costs more? Could they both get the job done?

To build quality software, you need quality developers. Not all CIOs have a “quality” budget.

There have been numerous reports in the IT press indicating we spend 70% of our total development budget mantaining existing applications.

From what I see, increasing the quality of the software would decrease the cost of maintaining it.

Surely, that would be of interest to a CIO?

The situation would be better if our software worked effectively for all users of that software. Unfortunately, software often only meets the quality requirements of a subset of the eventual customers.

Is the product “good enough” to launch in terms of any potential impacts it might have to:
Product Sales / Company Reputation / SLA penalties / Market Share / Competitive Advantage / Perceived Quality / Preceived Value *relative to the competition* / Upselling of future upgrades / etc.

True, some executives simply don’t understand “software” but even those that do are subjected to pressures that the development team (and even development management) are not subjected too.

There are VERY FEW businesses that absolutely require top quality in software (as in life-and-death): health/medical, aviation, no others come to mind. And even those or military or pharmaceutical have the concepts of acceptable errors. Simply because 100% is not only almost impossible to achieve, the cost to get there outweighs the value returned.

You can’t name any software developers who ship perfect software – there is always some leeway for fixpacks, upgrades or workarounds. In Agile terms its about highest value, highest priority being delivered first.

As a developer I love to have software where I can say “no bugs were ever found” (not don’t exist, just weren’t found) but I also realize that those low probability, low value User Stories/Use Cases do exist and, time for money, aren’t worth fixing.

Add to that the fact that users are (sadly) becoming more and more accepting of errors and corruption and “bad stuff” in software its become more and more likely that Quality Assurance will turn into Quality Acceptance.

Deciding how far to work down the Priority / Value chain in a given product and when to stop adding value and Ship is why the decision makers get the nice offices. Its not a happy thought but it is reality.

-Terry

The typical scenario is that a solution only costs (eg) 10,000 to develop / implement – in this financial year – so contractors get paid for bigger/better/faster/cheaper. What most don’t care to mention is that there is then another equal 10,000 or greater amount spent in the following year to correct or complete what should have been done in year one. But – hey – that doesn’t matter, it’s lost in the books of another financial year. We can simply bring in more consultants.

At CobbleSoft, I will absolutely go postal if we ever try to develop and deliver a half-baked consulting solution or upgrade to our service management software. Yes, I am sure we have lost work/revenue because of it, because we add perhaps one extra week to truly wrap up a project versus other folks.. Hmm .. an extra 1k this year or an extra 20k next year? Regardless, I know full well that our customers are getting a top quality product that offers functionality AND stability. That, unfortunately or fortunately, is my mindset, and the one upon which CobbleSoft is founded.

In a perfect world, we would all want to produce the highest quality product. But in the mean time, someone with a slightly less superior product beat us to market and now control 80% of it…

The 40 % that do not care – well maybe they should also spend less time answering sureveys.

Quality needs to be lived throughout the execution lifecycle, basically build it into the process (here is where my passion of Lean comes out)…..creating a “rabid customer focus”. This is what I would want a CIO to focus on….drive quality into the organization at all levels and hold the leadership accountable for executing on quality processes that deliver quality product.

1. Mediocrity in IT has become acceptable and growing.
2. People are being employed (longer?) for the shortcomings and ignorance of IT leadership.

Read more and download the entire article via: http://measuresw.com/news/SMSNews2006/ImprovementChampionIssue10.html .

if the outcome of the development department is not what the was required then get rid of that area, move people, do not assign critical processes to that team, buy a canned solution to temporarily walk around the problem, outsource development or testing only if you have brain damage, if you are the owner’s son or a saboteur.