Overcoming the Business and Software Mismatch

August 22, 2009

My father worked as an electronics technician, and at an early age I became acquainted with electronic terminology. One term that can be applied to software development projects is known as an “impedance mismatch.”

Impedance is used to describe the resistance of a system, preventing the flow of electrical current. Electrical systems attempt to match sources and outputs to maximize power. When mismatch occurs, there is wasted energy.

Where is the mismatch in software development projects? More often than not, when business people and developers are involved, the “impedance mismatch” is really a difference in understanding the needs of a software development project and the expectations associated with those needs.

The real challenge with software projects is establishing the right level of dialog between the business and the software developers up front, and providing the ability to have a continual dialog over the course of the project. And this is where problems usually creep in.

What I’ve observed over the years is that business people get frustrated by what they perceive as constant questions from developers about things that they believe they have already answered. I can appreciate the limited time that business users have available; it’s just that it is also difficult from a development standpoint to operate any differently.

Consider this: Without software, computers have no intelligence whatsoever. In fact, they are very literal and they will only do exactly what someone tells them to do, how they were told to do it, and when. This means that every step in a business process, down to how the data is displayed, how it is stored, the operations and calculations needed to be performed must be given to the computer in the form of specific instructions.

It is difficult to anticipate all of the questions in advance. Since developers do not have the business background and experience, they aren't qualified to anticipate everything in advance. What usually happens on software projects is that the business problem starts out being expressed at a higher level than what will be sufficient later on as actual, detailed development is under way.

Starting at a high level is good, as it provides a project team with an overall idea of what the end solution will be. Developers, on the other hand, are dealing with an insanely stupid, very literal machine and will need the help of those on the business side in telling that machine what you want it to do.

This is why developers are “detail-oriented,” they have to be. It’s also why business people sometimes get frustrated with continual questions from development teams. I’ve seen projects go astray because business input was limited, and development teams had to make guesses based on the information they had available to them – resulting in expensive and time-consuming re-work later because the software application wasn’t what the business thought that they were getting.

A software application is a computerized representation of the business; the application of your business on the computer.

The bottom line: Business people understand their business very well and know what they want to get out of the software that is under development. Software developers understand computers and software development, but they do not understand the business as well as the business users. And despite appearances to the contrary, the continual dialog is NOT the same set of questions being asked repeatedly.

If you are on the development side, explain the software development process to the business so that they understand the demands that will be made of their time, in terms that they can understand. Too often, the focus is on the process and what the business must use to interact with development, but never why. Give them an understanding!

If you are a business user, keep in mind that the software is for you. And bear in mind that the developers writing the software are spending their time keeping up with technological changes, working on tight deadlines while dealing with an insanely literal device, all the while trying to ensure that they are building what you need and expect.