Are CIO’s Indifferent Towards Quality Software

Post written by Chris Spagnuolo. Follow Chris on Twitter 45 comments

Last night I read through the results of a study from Original Software entitled Software Quality and Testing: A CIO Perspective. After I read it, I had to pick myself up off the floor. “Why was Chris on the floor” you ask? Because one of the main findings of the study was that 40% of CIO’s reported a general indifference towards the quality of the software they produce. When directly asked “What is the perceived importance of Software Quality Assurance (SQA) in your organization?” here was how the CIO’s responded:


I found it really shocking that 25% of CIO’s considered SQA “Nice to Have” and 15% apparently don’t even think about it. Why this is so shocking is that the same exact CIO’s who said that SQA is not really important to them said that their #1 management challenge is cost reduction. Hmm…consider the cost of software failures (both small and catastrophic) due to low quality. It could be in the millions from lost revenue, a reduced customer base, and let’s not forget about the law suits if you really messed up. Now, reconsider the cost reduction strategy. 40% of the CIO’s surveyed had not invested in any type of software automation at all. Only 1/3 made a significant investment of over $100,000 in testing automation, and another 18% were “just dabbling in it”. When you consider that really large companies could spend upwards of $250,000 on automated testing tools, it seems like a small amount to spend considering the large amount of money a company stands to lose due to catastrophic software failures.

To me, this cost reduction (or avoidance) strategy just makes no sense at all. I believe that CIO’s that ignore is discard the benefits of testing have a careless disregard for customer satisfaction, not to mention disregard for the long-term bottom-line health of their companies. To me, it’s a short-term, near-sighted solution, that in the long run can cause the demise of otherwise healthy software companies. So, do yourself and your customers a favor and make the investment in software testing. And if you decide to make SQA more than just a cost of doing business, make it a fundamental business practice or a strategic business imperative, you’ll have a competitive advantage over 56% of the rest of your competitors.

Note: The survey was conducted by Richmond Events and sponsored by Original Software. The respondents were all delegates of the CIO Forum in New York, their companies having average annual revenues of $5.8billion, and IT budgets of $764 million.

Click HERE to download the complete Software Quality and Testing: A CIO Perspective whitepaper.

