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.
I’m going to be examining this topic and revealing best practices in a series of articles. In this first one, we will look at what goes wrong, and why, for internal applications: the things you build to help run your business. In the next article we will examine commercial applications – the products you build for your customers. There are differences.
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. These tend to grow through stages of fear/stress. For example:
Stage 1: “This old internal application breaks every so often. Bob knows the system and can keep fixing it, but each time it breaks, it slows us down and disrupts business operations.”
Stage 2: “Bob has retired, and we can’t find anyone else to fix it. If it breaks again, we are up the creek.”
Stage 3: “We can’t wait any longer. We have to replace this thing. Let’s bring in some developers and have them create the very same thing on new technology.”
Best practice in this case? Start taking definitive action at Stage 1 (or even before). It’s best to make the transition to something new while “Bob” is still there and can help with the transition. Yes, there will be emotional issues surrounding the transition, and Bob won’t be happy. That’s not a show-stopper; it is an opportunity to manage your way through it. Sit Bob down and explain what you are going to do. Involve Bob in the decision, and pay for him to be trained on the new technology. Will he come along? Maybe, maybe not – but you will do your company more good, and Bob more good, if you handle it this way. Keep your eyes open for reluctance, foot-dragging, or sabotage, and nip it firmly in the bud as soon as you suspect it.
The reason you take action early is to avoid the pressure that will build up in Stages 2 and 3. The longer you wait, the more difficult the situation will become. Bob may retire early or unexpectedly. Users won’t be able to do their work. You’ll have to resort to anyone you can find to fix it, and may pay exorbitant rates and face greater risks for having to do it fast.
One way to avoid this situation in the first place is to keep track of the applications that are used in your company, and their current state. Someone should own this effort and report to management once a quarter on problems with the application, the current state of development resources, cost of maintenance, technical trends in that space, and possible alternatives. Doing this on an ongoing basis will avoid the mad scramble when things go wrong.
Let’s say that you find yourself at Stage 2 or 3, and it’s time to replace the older application. It may seem that the tactic described in Stage 3 – creating the same application but in the new technology – is a logical approach. Instead, it always leads to grief. Why? Several reasons.
- There’s an expectation that the task should be easy because it’s “just a rewrite” of an existing application. That does not make it “easy.” Some common misconceptions:
- “We don’t need requirements analysis, we’ll just model the existing app.” A working app is a good start, but it’s not a requirements spec. Without understanding why and how it does what it does, you won’t be able to faithfully recreate its capabilities.
- “Bob wrote this app in three months ten years ago. Tools are better now so you can probably do it faster.” Version 1 may have taken three months to write, but the current version has ten years of tweaking that you need to uncover and replicate.
- The old app may not have been that great in the first place. We have never found “clean” code when we are helping a client replace an older application. There are bugs, there are poor coding practices, and there are decisions made that accommodate the technology but thwart solid user-friendly functionality. The fact that people got used to it doesn’t mean that it’s right.
- Where you were “then” is not where you are “now” – and that includes new competitive pressures that have set a higher standard for efficiency, integration between applications, and reporting.
As you work on replacing the old application, you will fall prey to the fear syndrome. 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. One way you can deal with this is to “try before committing” as much as possible, giving potential developers small tasks first, to make sure that they won’t make the same mistakes again. We get this a lot, and in these cases we slowly but surely build the new app one brick at a time, as we build trust.
This is fine, but it’s actually the slow way to ensure that your project will get done. Because it isn’t the code that matters as much as the strategy and thinking behind the code.
It’s better to start by having a series of discussions with your developers, whether they are an internal team or outside vendors on your short list, where you explain what you are trying to accomplish and what has made that difficult in the past.
As you are explaining this to the developers, what types of questions are they asking? Do they help you see issues that you hadn’t considered previously? Is the conversation draining or invigorating? Does it cause more stress, or relieve your stress? Do you have the sense that they will take responsibility for their part, or that they will “let you be stupid” and “wash their hands” when things get tough?
After you feel you have been heard, it’s best to then ask them to tell you what they thought you said. This is a critical step, one that should happen before they leave your offices or the conference call. 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.
Emotions – especially fear – can derail development. The best way to deal with fear is to get it out on the table early. What is it about this project that you fear the most? What can you and your development team do, together, to make sure that fear is unfounded? This type of discussion can help everyone focus more on the task at hand rather than imagining what could go wrong.
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.
For more information on application development, please download a guide for CEOs about creating great software from Applied Visions today.
