Here's where you should always begin:
1. Determine your role in the error's genesis.
To gauge the error's impact, start from the point that it manifested itself and work backward. Where in your business process did the fruit of this error begin to flourish?
Now is not the time to reprimand a staffer or lay waste to a project team with harsh words. If it was your delegate that made the mistake, that doesn't mean that they're responsible. Know where in the chain of command the error happened, whom it impacted, and how everyone—both designer and client alike—may have contributed to the outcome.
This activity is not about blame. It is about systematically assessing the actors on the stage, and examining how their behavior may have influenced the project's progress. This is what's known as root-cause analysis. In doing so, you'll need to keep yourself from thinking, "In hindsight, I would have..." and focus on the basic facts of what went wrong. This is when you get to dig through your email, interview your colleagues, explore documentation and functional requirements, crack open design files, sift through code, and otherwise reconstruct the path your project has taken through the design process. Ideally, you should document in writing what you discover. There may be legal ramifications to what you've found, and having a trail documented in writing may be critical if you end up in court.
If your team can handle it (while they're working hard to right the error), have them aid you in the process. After all, they're going to feel just as bad as you do until the problem is solved.
2. Gauge the impact of the error to your client.
Try to quantify in hard numbers what your client will suffer until the error is righted. If you're working on an interactive project, gauge through metrics exactly what the impact may have been to your client. Did they lose $10,000 in potential sales due to people clicking a button in an email and going to a 404 page? Or did a thousand people receive the email and only two people clicked on it? You need to understand what the client has tangibly suffered as the result of the error, and using best-case metrics, what potential outcomes they may have suffered. These hard numbers should help guide your action plan.
A critical point here is that your assessment of financial impact does not need to be disclosed in full, unless the client is on the hook for hard costs or a change order due to their role in the error. You'll need to tread carefully if the latter is the case, because first they'll need to be convinced that the error is their onus to bear. Much like in court, the client is often innocent until proven guilty beyond reasonable doubt.
If the real root cause is something of a black box, such as beta-grade technology or a partner that has failed due to inscrutable reasons, I hope that you've outlined the risks and contingencies associated with their use or participation. Otherwise, you're going to need to disclose those issues as swiftly as possible to the client as part of your plan...
3. Write a plan as to how the error will be mitigated, and by whom.
Once you know where the error cropped up in your business process, and it's clear how much damage your client may have suffered to date, you need to formally write a plan of action. This plan can then be sent to the client via email after you've discussed the error over the phone.
What shape should your plan take? It needs to address the following:
- Where did the error appear?
- When did the error happen?
- Who was involved in the error?
- Why did the error happen?
- What are we doing to fix the error?
- How are we ensuring that the error never happens again?
- What are the impacts on your business, both in terms of dollars, schedule, and customer service?
You may need to outline more than one course of action to resolve the error, especially if there's a cost or schedule impact on the client. In these cases, always advocate the best option for the situation that puts the least amount of burden on your client. (That is, unless they caused the error and need to assume responsibility for helping to resolve it. I've seen the latter happen when working off client-hosted servers, or using client-selected vendors for photography or printing.)
It's definitely a sign of maturity to take responsibility when anything major goes wrong on a project. Even if you didn't foresee the consequences of your actions, you get to fall on your sword. If you hired the vendor, you have to manage their failures as well, and work together with them to make things right.
Don't wait to communicate the plan. The longer an error remains unaddressed, the more risk you assume from it. However, don't rush through your plan to get it in front of the client. Have it vetted by the highest levels within your organization.
In my next post, I'll cover the rest of these action steps and a few glimmers of hope in the midst of a hard fail.