I’m embarrassed to admit this, but, years ago, in an early project that I managed, I screwed up. Screwed up royally. How would you handle that situation? Here’s how I handled it.
I was responsible for project management, including communication with the end client, and Quality Control (QC) review of all productions that went out the door. Oh, and I was managing three other clients at the time. So, I was very busy.
We had a production going out late on a Friday (do they go out any other time?) and it had been a long week. All I had to do was to get the production QC’d and out the door and I was done for the week.
I went through the steps that the production team performed, spot checked documents that were being produced to ensure that they belonged in the production set, that the images were properly Bates labeled, that redactions were properly applied to documents needing redactions (and that those redactions were extended to the text files being produced). Everything seemed in order, so I signed off on the production and it went out. Because we were up against a deadline, the client chose not to review the production before it went out.
Unfortunately, what I failed to confirm was that the production didn’t include any privileged documents. Somehow, in selecting the final production set, the production team failed to exclude documents that were tagged as attorney work product (they remembered to exclude documents tagged as attorney-client privileged, but failed to also exclude the work product documents). I failed to confirm the proper count of documents, so I didn’t catch the mistake and some work product documents were inadvertently produced.
My boss found out from our client, who, in turn, was notified by opposing counsel. Needless to say, neither of them was happy about the situation. My boss was particularly upset and wanted to know what happened and I was fairly quickly able to determine where the mistake happened. However, since QC was my responsibility, instead of blaming my production team, I acknowledged that I skipped a step and failed to realize that the production set included the incorrect count of documents to be produced.
While my boss was still upset, he stated that he appreciated that I took responsibility for the mistake. We worked with our client to identify and “clawback” the inadvertently produced documents, I made sure in the future to check the count of documents before productions and we agreed that all productions needed to be reviewed by our client before they were produced to opposing counsel, regardless of deadlines. Lessons learned all around. And, I kept my job – actually, that boss even gave me a great reference later in my career!
Regardless how diligent you are in your eDiscovery process, mistakes will happen, at least occasionally. This was not my first mistake, nor would it be my last. But, taking responsibility for my honest mistakes has always served me well. Not only that, seeing others do the same has engendered in me a level of trust in them, because (frankly) not everybody takes responsibility for mistakes when things go wrong. I’ve worked with my share of people who are quick to shift the blame elsewhere if they can.
So, what do you think? Have you “royally screwed up” on an eDiscovery project? If so, how did you handle it? Please share any comments you might have or if you’d like to know more about a particular topic.
Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by my employer, partners or my clients. eDiscovery Today is made available solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Today should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.
As project managers, unfortunately, if anything goes wrong, it is on PM’s shoulders. I lost count of times I have own up mistakes done by team member.
I recall one time, we were going a cutover to production core banking system for a major bank. We prepared a cutover checklist that was not only reviewed several times by all stakeholders but just to be on the safe side, I even push for multiple mock runs to ensure we did not miss out anything. Time we were crucial as the bank will need to open up the next day by certain time.
On the day of the actual cutover, I guessed because the team were tired or caught up by the excitement of the hour, missed 1 small script. All the sudden our internal shakedown testing (another fail-safe step I added in) shows some errors with the migrated data. We run through the checklist to see what we missed and then found the missing script. Tested on the spot to reconfirm.
But by now, because of this, we had to redo some the cutover steps again and this was going to eat into the time of cutover activities where the client are involved. As the PM, of course, I had to face the firing squad whilst the team worked on it in the background.
Thankfully the impact was minimal and it was a successful cutover.
Thanks, B. Joe, sorry for not responding sooner. That certainly sounds like a success to me — thanks especially to your additional fail-safe step. To me, success isn’t necessarily everything going smoothly without any hiccups, it’s about the end result. Anything else is just inconvenience.