The SEI have just published a new report by Goldenson and McCurley. The report shows an interesting correlation between what high maturity organizations themselves report about uses of measurement and what appraisal results say about the organizations.

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!

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

In the April 26, 2010 print edition of Informationweek, the Dr Dobb’s Report contained a an article by Sid Sidner of ACI Worldwide describing his teams choice and implementation of a Static Code Analysis tool.  ACI looked at:

• AdaCore’s CodePeer
• Coverity’s Prevent
• GrammaTech’s CodeSonar
• Greenhill’s DoubleCheck
• Klocwork’s Insight
• Lattix’s LDM
• Microsoft’s StyleCop
• Ounce Labs’ Ounce Core

You can read Sid’s comments on each of these tools in his article.

The article is a very good description of how to integrate a software analysis tool into the development environment. Some engineering shops like ACI are a little bit ahead of IT organizations in building quality and security into their products.

Sid offers the following “Tips for Success”:

• Define an “initial issue” policy - what will you do with the code issues that identified by the first analysis run?
• Get the global mechanics working - many of the tools require license managers and centralized result servers
• Attack one product at a time
• Identify SMEs - those product experts who will also be experts in the tool
• Train the SMEs
• Work with the SMEs
• Train the developers
• Perform initial analysis on existing code and defer all issues - this is Sid’s suggested choice of “Initial Issue” policy.  Note that he suggested to defer not ignore.
• Deliver help from SME’s to developers as required
• Run the build anlaysis often
• Review deferred issues

I discussed this article with Lev Lesokin of CAST Software who have their own static analysis application, the Application Intelligence Platform (AIP).  Lev highlighted a couple of considerations which Sid’s paper did not cover:

1. ACI probably do a very good job building quality into their code at a module level, but they should also look at quality at a broad architecture level. Interactions between modules, between distributed components, and most importantly between the database and the code base. Some of the most risky quality issues actually reside in that application level and they are the hardest to identify by code walk-throughs or localized static analysis.
2. When analyzing your software, there’s an opportunity to also use that to introduce measurement. Sid could put some metrics in place to make sure his teams are getting better at building quality and security in. Also, risk metrics can be used to make go/no-go decisions at stage gates. This might be a point for his VP of Engineering, though. He/she can introduce productivity measures and drive the organization towards continuous improvement.

These two uses of software analysis and measurement products might not be as relevant for ACI, because much of the software they build is monolithic products that they ship and don’t see in a distributed environment until they implement at a customer. In an IT organization you will have many moving parts, connected through a services layer or various other interfaces. This is where app-level quality issues become much more present. Also, getting apples-to-apples measures across development teams in Java, .NET, DB stored procs, etc., is much more challenging. Once ACI’s customers integrate their newly acquired payments system into their bank’s accounts and cash management systems, they might consider an architecture-level analysis to determine how structurally strong their environment is in terms of stability, performance and security.

We often start our CMMI, measurement, estimating or other process improvement engagements with clients with a “gap analysis.”  Probably all of the readers of this blog have a pretty good idea what that means and so it is an easy entry point.

But I don’t like the term “gap analysis.” Why?  Because it carries with it the implication that it is an exercise in finding out everything that our client is doing wrong.  I prefer the term “opportunity analysis.”

In the April 2010 edition of SoftwareTech magazine, David Herron writes a very good perspective on this issue.  My own simple perspective is that every software development organization does some things well.  It must do otherwise it would not survive.  Hence, every software development organization must know how to do things well.  Finding the things the client does well is just as important as finding the things it does not do well because the pocket of excellence provide patterns for the improvement of the weak areas.

Further, identify the pockets of excellence is important because any changes must be carefully designed to ensure that the excellence is not compromised.  This is a classic mistake that we see too often - process zealots are allowed to bring everything the company does to the same “average” level.  This usually represents significant improvement is key problems areas but it can sometimes stifle the areas that were previously excellent and were making the company “special” to their customers.

Finally, for those of you who have time to go to read David’s article, I would also recommend the article by Capers Jones in the same edition, “Software Quality and Software Economics.”  Capers always delivers thought-provoking ideas and plenty of data points.

