In the June 28, 2010 print edition of Information Week, a long-standing friend of DCG’s, Capers Jones, identifies three keys to ensuring software quality:

1. Defect Potentials - Make sure they stay below three per function point
2. Defect Removal Efficiency - Keep it above 95%
3. Quality Metrics - Apply them from requirements through maintenance

For those of us who, like me, need an occasional reminder on definitions, Defect Potentials are the probable numbers of defects that will be found in the various stages of the software development life cycle.  Defect Removal Efficiency is the percentage of the defect potentials that will be removed (or actually are removed) before an application or project is delivered to users.

Which brings me to a conversation that I had today with a client team who are seeing the numbers of defects increasing on a monthly basis this year.  The explanation is that resources are being diverted from the maintenance teams so less bugs are getting fixed.  The client team has been told that all will be well when resources and budget ad diverted back to the bug fixers.

“Aaargh!” was my thoughtful and considered response.  The client team asked what they could do instead to improve the defect numbers.  I told them that the money =resources=time) needs to be invested further up the supply chain where it can make a much bigger proportional difference to quality.  Peer reviews of requirements, designs, code and test scripts are the most cost effective and quickest way for an organization to change quality outcomes.  To be fair, the client team then remembered that some development teams do conduct code reviews (”… and the quality is pretty good”) but the other teams “… don’t have time.”  This is a classic misunderstanding of the value of time spent in different phases of the software development life cycle.

So I get home this evening and start to catch up on my reading.  The first article I pick up is the Capers Jones article and my conversation earlier today jumps fresh into my mind when I see that Capers has included the following table:

Software Defect Removal Efficiency Ranges:

Activity Range

Formal Requirement Inspections                    50% - 90%

Formal Design Inspections                             45% - 85%

Formal Code inspections                                45% - 85%

Automated Static Analysis                              55% - 90%

Automated Unit Test                                       20% - 60%

Regression Test                                               15% - 30%

Integration Test                                               25% - 40%

Performance Test                                             20% - 40%

System Test                                                     25% - 55%

Estimates are “mission-critical” for Software Product companies because:

• In the short term, the quality of the development estimate can win or lose a deal
• In the medium term, on successful deals, the quality of the development estimate can drive profit or loss on a deal
• In the long-term, the quality of the estimates drives the evolution of the products – not just what we say we will do in the road maps but what we actually deliver in releases.

Phil Laplante of Penn State is a prolific and respected writer on many software and project topics as well as being part of my local IT community.  In the July/August issue of the IEEE IT professional magazine, Phil steps back and writes a thoughtful and though provoking article that is perfect for contemplation on the beach.

In “Nexialism and the Law of Unintended Consequences,” (there’s a search term you won’t use very often) Phil suggests that to understand complex interactions that could impact our project risk we need to spend at least some time thinking in simple terms about the big picture.  Nexialism is defined as “the science of joining in an orderly fashion the knowledge of one field of learning with that of other fields.”

OK so that sounds a little grandiose and you might be wondering how it impacts your project risks.  Think of it this way, how many times in a failing project did somebody know that it was going wrong early but was never asked?  Is the test manager communicating (talking and listening) with the coding team lead (and vice versa).  What is the opinion of the DBA’s?  The performance test team?  Like it or not, these are different disciplines (or fields if you like) with different perspectives and, too often, we do not take care to “join their knowledge in an orderly fashion.”

Keith Baxter of De-RISK, based in the UK, has developed a simple but effective way of capturing and visualizing the impact of risk on a project estimate.  The approach, called Quality Based Costing (QBC),  and some examples are provided in the following paper on Keith’s website:

Quality Based Costing Paper

QBC is based on the responses to structured questions about each project component which seek to identify four costs for that component:

• Absolute Minimum
• Best guess/realistic estimate
• Contingency added
• Disaster scenario

The approach is then to apply Monte Carlo simulation to derive a probability distribution of the likely cost.  I particularly like an estimation process that includes Monte Carlo simulation because it forces the project manager and organization to make an informed choice about the risk they wish to take on each project.

An article by Tom Costello in the May/June 2010 edition of the IEEE IT Professional magazine caught my eye because the title sounded like a new CD from a favorite band of my youth, “Status Quo - The Silent Killer “

It’s not every day I can say that about my technical reading!

Costello makes the point in his article that, today, IT are often asked to justify the business value of every initiative that touches IT with the underlying requirement that IT is expected to create value for the business.  He goes on to ask the question, “So how does IT create value when the business model ‘in play’ isn’t designed to do so?” and then, “What can technology investment achieve?”

Based on the premise that if the first 80% of technology capability in a particular problem space can be delivered at a given cost then the next 10% will have a similar cost and the next 5% the same cost and so on, Costello’s answer to this last question is based on trying to work out where your company is on this particular curve.

With some simple but interesting models and charts, Costello argues that the potential for IT to create business value is dependent on whether the business growth strategy at any given time is proactive, reactive or passive and where the business sits in relation to its competitors on a spectrum of profit margins for different revenues.  Essentially, Costello puts the case that the only case where IT can be expected to create business value is when the business growth strategy is proactive and the business has low revenue but high margins relative to the competition.

