Determine the flow of responsibilities

This is Part 6 of our The Life of a Project Series.

A massive project requires…well, massive resources. On both sides. On our side, we had three writers working to finish this project on time. We set up a protocol for dealing with the client and within our company. All work went to a single point of contact on our side.

To be honest, there were two points of contact. One senior writer, with many years of experience, a programmer’s background and an engineer’s heart and brain, took the foreground of this project. He was the face they saw, the name they knew, and the one who worked more hours than anyone else.

I was the second point of contact – mostly because I think they trusted my voice. When I said this is what we could do, they accepted it. When I said this is how we want to work, they accepted that too. They brought in a technology expert and then in some cases, all but ignored him when we disagreed with what he was suggesting. The funny part was that after a long conversation with this very knowledgeable person in Ireland, even HE was agreeing with me.

But overall, the flow of responsibility on our side was very clear. The client contacted our senior writer for updates, to deliver new material, and to receive drafts. I think I was the one they contacted when they wanted assurances that we were still working late into the night and both the senior writer and I were the ones who were thanked…profusely…in those closing hours and in the days that followed delivery.

On the client’s side, the flow of responsibility was a bit confused at first. We were receiving files from several people and bits and pieces of information from different departments. This resulted, in at least one case, in getting the incorrect information because the file was outdated.

At some point during the frantic race towards finishing this, the client’s main engineer became the clear point of contact, with another senior representative working with me on the more marketing related elements. Engineers within the company sent their files for review and we received each update from this one senior engineer.  It was his job to push the others to deliver, to track, to coordinate all the pieces from all the people so that we had a single, approved feed of information.

There were many lessons here as well. First, from within the technical writing department, in this case, WritePoint, you must have your internal flow of information coordinated and channeled. And, as was proven in this project, the same is true from the client side or subject matter expert side as well.

It’s important to determine the flow of responsibilities in all projects, especially those with critical deadlines and many participants. The company (and WritePoint) recognized this right away and time was saved by never having to discuss this point. From a “philosophical” point the benefits of this decision were clear, and we were happy to see that from a practical point of view, it only took a short while to implement it.

What we were left with, was that it was a pleasure working with this engineer – as it was a pleasure to work with all of them. A few hours before we delivered the final project, when it was clear that we were actually going to meet that red-line deadline, we were all began to breathe more easily.

“When this is all over,” I said to the engineer, “we’re all going out to dinner to celebrate, right?”

I heard him laugh and say, “definitely.” I closed the phone to go back to my last few sections, knowing our senior writer still had more work ahead of him but would be able to finish. I knew than, and know now, that a final accounting has to be made of this project. But one aspect that was handled so correctly from the very beginning was this issue of responsibility.

Stay tuned for Part 7 in this series: How to cope when the project becomes more complex