The work we have been doing with the Innovation Value Institute (IVI) and IT-CMF has revealed some interesting data on the differences in business and IT perceptions the way the business sees IT.  Generally, IT leaders see themselves as viewed more as peers by their business colleagues than is actually the case.  In the diagram below, I have taken advantage of the fact that the CIO magazine survey questions used very similar labels to the IT-CMF “Managing IT like a Business” maturity levels to map the survey responses to IT-CMF maturity levels.

The mapping , while admittedly imprecise, appears to show that over half of respondents believe that the business views them very positively – as an IT partner, business peer or business game changer.  The IT-CMF benchmark data which covers hundreds of companies assessed so far suggests that this view – essentially saying that over half of IT Departments have an IT-CMF “Managing IT like a Business” maturity above level 3 – is wildly optimistic.

CIO magazine "State of the CIO 2012" - The Way Others See You

An interesting article by Michael Koval in the Nov/Dec Edition of the IEEE IT Pro magazine entitled, “The Technologist’s Tool The Technologist’s Tool Set: A CIO’s Perspective” got me thinking.  In a thoughtful article, Koval proposes and justifies the following list of capabilities that a top CIO needs to have today and into the future:

• Know the Business
• Innovate
• Manage Projects
• Perform Business Analytics
• Understand Contracts
• Market the Product
• Ensure Security
• Motivate and Support the Team

I agree with these selections and started to think about how much of this maps to the IT-CMF framework with it’s mantra of “Running IT like a Business.”  It’s a pretty good fit with one glaring exception: Today’s and tomorrow’s CIO needs to be able to understand and use the financial information that the CFO can provide him with.  In fact, I often find that when we engage with CIO’s and CFO’s on IT-CMF or IT Governance projects, the CFO and his/her team do not know what information can help the CIO improve IT’s services.  Consequently,  if the CIO is not financially savvy enough, the business and IT blunder on it darkness around a core piece of information that drives the value delivered by IT – the financial numbers.  Of course, this is one of the strength’s of IT-CMF.

What do you think of this list?  Anything else missing?

There is a good, short introduction to Model-Based Testing (MBT) by Ina Schieferdecker in the January/February 2012 edition of IEEE Software magazine.  Most readers of this blog will probably be familiar with Model-Driven Development but most (according to a recent survey quoted by the author) are probably not using MBT.  The article is particularly useful in that, though short, it covers:

• a little history: including the important step to separate “models” for code from “models for test,”
• a short description of MBT’s three mains tasks: Design a functional test model, determine the test generation criteria, generate the tests;
• a list of current tools.

Schieferdecker asserts that MBT “… is no commercial off-the-shelf solution.  For successful implementation. MBT tools must be tailored to fit a company’s processes and infrastructure.”  Nonetheless, MBT looks like it it mature enough for further investigation right now.

Way back in February 2011, CFO research services in collaboration with KPMG published a report entitled, “A New Role for New Times” which sought to identify “Opportunities and Obstacles for the Expanding Finance Function.”  For some reason, I found this report again as I was sorting through my holiday reading and I took it home to re-read.  Although, you might accuse me of being the guy with a hammer to whom everything looks like a nail, my recent IT-CMF certification caused me to read this report in a whole new light.

The report concludes that, “In the years ahead, finance executives will seek to further improve heir abilities to support the highest-value activities that lead ultimately to better business performance.”  OK – no specific mention of IT in this but surely a warning shot across the bows of IT departments and CIO’s who are cannot be considered “highest-value activities.”

Finance executives surveyed for the report claim that, “… technology is the most formidable barrier … IT systems are out-of-date, inflexible, or unable to support new requirements.”

KPMG, as sponsors of the report, highlighted the state of the relationship between finance and IT as a particular concern.  This is where CIO’s should be proactive, get a simple introductory presentation on IT-CMF (with some basic understanding) and take it to their CFO’s.  The CFO’s cannot fail to be at least interested in a framework whose four macro capabilities are:

• Managing IT like a business
• Managing the IT budget
• Managing the IT capability
• Managing  IT for business value

KPMG’s comments continue that, in the survey, only 39% of CFO’s cite their relationship with the IT function as a strength.  Wake up CIO’s – these are the guys who control the money!

In the IT-CMF Framework for improving the business value of IT, organizational majority increases through five levels across four macro capabilities (or macro processes as they were once known):

IT-CMF Macro Process Maturity Levels (source: IVI)

