CIOs: How to Innovate

MikeA lot of articles I’ve read lately have focused on the need for CIOs to innovate – it’s clearly an industry hot topic right now and hopefully a warning for all CIOs who want to keep their jobs. The time to innovate is now, more than ever.

Chris Curran, in the recent CIO magazine article, “To Innovate, CIOs Must Unlearn,” contends that innovation requires a change in the way CIOs are used to doing things. As he puts it, CIOs need to “unlearn” a lot of what they consider to be standard – innovation requires a new way of thinking.

Some of his suggestions include:

  • Anticipating what customers want before they want it – then deliver it before anyone else
  • Emphasizing what you don’t know instead of what you do
  • Embracing the notion that you don’t need to have all the answers
  • Thinking of yourself as a strategic counselor, not a technology distributor
  • Utilizing data from outside the organization, not just data that you create
  • Bringing software engineering work back in-house; this will allow you to test ideas and see results faster than before
  • Forging relationships outside of the IT department, particularly with business managers


As I’ve mentioned before, the CIOs who will most succeed with this shift in their job description, are those who see it as an exciting opportunity, rather than a burden.  Focus on what changes you can make and utilize benchmarks to see if those changes are actually having a positive impact on the department.

Do you have any tips for CIOs to drive innovation?


Mike Harris
DCG President

Written by Michael D. Harris at 08:00
Categories :

David Consulting Group Partners with QuantiMetrics

If you haven’t heard our news, we’ve partnered with QuantiMetrics.

We’re really excited about this partnership because of the value it brings for you, our clients.

QuantiMetrics owns the largest validated database of regularly updated software project information, which can be used to help you better understand how you’re doing compared to similar organizations and across internal projects and applications.

This benchmarking data can be key in helping you gain a competitive advantage just by understanding where you stand in terms of your competition, and then using that data to make valuable improvements.

We utilize this data in a variety of our Solutions and Services, including Software Metrics (Industry Benchmarks and ADM Performance Baseline), Outsourcing Measurement, Project Post-mortem, ADM Benchmarking, and IT Value.

In the video below, you can learn more about why I’m excited for this partnership.

 

Tell us, do you currently utilize any benchmarking data?


Mike Harris
DCG President

Written by Michael D. Harris at 08:00
Categories :

Benchmarks and What They Tell Us

As ever, when I start to think about benchmarks, I like to remind myself of the definition. The Oxford English Dictionary states that a benchmark is:

  1. A standard or point of reference against which things may be compared or assessed.
  2. A surveyor's mark cut in a wall, pillar, or building and used as a reference point in measuring altitudes.

Synonyms include “norm, touchstone, criterion, specification, model, exemplar.”

Now, this leads us to ask what benchmarks show us? They give us a picture, an image of the current performance of an organization. The temptation is to see the result as a simple statement of fact uncluttered by its surroundings.

Fishing 
 I came across this notice on a trip in the States and, on the face of it, it’s a perfectly reasonable request, but when you step back and take in the whole structure you start to think again.

Fishing2
 Here’s the bridge – and that drop is 1,000 feet! The notice is clearly a joke, but taken at face value it’s a strong prohibition. That’s why our benchmarking service is designed to help clients see the whole picture.

Our aim is to help clients to understand not only where they are, but how they are progressing toward their goals. Single snapshots give us an indication of where we are in relation to the industry – today. An effective picture takes time and a number of data-points to fill in the missing corners.

Benchmarks should influence discussions on productivity and cost per output; they should not simply drive the conversation. The big picture is multi-facetted; productivity is affected by so many things: size, timescale, quality, process maturity, resource skills and availability, to name but a few, and any benchmark service should take that into account when engaging with clients.  

We have recently set up an agreement with Quantimetrics, an established independent benchmarking company, because we believe that the depth and breadth of data held by Quantimetrics enables us to bring even more to the benchmarking party. With our partners on board we bring a global, non-U.S. database to add to our U.S. data, plus many years of experience in data analysis.

