Writing in the March 2009 print edition of the Harvard Business Review, Susan Cramm listed the following seven "truths:"
- Enhancements often don't deliver results commensurate with their costs.
- Projects are often too big and take too long, partly because unnecessary functionality is built into applications.
- Previously purchased applications and infrastructure technology are often underutilized.
- Project failure rates are too high.
- Tech teams do not have sufficient incentive to achieve high quality and quality is often not measured.
- Managers don't know enough about the systems that support their areas.
- 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".