I was reminded of the value of this framework in moving forward our ability to deliver value across the business-IT interface when reading an article in the November 15th print edition of CIO magazine, “Building Bridges” by Diane Frank.  The print edition of the article had the sub-title, “Get over your service mentality and step up to a true business partnership.”  Looking at the IT-CMF framework, we can see that this glib sub-title can be put into a much richer context: First, a “service mentality” is a creditable level 3 way for running IT like a business; Second, being a “true business partnership,” is certainly a worthwhile step up because it is a level 4 way of managing the IT capability but the two things are not mutually exclusive.

Of course, it is silly of me to nit pick over a few words in such a good article but I started with this to highlight the problem that we, in IT, do not have a standardized vocabulary for discussing our opportunities and challenges with the business.  IT-CMF has many ways to provide value but this is surely a central one.  Ms Frank relates stories from Toyota, First Data, Red Robin, Motorola and others where there have been (apparently rare) successes in changing the business perception of IT.  There is even to offer of an online questionnaire to help rank your IT-Business relationship at one of three levels:  Service Provider, IT Partner or Business Peer.  Again, the similarity of thought is evident between this and IT-CMF but, I think, referencing something like IT-CMF and using the same terms would be more powerful.

 

I have been a long-time advocate of formal and informal inspection of artifacts throughout the software development process.  I become a convert while running the software development at Sanchez Computer Associates, a Banking software product provider, ten years ago (see page 21 of a CMMI Benefits Report by Dennis Goldenson and Diane Gibson).  My boss at the time, Frank Sanchez, quickly became a champion too!

So, I was delighted to see a fresh take on the topic in an Dr Dobbs Report article by Capers Jones and Olivier Bonsignour in the November 28, 2011 print edition of informationweek.  They argue that inspections are the defect-prevention technique of choice.

While I agree whole heartedly, experience has taught me that Fromal Inspections can become a bureaucratic waste of time. I have found that ADDING two things to formal inspections can add significant value AND enhance compatibility with agile. First, put together a small “software artifacts standards committee” with your top developers, business analysts and testers and get them to set the criteria for inspections or, in other words, “What are the inspectors looking for?” A checklist works well. This group should meet regularly to consider updates based on newly identified helpful or hurtful patterns. Second, two tiers of formal inspection should be implemented – the Fagan Inspection approach preferred by Jones and a peer-to-peer approach that completes the inspection checklist without going to the full committee. The standards committee decides on a policy for which artifacts go to which level of inspection based on the ROI.

The November 28, 2011 print edition of Informationweek contained an excellent article by Charles Babcock on the importance of an IT Operations voice in agile software development.  I encountered this issue last year at two levels while working on an outsourced agile development project with a client.  The first level was that identified by Babcock, the challenge of continuous integration.  In a traditionally waterfall environment, the IT operations team have their time on stage mostly at the end of the project when code is moved into various integration test environments (as close to production-like as possible)  from the developers unit test environment.  Over the years, mature companies have become quite good at this hand-off.  Indeed, my client had an exemplar “pipeline” system where requirements and design was done in the first 3 months, development in the next 3 and integration testing in the last 3.  This kept new releases rolling through and gave the IT operations group a minimum of 6 months notice of the need for new environments.

Under agile this does not happen, the new integration test environment (as close to production-like as possible) is needed in the first few weeks of the start of the project.  A nightmare.  Hence, if delays are to be minimized the IT operations people need to be in the project planning as early as possible.  With my client, we had the foresight to do this but then ran into the practical problems of not being able to stand up environments quickly enough because the process was designed for 6 months notice not 6 days!

The second level of IT Operations involvement that I ran into was the ability of the IT operations team to come up with ways of getting around the constraints imposed by the environments.  They were able to take their experience of finding quick production workarounds in times of crises and apply it to the more prosaic but just as important problems of agile teams needing to integration test against unfinished parts of the project from other teams.  Often, the solution was to take copies of production code into test environments and expose limited API’s for the agile development teams to test against.  Necessarily, these were subsets of the API’s that would eventually be delivered, extended,  by the parallel tracks of the current projects but at least some level of integration testing could be done very early – do the hard parts first!

Murali Chemuturi has written an interesting and provocative article promoting this solution to US software skills shortages in the December 2011 edition of Industrial Engineer magazine.  The article is entitled, “Distributing work for a revolution,” and, for once, I suggest that you jump to that article now before reading the rest of my comments.

Murali sets the scene well by looking at how the division of labor has impacted other fields of human endeavour.  This has only started to impact software development fairly recently.  He is quite right in his assertion that, in software development, if division of work has started then the other shoe certainly has not dropped yet - some of the new roles do not require the same level of intelligence (there – I used the word!) as others.  He is also right in his implication that US and other western companies have unconsciously (or consciously perhaps in some cases) accepted the potential for deskilling through their outsourcing activities.  Unfortunately, some of the pain of challenged outsourcing engagements is that the outsourcers have given their vendors too much of a free hand in testing the limits of deskilling by allowing them to resource ALL of the new roles with a “minimum sufficient skills” perspective.

