The Business Challenge

by David N. Rasmussen, Senior Consultant, Cutter Consortium

The IT industry today bears little resemblance to the industry of more than four decades ago when I started out in software development. In those early days, the concept of computers actually "communicating" with each other didn't exist. My definition of a "personal computer" was when I was the only user operating a mainframe at night, debugging my program (which was written on punched cards -- oh yes, "don't drop the card deck!").

Phenomenal change has transpired over those years, without a doubt. However, there is one attribute of the IT industry that remains just as important today as it was in the 1960s: communication in all of its forms, especially communication among people. In my experience, the vast majority of IT initiatives that failed to meet their program objectives were directly related to problems with communication in the workforce, such as incomplete documentation, poor business direction, lack of a common glossary of terms, starting development before the design is approved, confusion about the development process, inadequate testing procedures -- you know how the list continues! Well, these problems are not new today, and they weren't new in the 1960s either. It requires people working effectively together to achieve great accomplishments, and it takes people communicating poorly to deliver a less than satisfactory solution. This was true then, and it's still true now.

One of the critical success (or not) factors is the availability (or absence) of defined business rules for performing work, rules that are based on the experiential knowledge of the workforce that define which work is to be performed, by whom, when, and how the work completed is to be tested and validated. Call them by whatever name you want, but the rules are fundamental in training the members of the workforce to become experts in their jobs. When these rules are changed but not documented or communicated, the ability of the program team to work efficiently is compromised. Much of this occurs by a well-intentioned but naive management mindset that emphasizes speed of work at the exclusion of quality of work. And, guess what? Sometimes we have to develop the system twice -- once to learn how to do it right the second time!

Does this scenario ever happen in your IT department today? Of course it does, with the corresponding increases in development time and cost along with diminishing value of the eventual solution.

While technology may have changed over the course of the past 40 years, today's business challenge is actually fairly similar to ones of years past.

-- David N. Rasmussen, Senior Consultant, Cutter Consortium