Last week I had a technical deployment that didn’t go well at all. While we had done extensive testing in development and staging, there were conflicting technologies in the live environment that caused our project to break when we installed it. It wasn’t really our fault, but it was pretty embarrassing.
So what’s the best way to handle this scenario if it happens to your software? First, understand that anything can be fixed and that developers really do want to correct their mistakes and get the project back on track. The best way to help them get from here to there is to follow these steps:
Prioritize the issue — let them know what is most critical to have back in place and what can wait until after Tier 1 issues are resolved.
Let them work. You can try to hold conference calls with your developers and set meetings to talk about how frustrated you are, but this just keeps your project team away from their work, which further delays the repair of your project.
Set regular check ins. This can be a phone call in the morning, or a simple agreement where each time the developer feels an issue is resolved, they can send you a request for testing. This will let you ensure that each item is complete before they move on.
More than anything, try to remain calm. You absolutely should hold your vendor accountable, but be a partner in the process. I promise they did not set out to launch a faulty product — sometimes there are unforeseen issues that arise that can’t be blamed on any one party. And really, blame is beside the point when it is possible to repair what’s gone wrong.
If your technology vendor sees that you’re trying to move forward, they will step in line and support the effort with all of their resources. If the vendor sees that you’re looking for a target to blame, there is no reasonable way they can assist you. Searching for blame is a lonely road, my friends.
If you do manage to keep your wits about you during a technology disaster, you’ll also see these fringe benefits:
Additionally, when your developer is working to fix their own solution, they will often find the old spaghetti code of developers who were in there before. They have the choice of cleaning up this code as well as working on their code or just leaving that old stinky stuff in there. A client who works in partnership with developers often winds up with a cleaner project overall.
In the case of the project we deployed last week, we wound up cleaning three years’ worth of bad code because the client was keeping [relatively] cool. It’s just easier to do good work for good clients.
Marci De Vries is president of MDV Interactive, a web consulting firm in Baltimore. Reach her at email@example.com.