I am a proponent of agile development but, food for thought, is the return to the artisan approach in software development (embodied in the agile manifesto) simply an acknowledgement that we have failed in division of work where other enterprises have succeeded?

I am a proponent for offshore development but I want to pick up and wave the flag that Murali has created – it’s time for us to review the skills required for the roles in software development and see what we can do to reduce our costs AND open up opportunities for work onshore.

While I’m not happy about the implications of the title, “5 minutes to process improvement success“, this new project from Bill Fox gathers together some interesting short conversations with various process improvement experts including DCG’s own Tom Cagley.

By identifying and keeping separate the contributions from the different experts, Fox allows you to pick your experts to support or challenge your predispositions about the way to tackle process improvement challenges.  Of course, I would encourage you to choose some views from both sides of the fence because these experts are basing their opinions on hard won experience.  The style of the contributions is question and answer so this is a presentation format that is easy and quick to consume.

In providing this information, Fox is touching on the issue of the difficulty in getting considered, independent answers to some of the questions that come up regularly in the IT and software development business.  DCG has recognized a similar need and has provided an alternative response – the DCG Trusted Advisor service.  This service combines the research skills of our consultants with the curiosity and needs of our subscribers to generate monthly, subscriber-driven reports that research data-driven answers to subscriber questions.  Questions research in the 4 months since the service started include:

• Is there evidence that agile is better than other SDLC’s?
• Is automated function point counting read for prime time?
• How can we run agile and waterfall in parallel?

Reports are kept intentionally short for easy reading.  Subscribers are encouraged to add questions to the question backlog and vote on the next report to be researched each month.  Free trial subscriptions are available by emailing me or info@davidconsultinggroup.com.

Automated function point counting can work for applications and releases but manual counting is better and necessary for projects.  This post covers some of the considerations that DCG has gone through for one of our clients.

Companies may have several  goals in measuring their software using function points.  For our client, it has been assumed to date that the singularly most important goal is to use the measurements:
A.  To improve AT&T  software development practices.

However, in seeking to recommend the best sizing strategy going foward, we have aske them what weighting they would put on this goal (out of 100%) alongside the following equally valid goals:
B. To baseline AT&T productivity for a future outsourcing program;
C. To set productivity objectives for managers as part of their compensation plan;
D. To compare the productivity of different development groups;
E. To establish portfolio size for maintenance effort planning;
F. To improve project estimating;
G. Another goal

Our clients current plan for sizing project-level activities is to use an automated sizing tool and to collect sizing data at the application release level by comparing the application size in the proprietary automated function points before and after the release.  Clearly, this approach is useful for achieving goal E and, to a limited extent, goals B, C and possibly D.  However, it is not clear that goals B. C and D can be fully achieved with this approach or that goal A can be achieved at all.

DCG has suggested that sizing at the project level (rather than the release level) is the more effective and accurate way to obtain the data needed to attain goal A because measuring performance at the project level provides a greater opportunity to analyze process strengths and weaknesses within the SDLC.

At face value, it might seem that project level (manual) counting is more costly than automated release counting because:
• There are more projects than releases – this is true but DCG have found over the years that with appropriate resource planning and management the overhead typically associated with each count can be significantly reduced for regular counts on te same applications.  Once that component is minimized, the effort (and hence cost) are proportional to the number of function points in the count so breaking up the counts from releases into projects makes minimal different to the effort.
• Data collection by client staff to support manual counts for application has proved to be expensive in client resource time and interruptions to workflow – This is not well founded since our experience to date on client project counts has been very positive with minimal SME involvement.
• Automated counting of releases is quicker than manual counting of releases after the initial calibration has been done – Of course, automated counting will still be quicker and cheaper for releases but it is not yet a reliable option for projects.

DCG – experience suggests that data at the project level is of greater value than size data at the release level  because:
• Measuring productivity at the project level gives a more accurate and realistic perspective of the performance of the SDLC.  Specifically, every project is unique in that there are any number of factors that can influence performance. When measuring at the release level, individual project performance is not easily distinguishable. Consequently, it is more difficult to determine what has contributed to high or low performance levels and to draw lessons for improvement from good or bad practices (goal A);
• Measuring performance at the project level is in line with other client initiatives and therefore provides a basis of comparison (goals B,C,D)
• Historical data at the project level provides the basis for improved project estimating (goal F).