My colleague, Tom Cagley, has an excellent continuing series of interviews (podcasts) in our field of software measurement and software process improvement.  I commend the whole series to you but I want to particularly draw your attention to Tom’s interview with Joe Schofield which is an excellent conversation on the choice between function points and lines of code as an organizational software size metric.

Tom Cagley’s interview with Joe Schofield

If your interested in this blog, you might find the interview that I did with Ann All particularly the focus on risk.

Ann All\’s interview with me!

Its a week or two later and I have finally realized what was bugging me about a recent conversation with a group of representatives of an IT organization within a major company.

The theme of the conversation was how to measure the value of IT in a way that the businesses would understand.  In setting the scene for me, my new-found friends described all the classic symptoms.  The business can’t understand why IT projects cost so much and are often late; they perceive that they can’t possibly be getting optimum value because IT is a monopoly (with all that that implies).  On the other hand, the IT group can’t see how they can be expected to work in an optimally efficient way when the businesses cannot even execute a simple task like defining what they want perfectly first time.

Of course, I asked some questions specific to their environment and started the discussion about how they might make some progress.  It was this part of the conversation that started the niggling warning buzzer in the back of my brain.  They talked to me about the spread of their projects - nothing unusual there except the terms they used - something over half of their projects are “business as usual” projects and the rest are “initiatives.”  We continued the conversation to discuss which have business cases, how the business cases are monitored, how priorities are established and so on.  We started the conversation about how to work with the businesses to pick out value and compare it across projects.

Throughout the conversation, during the drive back home, through a very pleasant long weekend in Manhattan until now, the buzzer has been going in my brain.  What had I missed that might help? Finally, a conversation with a client who used the same term this week unblocked my brain.

What business value can there possible be in “business as usual” projects?

Of course, in hearing the term the first time, i just automatically translated it to the category “maintenance” projects.  But, hey, as an IT Value consultant, I think I prefer “Business as Usual” projects.

How many “Business as Usual” projects do you have?  By definition, they must deliver zero value to the business.  How much are you charging for your “business as usual” projects?  Do you think the business might have better ways to spend that money?

This led me to thinking about whether all maintenance projects are “business as usual”?  My first reaction to this question was that its a great value differentiating question.  I suspect that in most organizations the maintenance projects are a mix of business as usual and some tangible improvement to the business.  That bug fix - if left unfixed is it losing the business customers or costing money through some work around or is it just being fixed because its on a list that someone has?

The IT value optimization trick is to have a process in place that allows IT and the business to have a serious (but short) conversation about why IT is doing the ones that are truly “business as usual”.

Bill Curtis has been a friend and partner of DCG for many years and I was surprised and delighted to find that he is now the Chief Scientist of one of our other partners, CAST Software.  To get a sense of the contribution that Bill makes to our field and to get some really useful equations and numbers, I invite you to read his recent white paper, the “Business Value of Application Internal Quality”. Within this document, are several pages on mathematical calculations on determining business value / impact of application failure. Key topics include Corrupted data, violated security, terminated business transactions, lack of business agility, and others.

the-business-value-of-application-internal-quality

Writing in the March 2009 print edition of the Harvard Business Review, Susan Cramm listed the following seven “truths:”

1. Enhancements often don’t deliver results commensurate with their costs.
2. Projects are often too big and take too long, partly because unnecessary functionality is built into applications.
3. Previously purchased applications and infrastructure technology are often underutilized.
4. Project failure rates are too high.
5. Tech teams do not have sufficient incentive to achieve high quality and quality is often not measured.
6. Managers don’t know enough about the systems that support their areas.
7. IT is too risk averse: ” No one ever got fired for buying IBM or Microsoft.”

For each of these, Susan adds some useful tips for avoidance but she summarizes them best herself in her introduction when she says, “The discipline you develop now will pay off in a big way later.”  Superficially, I agree - more discipline is needed by most software development teams.  On reflection though, I have a problem with the statement - if we replace the word “discipline” with “system” or “enhancement” and its the very sort of unjustified claim that Susan accuses IT of making.  How do we know that more discipline will pay off in a big way later? More discipline tends to mean more process.  Is it universally true that more process will pay off in a big way later?

Now, of course, you all know that I am a discipline and process advocate.  However, especially when money is tight (when is that not true?), the key is that more discipline/process is not always best.  You need just the right amount of process to get the biggest return on the investment, have a business case for more discipline/process and, as Susan says, tie executive compensation to realization of value.

Finally, is it just me or are #4 and #7 oxymoronic?  But I know what she means!  It is a personality trait ot technical people such as ourselves that can carry off the split personality of the sharp intake of breath whenever management asks us to make a change and the “It’ll be alright on the night” mentality of “90% completeness” and “if we take a bit more time on development, we wont need as much testing time”.

Good news reported in the March 23 print edition of Information Week: The number of undergraduates majoring in computer science at U.S. Universities rose last year after six years of decline.  Apparently, increases were also recorded for Information Systems majors.

Our bright young people often see the pros and cons of the strength of an industry with a clearer eye than those of us who have been committed to it for many years.  Hence,  I see this as a very positive sign.   I will be looking for next year numbers with renewed interest.

Putting the facts up front, we, at DCG, are SEI Partners and advocates for CMMI.  Perhaps that is one of the reasons that our ears are finely tuned for criticisms of CMMI.  Many criticisms are baseless and a consequence of misunderstanding - wilful or otherwise.  Some are real and have a firm basis in experience on the ground.

One such criticism is CMMI compliance does not necessarily equate with good software in all cases.  This is the consultants way of saying, “They may be CMMI Level x but their code is awful.”  Is it fair to suggest that, sometimes, efficiency does not necessarily lead to effectiveness?  “All the indicators are green but there’s something wrong.”  I have heard clients complain about software produced which is, “compliant with requirements but never innovative”.

Here at DCG, we seek to mitigate such issues by deploying a portfolio of software development best practices through a Value Visualization Framework.  However, I saw an interesting article by Joseph M. Hall and M. Eric Johnson in the March 2009 issue of the Harvard Business Review.

In their article, “When should a Process be Art not Science?”  Hall and Johnson argue that the movement to standardize processes has gone overboard and that some processes require an artists judgement and should be managed accordingly.  They mention software development as an area in which this can be true and. although they don’t mention it, their argument resonates very strongly with the Agile Manifesto (make this link).

So how do we manage art?

Hall and Johnson propose a three step process:
1. Identify what should and shouldn’t be art
2. Develop an infrastructure to support art
3. Periodically reevaluate the division between art and science

Again this resonates with our consulting experience in agile development shops.  Too often, the success of agile implementations is constrained to only one or two successful teams because only step 2 is implemented.