Going back to our fishing notice, once we have the full picture, we can see that trying to fish from there is pointless. In short, the 1,000 foot view doesn’t work – let’s get down to the river and try again.

By making use of extra data and by monitoring progress over time we enable clients to progress on a journey towards better value for software development. We enable them to catch the big fish and throw back the small fry. We look forward to helping you on this journey.

What other benefits do you think bechmarking holds?


Alan Cameron
Director, DCG-SMS

Written by Alan Cameron at 08:12
Categories :

ROI and Agile

There is a good short article by Virginia Franke Kleist in the September/October 2012 edition of IEE IT Pro magazine called "The Elusive Technology ROI".  It covers the ground on traditional approaches to ROI and the pitfalls. As I was reading the article, I started thinking about the additional challenges of building ROI models for Agile projects. In traditional waterfall projects, the basic assumption is that the requirements can be defined up front to a large extent.  Included in this assumption is the concept of a business problem or opportunity that the software will more or less wholly address.  To build the ROI, we estimate cash flows associated with the business problem or opportunity solution. With Agile, we dispense with the traditional assumption that we can solve the business problem or opportunity wholly by defining requirements up front.  Instead, we take a piecemeal approach to tackling the next most important aspects of the business problem or opportunity that we can bite off in realatively small chunks.  In doing so, we expect our customers understanding of the problem or opportunity to change and their ideas for the solution to change.  We expect to reprioritize our effort.  How then can we make reasonable estimates of cash flows for a reasonable ROI calculation up front?  If we cant get a reasonable ROI calculation up front, how can we justify starting the project? In thinking about this, I have two observations to get you started:

  • On the benefits side of the ROI, the "what" of the size of the business problem or opportunity should not be influenced by the "how" of the methodology used to build the solution other than in that an Agile approach might be expected to produce more unforeseen, "emergent" benefits that traditional waterfall.
  • On the costs side of the ROI, the "how" can be very influential and the less predictable (at face value, assuming good requirements for the waterfall) nature of Agile could imply that costs might be more than expected for Agile.  However, it shoudld also be true that the risk of building useless "white elephants" in Agile is much smaller because projects that will struggle to solve the business problem or opportunity can be identified and re

  Mike Harris DCG President

Written by Michael D. Harris at 17:22

Software Gravity Wells

We had one of our quarterly management team meetings at DCG last week and we got into an interesting discussion about gravity wells.  It got me thinking about gravity wells in software – if you have been involved in the software development of a reasonably large system you will know what I mean.  These are the parts of the software that are the most complex and intractable; they tend to be the parts that most transactions go through.  Looking at it another way, you know you have these software gravity wells if there are parts of your software that only one or two people are allowed to touch!

A couple of years ago I worked on a project for a major financial institution where the gravity well in one of their core applications was still coded in assembler!

So, how can you find, prioritize and deal with gravity wells in your software?

These software gravity wells develop for a reason.  They are sometimes necessary and always complex.  This gives a clue about how to find and prioritize them.  The best way is to run a McCabe Cyclometric Complexity check on your software.  As the link suggests, a value of about 9-10 is usually thought to be a reasonable upper limit.   At one company I worked at, our flagship product had two or three modules with McCabe numbers over 100!

Once you have found your software gravity wells, how do you fix them? Start with “Do no harm!” Refactoring is probably not going to solve this one.  Instead, a serious redesign is called for.  The problem is often that nobody really knows why all the complexity is there and nobody recalls why different tweaks were made at different times.  So it’s a good idea to build a test jig for your software gravity well that creates input and output interfaces around it to allow it to be removed as a module and replaced with a new module (in a test environment, of course).  Once the new module to be tested is in place and connected, then the regression tests can be run to find out what parts of the application have stopped working.  You will notice that I did not put an “if” in that sentence.  This really is brain surgery!

What gravity wells have you discovered?


Mike Harris
DCG President

Written by Michael D. Harris at 08:56

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!