Mike-O-Matic

The helpdesk manager leaned over the demo system. He didn’t like what he was seeing.

“This one is a little better, but it doesn’t match how we do our tickets. For us everything starts with the phone call. This interface is way too complicated.”

The lead programmer smiled to himself. He knew what was coming.

“Matt, how long would it take for us to do this ourselves? I really want to get this right.”

“No time at all. In fact, I already have some ideas…”

Thus begins another project doomed to replicate functionality available for a tenth the price, while taking IT resources that can be better used elsewhere.

Why does this happen? Lots of reasons.

In many cases, an organization is unwilling to modify their requirements to match more established standards. They are committed to the process as it currently stands, or are not empowered to change anything. Sometimes the people choosing the technology aren’t familiar with what to expect in IT systems. Often the IT department itself is the culprit. When a new requirement pops up, they see it as an opportunity to create a new project. Everyone loves new code. The department gets more budget money, the developers get to test out some new technologies, the internal customer gets a system tailored to their exacting needs. Everyone is happy, right?

There are many costs to in-house software development that make it unsuitable for many application domains. Developers are often some of the most highly-paid non-management employees in the company. Utilizing them on one project incurs an opportunity cost since it makes them unavailable for more value-added development duties. There is a lot of overhead to getting an IT project going, such as meetings between developers and the client groups, new software licenses for infrastructure software like databases and application servers, and training that might be required for the new technologies used. And that is all before the app even goes into testing, deployment, and maintanence. When problems come up, the IT staff needs to find all the answers in house. No tech support line to call, nobody else to turn to when diagnosing intermittant bugs, no customer base to determine best practices with.

So what can we do to avoid this situation? Here are some tips.

• Do Research Before Building Requirements: In many domain areas, there are already applications that can do the job admirably. Inventory management, for example. By looking to see what is out there before building requirements documents, an organization can approach the process with an open mind and not be held to a predefined checklist built in a vacuum.
• Embrace Change: Empower the groups needing the applications to change their procedures to accomodate off-the-shelf systems.
• Consider Open-Source: When possible, look for open-source applications to bring in-house. These products have oftentimes gone through testing and the code was written with public consumption in mind. If they provide 80% of the needed functionality, they can be modified as needed to get all the way there.
• Use Interdiciplinary Committees to Evaluate Demos: People with different skill sets will bring different things to the product selection process. For instance, if a particular package uses MySQL instead of the typical Oracle database, a developer on the team can explain the tradeoffs and what will be needed to integrate the application into the environment. If that package has lots of great features that can’t be matched on an Oracle-based alternative, it may still be a workable solution.
• Focus on Flexibility: Looking at applications that use standard infrastructure such as SQL databases can be great for organizations with development staff. If the inventory management application has great operational functions but lousy built-in reporting functions, it can still be a viable choice if the developers can get at the data directly. They can build just the missing functionality or look for and integrate another package just for that purpose.
• Remove The Incentive to Empire-Build: Many organizations (particularly large ones) are organized in an inefficient manner. Different departments need similar applications and go through the procurement process on their own, resulting in multiple applications that are functionally equivalent but need to now be maintained separately. By communicating more clearly and penalizing departments for using non-standard applications many of these problems can be overcome. For example if several departments have built reporting tools over the years, but the organization has now adopted Crystal Reports enterprise-wide, charge a penalty against their budgets (after a grace period) as long as they continue to use the one-off systems.
• Ban Microsoft Access Company-Wide: A little tongue-in-cheek, sure, but having tools like Access around causes many amateur developers to start building tools to solve their day-to-day problems. This “build-by-default” mentality is dangerous because it introduces new technology that needs to be maintained and supported, and the applications that result often don’t scale, meet the needs of other people in the organization, or produce good data.

It should also be mentioned that there are lots of cases where in-house applications are the way to go. If you have an integrated application suite for the whole organization, for instance, building new modules instead of buying and integrating third-party apps can make a lot of sense. It is also worth building things which add value to the organization relative to other organizations. If you have excellent and efficient processes, get them in code and sieze the competitive advantage!

Choosing to buy or build is a very subjective activity and isn’t easily captured with generic rules. A lot depends on the culture of the organization, talent of the development team, and the particular problem that needs to be solved.

With a little thought and a few well-thought-out questions, an agreeable answer can certainly be found.

Til next time.

Subscribe to this Blog!