Monday, August 25, 2014

So, you want to build a new system... Why?

There’s an old saying that goes “To a carpenter with a hammer, every problem looks like a nail”.    Similarly, if you’re experiencing symptoms of illness and you decide to consult a doctor who is also a surgeon, it will come as no surprise that the doctor’s recommended remedy will likely require surgery.  It’s human nature that our approach to the problems we encounter lies within the context of the tools with which we are equipped, i.e. within the scope of our competency.  Addressing problems within that scope provides a level of comfort that we will be successful in solving the problem by exercising the skills that have been reliably successful in the past.  Indeed, we enjoy applying those skills.

Now, consider how this behavioral pattern is manifested by IT organizations. When a business organization consults its IT team for a perspective on a functional business problem, what solution is most likely to be recommended?  Because IT consists of professionals whose proficiency lies in delivering systems, their likely response is that a new system is required.  Similar to our consultation with the surgeon, the business executives will be reluctant to accept the recommendation of new system acquisition, as they’ve likely been down that road before.  They know that it will be costly in time and money, and will likely be problematic.   But, despite the fact that non-IT people have become increasingly computer savvy, their system fluency lies in the utilization of systems and not in system design.  The understanding of how and why systems behave the way they do is the domain of IT professionals.  So, the business leaders will eventually be persuaded by their IT organization to invest in a new system.  

Of course, IT will provide good reasons for why a new system is in order.  

  • The current system is antiquated.  The legitimacy of this claim is usually corroborated by the existence of a future date after which some vendor/supplier of a system component will no longer support that version of the component.  However, the truth and implications of the claim are rarely explored, as it would likely reveal less urgency and greater flexibility regarding whether or not to replace the existing system.
  • The current system can no longer be enhanced to deliver the evolving functional requirements of the business due to platform limitations.  I know of a large system that was delivered by a two-year project employing a team of ten developers, and which ten years after its initial production date, was still fully supporting its business line and required only one developer to maintain and enhance.   In contrast, there was another system that only one year after implementation of its initial project phase, required the scrap and re-design of it’s large and poorly designed database, which had made maintenance of the system untenable.  The longevity of a system regarding its ability to meet business functional requirements is most often due to the quality of the design rather than to any inherent limitations of the platform or tool capabilities. 
  • A new system is needed in order to meet speed-to-market demands of the business.   Most IT projects continue to be delivered late and over budget, despite the fact that technology innovations have reduced the time required to accomplish many system development tasks.  That is because IT organizations wrongly place responsibility for speed of delivery on platforms and tools  (i.e. hardware and software), rather than where it rightfully belongs, on process.  Well-designed, efficient, repeatable and reliable process is what will assure speed-to-market.  No system can substitute for that.
  • New technology is inherently better than old technology.  Time and again I’ve heard the statement that “we’ve got to get the users off the old and onto new technology”.  The greatest expense of bringing new business products to market is the cost of IT.  That cost continues to rise astronomically, eating into product profitability.  IT does a huge disservice to the businesses it supports when it insists that they invest in new technology that delivers no gains in business value.  We would do well to consider this.  Arguably, one of the oldest and most significant tools in business is the spreadsheet.  It existed before computers and with the advent of computers, became one of the first business tools to be automated.  Despite automation, the functionality of the spreadsheet remains fundamentally the same as ever and it continues to be a mainstay of business productivity.  


I suggest that IT leaders become valued members of their business teams, and as such contribute ways for businesses to get the most from their IT investments rather than needlessly propagating technology.  This philosophy should be promoted throughout the IT organization so that IT may become partners in profitability.