Software Development

10+ tips for getting your application into production


Developers usually consider an application successful if it meets budget, delivery, and business requirements. But getting from development to final acceptance can be a sticky path to navigate.

Implementation is undoubtedly crunch time, from moving the application to production to making sure the users are trained well and understand the application fully. And all too often, crunch time comes with plenty of stress and sleep deprivation. Here are a baker's dozen tips for calmly managing the deployment of your customized application.

Note: This information is based on the article "Thirteen survival tips for transitioning your application to production," by Kathrine Wright. It's also available as a PDF download.

#1: Check the hardware

Be sure that appropriate equipment is available and configured properly. Make sure that you are familiar with any other applications that use the same resources, including servers and connectivity, and understand how these applications tax the shared hardware.

#2: Make sure the servers are identical -- or as identical as possible

Try to set up the development, quality assurance (QA), and production environments as similarly as is feasible. Make note of any differences, even if they seem minor. It's no fun finding yourself hung up in the implementation process over a miniscule, yet irritating, configuration issue.

#3: Make nice with the system administration staff

Give them the right documentation and training. They're critical to deployment and are often highly knowledgeable about the user community. They may hear important feedback you wouldn't otherwise be aware of.

#4: Develop a foolproof rollback plan

Whether your application is a replacement of an existing system or an upgrade, carefully construct your rollback plan to make sure that users aren't left without their business-critical application. Nothing is more disconcerting to management than a group of users with nothing to work on. That lost revenue will be noted as a strike against your application no matter how well it works once it's installed correctly.

#5: Document well

I stress this point often and with good reason. Thorough systems documentation helps the application maintenance staff support the application once it's live. And well-designed, intuitive help and user guides aid in the user's comprehension of the application, making user acceptance more likely.

#6: Check the data

Make sure that the data has been scrubbed properly and meets the standards that were established for your project. Also make sure that you have good processes in place to do the data dump from one environment to the next. If it is necessary to perform this activity in the evening or over the weekend, be aware of the scheduling issues this may raise.

#7: QA the deployment process

In addition to having the functionality of the application QA'ed, be sure that the deployment process itself is properly scrutinized. The first time your application is deployed will likely be into the QA environment. There, a series of steps must be followed, including configuring and initializing the database and configuring and initializing the installation of the application. Knowing the deployment process is sound can be the key to a successful move to production.

#8: Build good metadata

A good metadata repository is crucial for users who build reports from the data used in your application. Documentation on the database, which describes what the fields and tables are and how they're used, will help users generate useful ad hoc reports. Good metadata will also aid in troubleshooting potential data problems. It's realistic to think that any application (and its database) will have its share of problems. Good metadata can help you or the database staff figure out how to resolve issues quickly.

#9: Enact sound version control

Make sure you have a good version control process in place and that feedback and bug reports are incorporated into the version control system.

#10: Select a liaison

Provide users with a reliable method of making their concerns known. Appoint one person -- either a subject matter expert from the business unit or a technical staff member, such as the project manager or a systems administrator -- as the liaison/communications coordinator to ensure that users maintain confidence that the application is working properly. This liaison should supply accurate feedback to you and stay in touch with users until the issues they bring up are resolved. This will also keep the developers from possibly frequent interruptions.

#11: Seek feedback vigorously

Implement an automated and easy-to-use method for entering feedback, enhancement requests, bug reports, etc.

#12: Play Nostradamus

Try to predict the strengths and the weaknesses in your application. Take notes and make plans for fixes, enhancements, etc. Later, compare this information to user feedback to figure out how to design better the next time.

#13: De-stress yourself

Do something totally unrelated to the project. Swim a few hundred laps. Plan a trip for the weekend after implementation as a little incentive to meet the deadline. Update your resume (you should be doing this regularly anyway). Do whatever it takes to keep your stress level in check at this critical juncture in the application life cycle.

Expect the unexpected

Finally, it's important to note that the transition to production does take a little bit of time. The user interface will need tweaking here or the database will need scrubbing there. When implementing a new application, dealing with unknown, unpredictable issues often causes the greatest frustration. All you can really do is plan well and hope for the best.

3 comments
jefferyp2100
jefferyp2100

Document? What are you, some kinda anal-retentive wimp?

ssharkins
ssharkins

Another good article Jody. This would work well for a general check list to add to the beginning stages. I've been snagged by #2 myself -- very unpleasant. In the end, IT would not throw the appropriate switch, and I had to recreate an Access form. It wasn't a big deal, but was still a nuisance. Fortunately, the client was annoyed with me.

ssharkins
ssharkins

I'm sure that's a rhetorical question, but I don't get it.

Editor's Picks