Costello presents and interesting concept and one that can be fairly easily constructed for companies competing in the public space.  it brings to mind Christensen’s disruptive technology proposition.  However, it has weaknesses.  For example, it assumes that the problem space stays the same and doesn’t allow for low cost innovation due to changes in either technology capabilities or the business environment.  Such changes effectively reset the degree to which the current capabilities satisfy the problem requirements back to below the 80% level.  I guess that Christensen would argue that this is precisely the opportunity that a disruptive technology seeks to address because its business model is more flexible that the incumbents.

Finally, I wonder what the equivalent of this sort of analysis is for the government departments?

Interesting survey result in the June 2010 edition of CIO Magazine.  90% of respondents to a survey by Forrester Research reported that customer experience was “critical” or “very important” to the corporate strategy.  No surprise there.  The responses on the obstacles to improving customer experience were very revealing:

• 53% (over half) reported “No clear strategy for improving the customers experience
• 50% expressed a “Need for customer-experience management processes.”
• 49% are experiencing “insufficient cooperation across groups”
• 32% report a “lack of understanding about customers”

If any of this sounds familiar, you need help!  Give us a call or work it out yourselves.    All of these are solvable but the third bullet rings particular true across the business-IT interface.  We run across this all the time with our clients and it improvements in breaking down internal barriers DO benefit customers!

I see in a short report in the June 1, 2010 edition of CIO magazine that Forrester Research have coined the term “Agile BI” to describe an approach to business intelligence implementations that calls for incrementally delivering products versus a big-bang approach.  Having posted our Agile Approach to Consulting some months ago, it is nice to be able to say “Welcome aboard” to Forrester!

The May 19, 2010 edition of Computerworld magazine contained a couple of articles about the growing evidence that one of the reactions to tightening budgets in software development has been the increased use of open source software and the associated  “Hidden Snags”

It is clear that one of the attractions of open source is the availability of source code which is critical for integrating open source into the enterprise but this brings problems of its own (“Integration Jams”).  I have written before about the benefits of static code analysis and I really want to stress the value of getting a one-off analysis done of any significant open source code that you bring into your enterprise.  Such a one-off analysis can be delivered as a service and does not require purchasing or learning a new tool.

The SEER estimate by Comparison capability is something that I talk about a lot to company’s who are really struggling because their SWAG approach to estimating projects is neither repeatable nor coherent.  Often, the projects they are failing miserably to estimate professionally are mission-critical either for deliverables to customers or for internal investment (budget) planning.

At some point, these estimate amateurs may need to base their estimates on a repeatable sizing approach (of which Function Points is just one option) but they need to change their ways quickly so I often talk to them about doing estimates by comparison using SEER.

Even if you don’t see yourself buying a tool right now, I recommend investigating this approach so you can attend in real time or review later.  The technique is powerful even if the tool is not right for you.  DCG can also provide the tool as a Service so you can pilot the application or just use it a few times every year for this really important estimates.  For more information on this service, you can contact David Herron at d.herron@davidconsultinggroup.com.

The Estimate by Comparison application has traditionally been used to empower users to develop an understanding of software size; the single most significant driver of development cost, effort, and schedule for software projects.  However, SEER Estimate by Comparison has evolved and can be utilized with all of the SEER solutions to provide an insight into effective definition of scope through a series of project analogies and/or comparisons to a user’s repository of past projects, thus helping users to develop a reliable estimate on a project’s scope even when information is scarce.

SEER Estimate by Comparison further adds capability to the project team when used in a more contemporary manner. It can be manipulated in such a manner that a wide realm of subjective, qualitative alternatives can be evaluated in context of the project as a whole in a robust, repeatable and ultimately measureable manner.

I have heard or read the phrase “IT-Business convergence” a number of times in the past few months.  It’s a neat phrase but what does it mean?   Different things to different people it seems.  Some examples:

• One of our clients is seeking to collapse its various product offerings onto a single connectivity and data management architecture to serve multiple vertical markets - “IT-Business convergence”?
• In the May 17, 2010 issue of Informationweek, John Burns CIO of Credit Suisse investment bank talks about, “… the increasing convergence in the way business is transacted.  We’ve been very siloed because our products and business are diverse but there’s more and more commonality in the way business is transacted, and electronic trading is becoming more common across all asset classes.” - “IT-Business convergence”?
• In the May 24, 2010 issue of Computerworld, Julia King spoke to five “Pioneers of Convergence” including Paul Heller, CIO of our local giant Vanguard Group.   From these interviews, Ms King identified six indicator of companies that have a high-degree of “IT-Business Convergence”:

1. View IT as an innovation engine that continually transforms the business, often enabling new revenue streams
2. Regard their customers as kings and view customer service, both internal and external, as supreme
3. Rotate business and IT staffers across departments and job functions
4. Provide an overarching goal that is crystal clear to each and every IT and business employee
5. Ensure that IT employees know how the company makes (or loses) money
6. Create a distinct, vibrant and unique company culture