A recent report by the National Association of State CIOs highlights 10 areas in which IT has delivered value to state governments:

• Business continuity and disaster recovery
• Cross-boundary collaboration and partnerships
• Data, information and knowledge management
• Digital government: government to business (g to b)
• Digital government: government to citizen (g to c)
• Digital government: government to government (g to g)
• Enterprise it management initiatives
• Information communications technology (ict) innovations
• Information security and privacy
• IT project and portfolio management

I really like this report because it is attractively presented, features real people working in state governments (with their photos) and describes simple ways to deliver value.  You can read it or download it at:

http://www.nascio.org/publications/documents/NASCIO-2008Awards.pdf

Here at the David Consulting Group, we preach that “Value Visualization” is a necessary step in the cycle of operations, measurement and improvement in IT organizations because it presents information in a way that enables senior management to make business decisions - both strategic and tactical. For more information, check out www.davidconsultinggroup.com/vvf/.

So imagine my delight at seeing a news story in InformationWeek about the IT department at General Motors using visualization software to reate mock-ups of software for business users in the same way as they create mock-ups of cars!  My Dad worked at the Ford Research & Development Centre at Dunton, England, and I still remember seeing the clay models of cars they used to make when we were allowed in for open days.  Interestingly, Mary Hayes Weier, who wrote the print article commented that, “Its the pressure of globalization and outsourcing that makes visualization particularly well suited for IT work at GM.”  I couldn’t have put it better myself in the context of our VVF.

The relevant InformationWeek article can be found at

showArticle.jhtml?articleID=211200920#community

I just realized that I haven’t posted a link to our book yet …

If you have read it, I would welcome some feedback.  If you haven’t read it, please buy it and let me have your feedback or tell me why you won’t be buying it.

ref=sr_1_40?ie=UTF8&s=books&qid=1225243195&sr=8-40

Thanks

 With thanks again to the folks at InformationWeek for their excellent survey results (see reference at the bottom of this post), I was curious when I looked at their tables to see if the split between legacy and new project spending in IT budgets was consistent or different by industry sector.  As you can see from the chart, it seems to be that there is more consistency than variation particularly in the context of the second chart that shows much greater variation in percentage of annual revenue devoted to It in the different industry sectors.  A current rule of thumb for legacy spending seems to be about 65% or 60% which is much healthier than the figure of 80% than was doing the rounds a few years ago.  Of course, if we are facing a down turn then spending on new projects, which tends to be more discretionary, will drop while spending on legacy, which tends to be about preserving the status quo or keeping the lights, is less flexible and more likely to stay flat than drop. We may see some retrenchment in these percentages next year.

This chart shows that the Banking & Financial sector continues to spend twice as high a percentage of revenue on IT as its nearest rival sectors and four times as high a percentage as some.  It will be interesting to see if this changes next year as the Banking & Finance sector deals with the self-inflicted financial constraints of the credit squeeze and the demands for increased regulation (which will presumably require more reporting and more IT).