We have been using CMMI as a framework for our consulting initiatives for many years.  In recent years, it has become clearer that you can get a lot of value out of this approach without going all the way to a full accreditation.

In a recent (Jan/Feb 2010) article in CrossTalk, Jeffrey Dutton captured the essence of using CMMI in this way.  He puts forward three driving principles:

1. Focus on Business Issues and Performance Goals
2. Involved Leadership and Process Ownership by Process “Doers”
3. Improvements should be made at the Speed of Business

Jeffrey goes on to explain that the CMMI framework together withe three principles can readily accommodate different approaches like CMMI itself, Lean, Six Sigma and ITIL.

We are seeing more and more interest in this “multi-model” approach to get more value more quickly out of process improvement initiatives.

I must admit that I rarely use the Standish Chaos figures on what percentage of software projects fail in respect of their original estimates of cost, time and functionality.  This may seem odd.  Surely, they support the business case for using consultants who specialize in improving software development?  Well yes but they never quite correlate with my experience and, perhaps as a result, the latest percentage never quite lodges in my memory.

My own  disquiet has always been based on the feeling that the statistics derived from any such survey may be more correlated to the type of questions asked than the reality on the ground.  For example, when a project finally reaches that point where the customers admit that they really didn’t know what they wanted when the project started, is that a project failure?  Probably it counts as a “yes” but I would argue that it was a controllable fault of the software developers or their process. Maybe that’s where the Standish publishers are going with it.

Anyway, I was pleased to see my concerns validated in an article by J. Laurenz Eveleens and Chris Verhoef in the January/February 2010 issue of IEEE Software.  With significant statistical analysis using reputable sources, the authors identify the following four problems with the Standish Group figures in their Chaos reports:

1. “They’re misleading because they’re solely based on estimation accuracy of cost time and functionality.”
2. The Standish estimation accuracy definitions are not sound.
3. If the Standish definitions are used to drive projects, they may cause large cost and time over-estimations.
4. The Standish figures cannot be extrapolated across organizations because large forecasting biases exist in any given organization which make extrapolation, in the authors words, “meaningless.”

Interesting article by Jeanne Harris, Allen Alter and Michael Nieves in the September 2009 issue of CIO Insight (OK - so my reading list got out of sequence!).  Jeanne is a co-author of “Competing on Analytics” which I liked a lot.

Anyway, the article sets out a plan for CIO’s to increase IT capability while cutting costs.  The report takes the broader view of IT (e.g. it includes operational costs such as “telecom expense”) and groups the priority actions by the quarter in which payoffs can be expected.  I was interested in where cost savings in software development could be achieved.  The answer seems to be that there are no direct cost savings to be had although there may be implied cost savings depending on how your IT is structured.

The list is as follows:

Returns in Q1 (”Minimize” phase):
SLA’s
telecom expense
hidden IT

Returns in Q2 (”Optimize” phase):
thin-client computing
procurement management
application renewal
consolidation and virtualization

Returns in Q3 (”Redesign” phase):
process engineering
shared services
operating model and organizational redesign
sourcing strategies

Which of these do you think are cost saving strategies around software development?  Let’s set aside that they have omitted the most obvious and usual Q1 step - lay off x% of the development staff.  It seems to be that the software development gains come from Q3 in the form of process improvements and sourcing strategies.  That resonates with my experience if, and only if, you start those initiatives immediately.

I came across this in the July/August paper edition of Baseline magazine.  For those of interested in improving the business value of IT, the IVI is definitely worth watching and, if you have the inclination, participating.

The Innovation Value Institute, hosted at the National University of Ireland in Maynooth, researches and develops unifying frameworks and road-maps for IT and Business executives to create more value from IT and better deliver IT enabled innovation whilst validating that these frameworks/tools have a broad applicability across differing industries and contexts.

In association with its prestigious group of more than 30 consortium members, the IVI has developed a five-stage (of course) maturity model for mapping out IT improvements.  In addition to the five stages, there are four macro-processes:

1. Mapping IT like a business
2. Managing the IT budget
3. Managing the IT capability
4. Managing IT for business value

IT-CMF

For more information, check out the IVI website.