Share on Facebook
Post to Google Buzz
Bookmark this on Yahoo Bookmark
Share on FriendFeed
Bookmark this on Digg
Share on reddit
Share on LinkedIn
Share on StumbleUpon
Bookmark this on Delicious

  1. Ben Carey said,

    Based on the information that you found, I think you probably hit it right on with the long-term and short-term insight. Cost takeout strategies seem to be very short-term focused and unfortunately tend to cut things that have potential long-term impacts (like everything you mentioned).

    The hard part for executives seems to be in balancing the long and short term. While cost reduction is immediate, investing in quality takes time to start to payback on the investment. With agile methods we start to change that equation a bit because we focus on lean testing techniques, heavy automation, and faster releases. If we can execute on building in quality, get our products to market faster, and get our software in the hands of our users, then we can see the payback much faster.

    The cost takeout might slow the bleeding, but I think the sustainable solution ultimately focuses on high-quality delivery.

  2. matt mcknight said,

    I think you may be thinking of a different sort of QA that the surveyed CIOs. In the very large organization that I am supporting, much of what is called QA is a waste. We are doing a very agile process. The developers understand the needs of the business better than the other people on the project- including many of the people that use the software and the testers. The developers fought to have the testing automated with free tools so that they could use it- it allowed us to get rid of the 40% of the testers that didn’t understand the business at all and just came up with bogus usability suggestions labeled as bugs. We have people in a huge QA group that do nothing but go to meetings. Please don’t call them testers- they will go nuts: “I am not a tester, I’m in QA.” We cut our QA and testing costs by 50% and vastly improved our delivery speed. Just because people aren’t increasing costs doesn’t mean they aren’t improving quality.

  3. Bruce Taylor said,

    In my experience, CIOs (and CEOs) care very much about software quality – mostly because the buck stops with them when a customer loses a day’s business because of an error. So it’e not unusual to get support for quality process, unit testiing, and refactoring coming from the corner office.

    However, this enthusiasm for quality almost never trickles down through the management layer. Because each layer of managers is subject to greater and greater pressure to meet arbitrary deadlines with insufficient resources, they have to make harder tradeoffs. I don’t mean to offend middle managers with this, but it’s my observation that managers will trade off those qualities of the software that they are not personally evaluated on. They will get hammered if they go over budget or miss a delivery date, but poor quality can usually be patched and covered up long enough for them to be promoted and reassigned away from the problem. (Sorry, that wasn’t fair to those managers out there who are committed to delivering a quality product – but you’ve seen the people I’m talking about, and I believe that you’re in the minority.)

    Now, the programmers are (usually) committed to quality because they’re good engineers, or because they will be evaluated on it, or because they know that they have to maintain the product going forward, so they want to take the time and resources to do the job right. Sure, there are sloppy programmers out there who rely on QA to make everything right, but not as many as you’d think.

    So you have this pressure for “hurry up and finish and damn the quality” coming from the top, and “let’s do this right for once” coming from the bottom. Where do they meet? Right, at the first level manager in charge of the team, its schedule, and the product quality. He or she has to somehow try to reconcile these irreconcilable directives, do the difficult balancing, and put our a product. That’s why the first line manager’s job is the hardest in the building (really!) and why they burn out so quickly.

    Of course, this is all from personal observation and I don’t have citations or surveys to quote, but I’ve served a long, long time in this business and I’m pretty confident that this is a good model. Your mileage may vary, of course.

    - Bruce

  4. Bob MacNeal said,

    Thanks for pointing out this study Chris.

    I was pleasantly surprised that 45% of the CIOs considered quality either a “fundamental part of” or “cost of” doing business. Indifference toward quality is understood in the context of today’s business culture (emphasis on quarterly short-term “wins”) and the nature of the products we’re building (soon to be replaced or obsolete…anti-pyramids).

    Few of us, from senior executives to green developers, are far from being temporary piece workers. The time frame for many software initiatives is 3-6 months. Poorly conceived and constructed “solutions” are often celebrated as wildly successful. Few of us are still around once the failures of poor conception and execution are felt.

    I suspect the path toward becoming a CIO has less to do with quality than with spin and sugar-coating systematic failure. That’s not a knock on CIOs. We all are products of our culture. Quality comes down to personal preference (and pride).

    Quality is integral in the software I write, but it has little to do with longevity or cost containment. I build quality software for aesthetic satisfaction. The same reason I build furniture with impeccable joinery. I just like a good joint.

  5. Arif Gangji said,

    I don’t think they are indifferent, I believe that it’s a balance between time/cost, requirements, and what can be done.

    In essence that’s where Agile is supposed to help (but you would already know that working for Rally – I think our logo is still up on the wall there).

    Quality is always high priority, but it comes at a cost and in some cases the cost is very high and may not allow for the level of quality that should be required.

    You get what you pay for right?

  6. Scott Barnes said,

    My experience points to the same observations that Bruce has made. Often there is a substantial divide between generating revenue and delivering software. This is not always the case and I do hope that analysis shows a trend towards delivering value rather than “a project”.

    In general the results of these studies should be compared with the methodology and specific questioning that was used. For instance if you ask the question: “If you had to choose between generating revenue or fixing bugs, which would you choose?”, the answer is obvious to upper management. Without generating revenue you will not be able to afford to make those changes. On the other hand, without quality software you likely will loose business, at least to some degree.

    My firm has successfully integrated Agile Scrum within a 6 Sigma environment and the results were excellent. We received great praise from upper management, awards, etc. I do not though, believe that from the start of the project, upper management was counting on such high quality delivery of software. I believe it was more amazement rather than an expectation.

    I believe as Agile Trainers, Coaches and Consultants, we have an obligation to be creative in how we integrate Agile with upper management’s expectations and experiences.


  7. Ray Sullivan said,

    I am a little suspicious of making declarations such as CIOs being indifferent to quality without knowing much more of what was asked, and to see what biases are built into the questions (this is very important when the survey is conducted by a software vendor with a product to sell). I’m not convinced yet that the results of this are fair or accurate in this context.

    Having said that, here is my experience with CIOs and their view on quality. They do believe that quality is very important. They also are also under great pressure to deliver the highest value for the dollars they spend on IT and services.

    They also believe there can be many paths to good quality. Not having a formal SQA function does not mean that there is no quality. Some of the best quality software products I have seen have been built by a team of developers that furiously stuck to solid XP practices, where acceptance testing was performed by a developer, not a “QA” person. Other teams do just fine without extensive automated testing. I believe for the most part that is less of a decision away from good quality; rather it is more of a lack of maturity in their overall development process.

    My final thought is that CIOs do often have a hard time influencing quality downwards in their organizations in a meaningful manner. They absolutely need to have people working for them who get the vision and can keep it moving down to the lower layers. A breakdown at any layer of an organization can cause the message to become blurry or lost.

  8. Siobhan Walsh said,

    I think it depends on where the quality is delivered. If a piece of software does the job, works effectivley for the user and delivers against cost then the quality or the beauty of the code are, to my mind secondary. The CIO function is often to align the IT and the business need and the perception of the user is that I need a system that does X, rather than a system that is beautifully written.

    I agree with Bob that in these circumstances, quality needs to be seen within the context of the business – system X may only need to work as long as it meets the needs of my customer, as soon as it doesn’t I, will want system Y and the speed at which I can have it up running and solving my problem will impact my perception of the quality. Fast and responsive will win out time and again over beauty.

  9. Paul Ellarby said,

    Not at all surprising to me, Chris. CIO’s (indeed, almost all CxO’s) are focused on the business (i.e. maximing profits, minimizing expenses), not necessarily on the subject matter of their organization. Having spent almost all of my career in consutling (including 10 years at EDS outsourcing various companies IT organizations), the focus of most CIO conversations is cost, NOT quality. They want to get more done, cheaper, faster – quality is often an afterthought (or at least a distant rd after cost and speed).

  10. cspag (Chris Spagnuolo ?) said,

    Apparently I made some sensitive CIO’s unhappy: http://tinyurl.com/6ebt9o

  11. cspag (Chris Spagnuolo ?) said,

    Apparently I made some sensitive CIO’s unhappy: http://tinyurl.com/6ebt9o

  12. Fred Held said,

    As a former CIO, 14 years, I disagree both with the study results and the concept. Poor quality software leads to a high incidence of business interruptions and expensive maintenance and we all know that. What we don’t know is how are some of the features in the software going to be used and will that lead to business interruptions or operational problems.

    Most of the time packaged software is purchased or leased and some customization is performed to meet the needs of the business. Additional software is integrated to meet specific business needs that the package nor customization does not address. User A discovers that if they put in a certain data set they will get out results (never intended by anyone) that helps their operation. This data is processed at a later time as if it was some other form of data and causes major business interruption problems.

    While at IBM, I ran into this with a well known CPG company. Distribution was using a system not intended for them and already made obsolete but not taken out of the integrated system. IT had no idea that Distribution was doing this and asked them to stop it. We all know how successful It was in getting Distribution to stop using an operational system regardless of its status.

    We caught this because IBM was helping the client implement its first B2B eCommerce system. We could not find how a certain function was being performed and in a meeting, Distribution explained what system was being used to accomplish this. IT denied the system was running and Distribution went to a terminal and brought it up. IT then realized why a certain financial module was giving “wacko” results.

    Any CIO that meets budget and schedule by implementing low quality, high error rate software MUST BE FIRED ON THE SPOT.

  13. Mateus Batista said,

    Yes, I think the most of all CIOs is commited with the results, or the final product, the problems and the adjusts will guide to improve of the software.
    But I think that the quality is important, but what quality level the product needs to be launch?

  14. Azmat Malik said,

    Do they have a military or Microsoft {;-)} background .. do it on schedule, and then do it again. Of course they HAVE to be concerned about ‘quality’ … the problem, like many other such matters, is that they dont know HOW to measure and assure ‘quality’ … probably because specs are established as they move in development. One way to reduce the ‘pain’ of quality assurance is to outsource. I can refer some real ‘quality’ software quality-assurance (QA) folks

  15. Anne Purvis said,

    I think if I were a CIO instead of an underling I would be indifferent to unless all hell broke loose. It is the job of the underlings they hire for a very good salary to make sure those things work. They work at an upper level and expect their management teams to handle the rest.

  16. Igor Iván Spiler said,

    of course they are not indifferent to software quality, by definition “quality” is what the customer expects from your product, if your software (or whatever product or service) produces results adequate to the expected customer group then it is enought, no need to extend budget, no need to outsource anything, it is your CIO or architect’s job to make sure it meets expectations (and what the expectations should be a.k.a. requirements).

    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.

  17. Bob Marshall said,

    Personally, I believe that senior management (CEOs of software companies, CIOs, etc) are not indifferent to software quality (nor to productivity, this being another facet of the same issue). In my experience, it’s much more about these folks “stifling their doubts” – rather than “honestly earning the right to their belief through patient investigation”. The belief in question being that their development teams and processes are as effective as possible. I have recently had an article published in the SMS monthly newsletter on just this topic (lead article: “Are All Executives Unethical?”). I feel that the question – and answer – resolves to one of ethics.

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

  18. Jerry said,

    Forgive my potential ignorance here, but my experience has concluded from the companies I’ve worked…..

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

  19. Phillip Cave said,

    I look at quality as a mindset and look to the execution process of delivering value, so with that perspective….. I find the statistic appalling. A CIO (or senior IT leader – VP, Director) is supposed to care about delivering value to the business. I would want this indifference to be much lower. What are our CIOs or senior leaders working on if not improving the delivery model? I saw this disregard first hand in a large IT shop where one senior leader (VP) had an “it’s all about me” attitude and was focused on politics instead of a sharp focus on improving the organization at large to deliver value. In this case the CIO was new so hopefully she will see through, but alas, personality and politics have amazing sway.

    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.

  20. Luca Botti said,

    Most CIO’s, like the rest of CxOs, do not care about software quality. They care (mostly) about quick results, short term realizations and not the long term.
    If a banking system is not top quality, other will come and add other features – easier than asking better functionality delaying the delivery.
    It takes a lot of strength to carefully plan for delivery, quality and functionality.
    If it was quality, no big three consulting would be…big three.

  21. Dr. Frank Harper, PMP, ITIL said,

    I’ve found that in the presence of cost and benefit data CIOs develop a laser like focus on the quality of the software they produce. The use of financial data provides objective metrics to evaluate risks of a certain quality level.

  22. Frank Ramirez said,

    Going to pull a McCain here and say I think the polls are flawed. I had the privilege to address 100 of the top CIO’s in the country at a Gartner event several years ago and these guys were very concerned about QA with software + the network . Most CIO’s of any stature understand the downstream TCO implications of lousy software and the cost implications for productivity loss and operational cost for maintenance and user support.

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

  23. Joseph Hewitt said,

    I don’t think it is that they don’t care, it’s just that they have so many metrics to meet and report on. Let’s be honest, they don’t have the same bosses to answer to that we do. Support is a downstream cost. They’ll worry about and account for it later. Thus, in comparison to other factors they must answer to, initial quality is probably not top on the list.

    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…

  24. Frederick Constantineau said,

    Every CIO I meet mentions software quality as one of the top 5 things they care about. This is becoming even more important as outsourced applications become older and less predictable as a result of half baked testing earlier in their existence. It was more about passing functional testing than anything else for outsourcers. Things are changing. The relationship between TCO and app quality is well known by CIOs, so much so that large investments are currently made to stage sw quality and standards gov COEs at many leading companies.

  25. Richard Stevenson said,

    The comments made by Anne are absolutely right on the mark. Many CIOs are tasked to achieve: full-stop. It doesn’t always matter how, and hence the short-term trends that we have seen forever (and that then morphed into offshoring for an even quicker cost cutting). It is short-sighted, and I have seen this year after year, organisation after organisation, and it is particularly prevalent in the US.

    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.

  26. Terry Hamilton said,

    Its not about indifference, its about Return On Investment and the (legal) obligation of executives to maximize profit for the owners.

    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.


  27. Ramkumar Ramachandran said,

    I don’t think it has become whatever-it-is overnight. When Quality is seen as additional cost and not seen as an inbuilt component, CIOs attempt to remove the cost-to-create-quality and thereby make the services cheaper. This is a very funny short-sighted outlook. There are also CIOs who want to know metrics like “no of lines to no of test cases” ratio, Code coverage metrics etc. to ensure that a good product reaches them. The Vendor also has the responsibility of conveying the CIO that quality is inherent, when you deliver application, you deliver well architected, well designed, well developed, well reviewed, well tested application. The short term goals on cost savings by CIO would only lead long term revenue leakages due to rework, production bombings, performance issues etc. In short a Visionary CIO would never compromise on quality…!

  28. Garfield Moore said,

    Perhaps how we measure the cost of quality is often naive.

    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.

  29. Larry Freedman said,

    For a truly technology literate CIO (the majority), I wouldn’t call it indifference. CIOs are subject to significant pressure to deliver more technology solutions faster and cheaper. There doesn’t seem to be the same amount of pressure to add “better” or “quality” into the mix here, so I think sometimes these CIOs will tend to overlook it. However, I do believe there are CIOs out there who do not have a technology background and no true feel for what all is actually necessary to deliver quality technology solutions. I would agree that these CIOs are indifferent to quality.

  30. Stephen Nimmo said,

    In a perfect world, all CIOs would list quality as being a priority, but unfortunately business users don’t demand “good, quality software”. They want it to work and they want it now. This leads to increasing demands to cut corners and get things done, rather than get things done right. I can’t remember a project where someone hasn’t said “we can go back and fix that later” – as if that ever happens.

    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.

  31. aalmeida71 said,

    In my experience the folks from the corner office care very much about software quality and understand very well the consequences of dropping the ball on Software Quality, and it is also my experience that to put money in it does not bring results as far as Final Product Quality. In my experience the solutions to achieve quality results come from the dedicated efforts of everyone involved in the process of delivering the product. It is not visible to expect good results if the “QA Department” is the sole responsible for the Final Product Quality. http://www.artdigitalonline.com

  32. James Peckham said,

    Well duh, CIO’s only care about beans. They’re big bean counters, so they only care about really big beans. Just like product managers (usually).

    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.

  33. Chris said,

    Wow, judging from the wide range of answers, looks like this simple survey touched a raw nerve!!!

  34. Martin Waterhouse said,

    The question you raise, “Are CIO’s indifferent toward software quality?” is easily answered: … “it depends”

    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.

  35. John Boal said,

    In my opinion, top leadership is interested only in the “appearance” of quality, or the reputation of quality. That is something they can sell. Unfortunately some leadership is cashing in on the history of quality and not ensuring it will remain. It takes time to tarnish a reputation and they know this and sort of borrow against that time by focusing resources on feature delivery. This ends up usually delivering shoddy features that mostly work, and then saddling the development and test organizations with technical debt and a backlog of bugs. Meanwhile top management can continue to sell product based on past reputation. It’s usually not a sustainable way to operate for more than a short-term gain. Top brass figure that the problems will get worked out eventually and a bruise or two on the reputation isn’t going to sink the ship. However, when security bugs and other issues like this come up, sometimes it is more than a bruise, and that can be a real torpedo to reputation.

  36. Frits Bos said,

    It is interesting to see these results, because how the CIO is evaluated will be a reflection on the overall culture within the organization. That said, the focus in most companies is to deliver results to move forward. I have seen first-hand the effects of a focus on doing everything “perfect” with the result that IT failed to deliver strategic functionality in time for the company to gain a competitive advantage that would have justified the development. It is a fine line to walk, since reality dictates that quick-and-dirty implementations often cannot be followed-up with a robust second release, and the CIO will also be responsible for not allowing the IT operations to turn into a complete mess. With those kinds of pressures to consider I too would not rate quality at the top of the list although I am personally in favor of ensuring the quality of results. I don’t think it is the extra cost of quality as much as the extra time it takes to get the job done “perfectly” each time, and I think it has very little to do with testing (what is implemented has to work even if the backend is held together with skunk works). Ramkumar has a point about vendor responsibility, but even that is a bit self-serving (with due respect) because no vendor wants a client to point the finger at their failures. Also, vendors will go along with shortcuts if there is a clear audit trail that the client demanded that: business is business.

  37. Shelina Mulji said,

    In my experience, I am seeing more and more CIO’s appreciate the value of good QA. However they are also convinced that QA professionals should not be costing as much as other IT professionals and that QA is the tail end activity.

    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.

  38. Mick Maguire said,

    In my experience this is the case – that is until poor quality bites them on the ass. One of my previous employers saw SQA as (in lean terms) non value added, i.e. waste, which should be trimmed and eliminated wherever possible. It was always a fight to hire QA staff and then he would only OK entry level.

  39. Duncan Campbell said,

    I am continually amazed how business will prod and poke into software development processes and question the role of testing whilst viewing it as a cost rather than an investment.

    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?

  40. Mick Maguire said,

    hear hear Duncan – every place I have worked that is not specifically a software shop (and some that are) have suffered from this problem.

  41. Joy'll Cambridge said,

    I find generally that this is not true with younger or newer CIO’s. I think the ones that are a bit more seasoned are not necessarily out of touch, just not as sensitive to the issues that poor quality software can create for the business. In general because they are more experienced, trends, newer technologies, & newer methods of doing things, they tend to be a bit slower in adoption & implementation.

  42. Oana Juncu said,

    Well, the technical debt of low quality is a delayed effect bomb. Some intelligent VPs (CIO or others) had the intelligence to do the right analysis of desastrous business impact of systems crash invest in quality and …do Agile.
    Unfortunately, this type of analysis is done after the disaster has happend, not before; quality is not enough considered in the risk management area.


  43. Tim Sandford said,

    Define the importance of quality in comparison to other factors – functionlity, development schedule, etc. Perhaps they can only give 40% as a view because their other priorities are significantly greater?

  44. PINGBACK said,

    PINGBACK http://www.aphids.com/agiletesting/2008/11/survey_says_40_of_cios_are_clu.html

    …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…

  45. PINGBACK said,

    PINGBACK from http://manualtesting.com/blog/?p=28

    …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…

Add A Comment


Creative Commons License
©2011 Edgehopper.com. Please don't copy me, it's bad karma.
Edgehopper by Chris Spagnuolo is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.