At DCG, when we work with clients we often conclude that spreadsheets may be the most appropriate way to manage a simple metrics program.  However, I was reminded this week (based on an incident at a client which caused me to look up the appropriate section of “Competing on Analytics” by Thomas H. Davenport and  Jeanne G. Harris) that there are a couple of common problems with basing your metrics program on spreadsheet repositories:

• Errors - Raymond Panko wrote a much referenced article back in 1998 based on his research which suggested that 20-40% of user-created spreadsheets contain errors.  The more spreadsheets, the more errors.
• Multiple versions of the truth - too often there is not a single, multi-user spreadsheet but multiple versions being spread like a virus across an organization by email, each with its own few unique data values.
• Unintended uses - the data in spreadsheets are very difficult to keep under control when key data elements are changed to meet new needs.  The knock-on effect on linked data can be catastrophic but not necessarily visible.

Worst of all, its almost impossible to debug or do a data integrity check on even a mildly complex spreadsheet.

The lesson - use spreadsheets as much and as often as you like but do not attempt to build a serious metrics or estimating application on them if you want it to have a useful life in your organization of more than one year!

In my posting of November 18, 2009 entitled “DCG’s Software Development Value Index - A metric for effectiveness, efficiency and economy,” I referenced the concept that the system represented by a software development group takes inputs and performs a transformation of those inputs into outputs.  I proposed a system-based metric for assessing the value provided by the software development group as a result.

Now I would like to come back the concept that the transformation part of the process can be value neutral, value add or value multiplier.  What do I mean by those terms and how should they be prioritized when considering a project portfolio for a software development group?

A “Value neutral” project does not change perceived value of product or application e.g. some architectural changes, bug fixes, make work.

A “Value add” project clearly adds to perceived value but probably only for a subset of all the possible beneficiaries.  Examples might be interfaces to 3rd party software, incremental functionality to existing component, new local capability.

A “Value multiplier” project increases value for all possible beneficiaries.  Examples might be new front end, new component to enable new clients/market, new general capability, new language support.

Obviously, in an ideal world, all projects in a software development portfolio would be value multipliers.  However, that is not realistic and could even be a high risk allocation of resources.  In practice, a typical portfolio will contain a mix of the three types of project.

So what is the right balance?  It depends on the risk tolerance of the business, the available discretionary funds and the degree to which the business can drive the software development group to be flexible.  However, the DCG “rule of thumb” is to appotion your software development dollars somewhere between $1-$2-$1 and $1-$2-3 for value neutral - value add - value multiplier.  In other words, always try to spend twice as much on value add as value neutral then try to spend one to three times the value neutral amount of value multipliers.

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 believe in process and spent my early working years on the factory floor (managing a high-tech production line).  Consequently, its quite comfortable for me to fall into the common trap of wondering why we can’t just build software the way we build cars - on a production line - maybe even using robots for some of the tasks!.  From a process, measurement and statistical control perspective, the production line model would surely help us develop software better, faster and cheaper?

I was sitting in a conference last week listening to yet another speaker fall into this trap.

Why is it a trap?

Because before you can apply the production line model to software development (and complain about the shortcomings of software development groups), you need to do a little imagination experiment with me.

First of all, I need to you to conjure up that standard production line video in your minds for me - you know the one - with  shiny car chassis steadily moving down the line while humans and robots attach parts, paint parts, test parts, etc.  Pick your favorite car and imagine it being assembled.

With me?  OK, now I need you to consider that every car will be slightly different - some will have moon roofs, some will have two doors, some four and so on.  Well OK, these modern plants are very flexible and they can cope with a lot of that but the sophistication of the logistical process that supports the build has certainly jumped up a notch along with the industrial design engineering needed to make the production line work (quite separate from the design of the car!).

Hmm, what would be the equivalent to that sophisticated logistics and industrial engineering in software development groups.  Well, in most SD groups, we have some tools to help us with configuration management and testing (if we are lucky), probably some code libraries and maybe even some formal processes.

OK, lets get back to our mental picture of that sophisticated car production line.

Now I want you to imagine that the same line that produces your favorite car with trucks flowing down it.  And buses.  And Formula 1 cars.  And tanks.

I know what you are thinking - don’t be stupid, Mike.  You wouldn’t put all of those things down the same production line.  It wouldn’t be cost effective.  Some of those things will never be on a production line - even if such a production line could be designed.

Duh!