Long-time reader William Yohman points out a non-technical pitfall common to many end-user-developed IT applications:

“I developed dozens of applications, templates and procedures that were ‘the next best thing.’ I then trained the other users in my work center on their use (and how it would save them time) only to find out the momentum died when I left. These are intelligent, highly technical people who chose to go back to their previous frustration instead of continuing to use a product that was easy to use and saved them time. Why? Because no matter how good or how easy it was, it was easier to go back to the way they had done it a thousands times before. The reality is that ‘organizational memory’ only lasts until the alpha geek leaves the work center.”

Many end-user-developed applications fade away once their developer departs, no matter how good or useful they are. One reason is the difference between grassroots programming efforts and full-blown projects. The latter include training and business change management tasks that make sure the new system is institutionalized. They include establishment of a business sponsor who owns the change and is accountable for its success. And, when the new system comes in, the company “burns the boats” as it were — there is no way to go back to the old way of doing things.

Successful projects, that is, give end-users leadership, support, and an absence of alternatives.

With an end-user-developed application, all they get is support, and once the developer moves on, that’s gone too. There’s nobody to make additional modifications, answer questions, or help ensure that those using the application do so as intended instead of developing workarounds that pollute the data. Unless IT agrees to take on the job of support, use of the application grinds to a halt.

This isn’t necessarily a bad thing. Some of these applications are more conveniences than essential tools. They make life easier for awhile, but in the end the inconvenience of maintaining them outweighs their benefit.

Interestingly, the opposite can happen as well. As several readers have related, IT can develop a professionally engineered replacement for an “Access tangle” only to find that end-users refuse to abandon the application they’re familiar with, regardless of its limitations and inconveniences.

Sometimes, even well-accepted grassroots applications die; other times they stubbornly live on, even when IT provides superior replacements. What’s to do, other than shrug our shoulders and ponder the unpredictability of our fellow human beings?

Plenty.

First of all, whenever you’re responsible for implementing a new system, make sure to find out what home-grown applications are currently in use. Learn everything you can about them, and in particular, find out who their authors are.

Add those authors to your project team, either as full participants, or at least as subject-matter experts. Doing so will have two salutary effects. The first: By definition the authors are influential in the end-user community, so making them champions for the new system will increase acceptance. Second: By definition as well, the authors understand how to design a system end-users will embrace. Having them on the team (and paying attention to their ideas) will improve the design.

There’s one more benefit to including these folks on your project team. When the project is finished and the new system is in production, it’s just as important to turn off the home-grown applications it replaces as it is to decommission any large legacy applications the new system subsumes. The legacy systems, of course, are within the project team’s jurisdiction, so unplugging them is just another set of tasks on the project plan (“just” being a relative term, of course).

The home-grown ones are another story. If the project team shuts them down it might be considered an intrusion. If, on the other hand, the authors shut them down, it’s a powerful message to the end-users that the replacement system really is a better alternative.

Who better to burn the boats after all, than the shipwright who made them?

I have a confession to make. I like Microsoft Access. In fact, I like it a lot.

The Microsoft Jet database engine is a disaster, but Access itself lets me snap together simple applications in not much more time than it takes me to think through the design. Sure it lacks some niceties, like decent support for recursive data structures. The lack of a macro recorder is simply baffling. Some features blow up inexplicably. Still, all in all Access generally stays out of the way, letting me do what I want to do without a whole lot of trouble.

Microsoft Access lets end-users design simple systems simply. So why do so many IT professionals complain when end-users do just that? Because many of these end-user-developed systems succeed, that’s why. By becoming too successful they become production applications … fragile production applications that require duplicate data entry, disagree with the system of record, disagree with other independently-developed Access applications that have succeeded, and sometimes just plain blow up. Did I mention that the Jet database engine is a horror?

These problems don’t just cause headaches for IT. They cause headaches for the business as well: A workgroup that used to work inefficiently using pencil-and-paper techniques now can’t work at all until its “production prototype” is up and running again; and a department that gets different answers to the same question depending on which database it queries never knows the right answer. To be fair, these same workgroups gave different answers to the same question when they used pencil and paper, too. It just took them longer to disagree.

Many IT organizations, seeing only the cost of the mess and not the business benefit of the automation these applications provide, simply ban Access. I formed the mythical Value Prevention Society (VPS) earlier this year as a place for them to congregate.

Enlightened IT organizations take a different approach to the problem. I’ve outlined some elements of their operation in earlier columns: Train power users in data-design; expose production data to MS Access and Excel (read only, please); and provide advisory services to end-users engaged in developing applications that use these tools.

By themselves, though, these steps mere ensure each individual application behaves as well as possible. It doesn’t solve the problem of having hundreds, or even thousands of them floating around colliding with each other.

A tangle of Access applications is nothing for IT to sneer at, of course. In many companies, IT has created its own tangles that are still in production as well. All that’s happened is that end-user-developed Access applications reveal the core problem of enterprise architecture at a different stratum of the organization. IT architects know that optimization of the parts doesn’t result in optimization of the whole — often the result is the opposite. A portfolio of individually sound, best-of-breed applications can still yield an icky applications portfolio. Which points to the solution for the Access tangle.

When enterprise architects analyze an applications tangle, they work with business areas to settle on a portfolio of go-forward applications, and create a coherent integration strategy. Then they develop a decommissioning plan for the other applications.

Do something similar for the Access tangle. Get close enough to the business to know which Access applications have reached “tangle” status. But instead of choosing some as go-forward applications, use the tangle to provide the specifications for a new, production-grade application to replace the whole shebang. My guess: IT should be able to replace an Access tangle with half the effort it would have taken to be involved at the beginning.

Last week’s column pointed out that there’s no such thing as an IT project. It’s always about changing the business. That’s still true.

What’s attractive about the Access Tangle Replacement Methodology (ATRM) is that the business change takes place before IT ever gets involved.