The above charts were created from data provided in the InformationWeek 500 published on September 15, 2008.  (reprints of that article which includes the data but not the derived charts are available at www.magprints.com/informationweek500

Earlier this week, I had the following exchange with a guy who had attended one of my seminar’s:

A question – if you were a Senior Manager, what would you be looking for from a Software Quality function? We changed our function’s focus from Process compliance to focusing on identifying and mitigating application risk from a perspective of Application Stability, Changeability and Reliability. What would some typical (quantitative) measures be?

Answer: I faced exactly this challenge in my days at Sanchez/Fidelity in two respects: maintenance and project completion.  In both cases, I found that the most useful metrics were related to change.  I had my software quality team gather metrics from the configuration management system about the total number of lines of code in the application or project.  We used this as a sort of baseline (not a real baseline because it was always changing) to track on a monthly, weekly or daily basis (depending on our sensitivity) the percentage of LOC’s being added, delete or changed.  Again, our configuration management system either generated this automatically or, for  some older code, we ran scripts to do it.  By running these metrics for a while we were able to get a feel for “normal” levels and “expected” fluctuations.  This in turn enabled exception reporting which kicked-off investigations.

You may think that this would help with stability and changeability but not reliability.  In fact, we found that if we extended the granularity of the metrics down to module levels, we were able to see outlying modules in particular applications that had either very few changes or very many changes.  Either very few or very many changes could often be attributed to problem modules.  For example, a module may have very many changes relative to its peers because it is a central module in the architecture that has to be changed by every project.  This module is a high risk module!  Equally, a module with very few changes is either very stable or not used (surprisingly many of them) or a module that is so critical and hard to maintain that nobody dares to touch it for fear of it failing.    This is a good example of why the metrics can only kick-off investigations rather than give you absolute answers.

I’m not going to go into the details of this Standish report because I think that, if you are reading this blog, you will probably want to geta copy of the report at:

http://www1.standishgroup.com/newsroom/it_value.php

To whet your appetite, the ten drivers that Standish identify (along with 3 sub-drivers for each category) are:

1. Lowering the Infrastructure Cost
2. Increasing Application Features
3. Reducing the Cost of Downtime
4. Maintaining Suitable Risk
5. Commoditization
6. Higher Readiness
7. Project Management Leadership
8. SOA
9. Service Delivery
10. Vendor Consolidation

Do you agree with these? Have they missed something? 

My own perspective is that there is a lot that is right with the Standish top ten, particular when they are talking about cost drivers. 

While I agree that “Increasing Application Features” is a big driver of value, the Standish report misses the important point that Application changes should not be about features but about business benefits embodied in business cases (if you don’t think there is a difference between features and benefits talk to a marketing person).  While innovation can be realized through any of the top 10, it will be through enhancing the Applications that innovation impacts business processes, services and products. 

The report gives a good treatment of “Higher Readiness”.  I would have exteneded it to include responsiveness.  One of the big complaints that i hear about IT from business people is that IT operates on its own timetable (or a different clock frequency if you prefer) and is unable to respond quickly to business needs.  Of course, there are always good reasons for not being distracted by continual changes - its very inefficient and drives up costs.  However, there are no excuses for not being tightly aligned with the businesses current needs.  It was partly this separation of clock frequencies that led to the sprint-driven agile methodology which focuses on reprirotizing at the end of each sprint.

One final comment on the Standish report. They include a defintion of “Value” which I will not repeat here other than to mention their suggestion that one way to think of the value of IT is as the difference between the cost of the IT Service and the cost of providing the service manually.   This really struck me as strange.  My reactions, in quick succession, were: “That seems reasonable,”  “Surely, value is in the eye of the beholder?” and “Hang on, haven’t we moved way beyond comparing IT solutions to manual solutions?”  What do you think?

Paul B. Carroll and Chunka Mui wrote an interesting article in the September edition of the Harvard Business Review on lessons from the most inexcusable business failures of the past 25 years.  The magnificent 7 identified were:

1. Roll-ups of almost any kind - taking large numbers of smaller business ( or IT systems?) and rolling them up into a larger systems for economies of scale/efficiency/easier management/whatever.
2. Bets on the wrong technology - I dont need to put this into the IT context for you, do I?
3. Rushing to consolidate - In IT, this is the same as #1.
4. Pseudo-Adjacencies - in business, this is about selling the same product to new customers/markets or new products to your existing customers but the “pseudo-” part refers to the fact that the fast path to failure is not knowing enough about the new thing you are stepping into.  The IT examples are legion but I will limit myself to those porr souls like me who assumed that because their new laptop was sold with Vista on it, it would work.
5. Stubbornly Staying the Course - Oh yes - these are Ed Yourdan’s death march projects - check out his book or try http://www.yourdonreport.com/index.php/2007/11/27/death-march-presentation-download/
6. The Synergy Mirage - two IT companies partner together because it seems that their products and services are complementary.  A lot of heat and light is generate but no benefit to either of them or any potential customers because their cultures are too different.  For example, software license sales people do not necessarily make good consulting sales people and vice versa.
7. Faulty Financial Engineering - Here is the delivery date and here is the budget.  What do you need estimates for?

A copy of the Carroll/Mui article is available for purchase at this location.

IT spend as % of revenue is a frustrating metric because it places IT firmly in the sphere of costs that cannot be avoided and must be managed rather than an investment that should yield beneficial value.  Being above or below the average % revenue line is no great indicator of success other than the feeling that, as a CIO, you are doing are doing better or worse than your peers in the eyes of your boss (especially if your boss is the CFO).  Looking at the chart below (if you click on it you will get a version that’s easier to read), you can see that, for the mash of all industries, the percentage has stayed remarkably stable between 3% and 4% over the past eight years.  What does this tell us?  Two things:

1. I think its a number that business and IT need to be aware of (about 3.5% - more on the industry specific numbers soon)

2. Because this variable has been held steady, we can look at the other variables in a different light.  For example, have all the contributions to better performance over the past eight years (SOA, web services, ITIL, CMMI) been a waste of time or are the improvements perfectly cancelled out by the cost of the extra work we are able to do now?  What do you think?

The above chart was created from data provided in the InformationWeek 500 published on September 15, 2008.  (reprints of that article which includes the data but not the chart are available at www.magprints.com/informationweek500

Writing in the September 15, 2008 edition of Government Executive, Carolyn Duffy Marsan proposed seven best bets in IT for the new administration (of whatever party).  The seven were:

1. Cybersecurity
2. Performance Measurement
3. E-Government
4. Lines of Business
5. Federal Enterprise Architecture
6. IPv6
7. Green Data Centers

All good stuff!  But, naturally, the one that I am going to focus on is #2 Performance Management.  Not just because the David Consulting Group can help but because, frankly, it is easy to do and we do not see enough evidence of it yet in government IT projects.

To get some insight into why these seven were chosen, you can read the original article at http://www.govexec.com/story_page.cfm?filepath=/features/0908-15/0908-15s3.htm

The September 22, 2008 issue of Federal Computer Week contained a couple of articles about a fairly new concept in the US Government - the Chief Management Officer or CMO.  The idea is to create a position in agencies to elevate the level of attention paid to management issues, integrate various transformational efforts and institutionalize accountability.  Is it just me or is this the ultimate symptom of total management failure?

Fot the editorial see, http://www.fcw.com/print/22_31/comment/153791-1.html

For more information on the CMO concept, see Jonathan Breul’s article, http://www.fcw.com/print/22_31/comment/153814-1.html