Take fear and stress out of internal app development

by Frank Zinghini CEO

Internal application development is a psychological experience. There is always a mixture of fear, excitement, and potential for embarrassment involved. Personal and company reputations are at stake.

A successful development process – one that meets the objectives – doesn’t just happen. It is successful because it is managed successfully, and not just the technical part. For every technical decision, there are many psychological and business decisions that play a part in the overall successful outcome of the project.

Where things go wrong

A lot of projects are doomed from the start because the entire psychological underpinnings are flawed. The decision to develop is usually driven by fear or stress: the need to support a new business process now; adapting to changes in the business; replacing an existing application that is growing obsolete; and more.

Best practice? Start taking definitive action as soon as possible, hopefully while the “owner” of the existing application is still around. Involve the owner in the changes, but keep your eyes open for reluctance, foot-dragging, or sabotage, and nip it firmly in the bud as soon as you suspect it.

One temptation you’ll want to avoid is replacing the older application by creating the “same” application using newer technology. This always leads to grief. Shortcuts are taken, without a proper requirements spec. The older application has been tweaked over the years and is no longer a “clean” application. The older application, while everyone is used to it, may not be that great to begin with. There may be bugs, poor coding practices, and decisions made for the wrong reasons. And, you’re now facing new higher standards for efficiency, integration, and reporting.

Everyone in business has now had at least one negative application development experience. This has heightened the emotional aspect of application development, causing managers to become super cautious. Head these tendencies off at the pass by having a series of discussions with your developers. Explain what you are trying to accomplish and what has made that difficult in the past. As you are explaining this to the developers, pay attention to their questions, which will reveal their agendas and ability to embrace the new effort.

After you feel you have been heard, it’s best to then ask them to tell you what they thought you said. It’s better to hear it now, and realize how well (or poorly) they understood, than to experience the disappointment that comes with the delivery of an irrelevant and off-target application.

As with so many highly-charged undertakings, leadership is critical. Listen to your team and reassure them that you understand their concerns. Ground your expectations in their reality, and control expectations up the chain of command. Help them connect with users, even if the users don’t understand why you’re bothering to rebuild this “perfectly good application.” Help educate those users. Lead from the front, and your development team will follow you anywhere.