Let’s go back to that stuffy little conference room in the UK midlands and pick up where we left off in this book’s introduction.
The customer unloaded on us from their side of the conference table, taking turns venting their frustration. When they had exhausted themselves, I paused for a moment and asked, “Can you show me your RAID log?”
They looked at each other, then back at me. I let the silence go until it got quite awkward.
I looked up and down my team’s side of the conference table. “Can you show me your RAID log?” My team had the same awkward, silent response. I didn’t know if everyone in the room was embarrassed that they hadn’t been using a RAID log, or if they were embarrassed that they didn’t know what I was talking about. But, either way, my question had the intended effect.
I plugged my laptop into the conference room’s overhead projector, opened a fresh clean RAID log and started at the top of the Issue log. “OK, let’s review each of the current issues as you see them to make sure we understand them correctly.” I had the customer walk through all of the issues in exhaustive detail, asking questions along the way and documenting it on the projected Issue log for all to see.
After a long, emotional review of the issues with the customer, I asked, “Is this all of the issues? Is there anything else to add?” It was a pretty long list by now, but I wanted to be sure I had it all. When they were satisfied that I had, I turned to my team, on this side of the table. “OK, how about you? What issues have you run into on this project which have kept you from being successful?”
Boom! They unloaded nearly as many issues caused by the customer as the customer had just listed about the team. Carefully facilitating the discussion, I let my team express their issues but kept it civil, all the while documenting everything in the Issue log. Many of these items seemed like very legitimate issues caused by the customer – the customer didn’t have this or that ready, they weren’t responsive, that kind of thing.
Once we had all the issues on the Issue log and we could all see them there together, it quickly became apparent that the root of most of our problems were missed and misunderstood dependencies between the project team and the customer. The project team needed quite a lot of information, material and support from the customer, but it was pretty clear that the customer had not understood those dependencies and their impacts.
Rather than focus on blame, I added a Dependencies log to my RAID log and had the project team walk through every one of their dependencies on the customer. As we added these to the Dependency log, we talked through each one with the customer to ensure they understood the dependency and why it was needed. We set a due date for each one and identified a responsible customer resource, and continued on to the next one.
What was magical was that by the afternoon of the first day, the mood had completely changed in the room. Instead of their side of the conference table vs our side, we had all gradually turned our chairs to face the RAID log projected on the wall; our new shared adversary.
In the days that followed, our teams worked very closely together, using our RAID log as the shared focus of our efforts and to track our progress. It wasn’t us against them anymore, we were working together to overcome the issues we had jointly identified and agreed on – in the RAID log. We had taken the conflict between the customer and the project team and turned it into something concrete that we could understand and work on, together.
By the end of that week, the customer had retracted their legal notice of cancellation. Within 2 weeks, we had a new baseline plan agreed to. A few months later, we successfully delivered the project – using a RAID log.
