Lessons for the Client-Side

This is final part of our The Life of a Project Series.

Sometimes we have an attitude of “been there, done that” when it comes to projects. In almost all cases, there are unique elements of every project we tackle and yet, there usually remains a common thread or set of practices from which we can derive lessons for improvement. While we finished the project on a high note with the praise and thanks of our client, we have still taken the time to review both our contributions and the interactions with the client to learn for the future. In the previous post, I detailed some of the key learning points from our side (and I hope others will contribute their thoughts as well). In this post, I’d like to detail some of the lessons I believe need to be implemented by our client:

  • Timing the entrance: First and foremost, as is often the case, the technical writing team was brought it too late in the life of the project. There is no reason for a person to have to work a 22-hour day, or even a 16-hour one. We had several of these, knowing we were in a mad dash for the end. It didn’t have to be this way and while we had the complete cooperation of the client – it could have been with so much less stress and uncertainty about reaching that finish line, if we’d been brought in sooner.
  • Version control is another place where lessons are to be learned. More than once, we were given the wrong document. Once, we lost several hours; the second time, we lost additional time integrating comments from various places over new material we had added. Technical writers have to rely on the engineers to give them accurate information. When the information we receive is not up to date, valuable time is wasted first discovering this mistake and then waiting to get the correct document.
  • Check info before giving to tech writing team: Sometimes simple information was given to us…in three different versions. At one point, we were told to remove the Ltd. from the company name because it was thought that a different subsidiary would be used. Then we were told to add LLC, and after we had implemented both of these, we were told to put Ltd. back in place. This is more an example than any major time loss factor. The lesson here is that information has be be confirmed before it is given to technical writers. We work as fast as we can to implement these updates. When we have the wrong information and have no way of verifying otherwise, this ends up costing more time.
  • Teamwork:  This one is a lesson for others – not for the project we just completed. There was not a single moment during this project that we did not feel ourselves to be part of a greater team. Even in the middle of the nights, while we were still working on new sections, we were told we could call and when we emailed or called, they were right there. We were constantly given thanks, approval, and encouragement. They appreciated our catching problems and offering suggestions. On more than one occasion, they took our advice over the third party adviser they brought in.
  • Estimations: Companies like to feel in control of how long a project will take and underestimating is very common. Rarely do companies really accept that you really cannot write 100 pages in a week or that formatting a document really does take time – especially when it is given to you as a complete jumble of fonts, sizes, etc. If there was one mistake we all made, it was in not taking the extra few hours to really review the engineer’s initial estimation of not only how long it would take (which we knew from the outset were not realistic), but his estimate of how much had been done, how much needed to be done, and where the information would come from.

I have always said that a project’s success or failure is often determined at that very first meeting. In this case, if all had been decided in that first meeting, I think we would have failed to deliver the document they needed on time. The reason we could get a final note saying that the company would be honored to be a future reference for WritePoint and why we do hope and expect to continue working with this company is because despite the initial “misdirections,” the project was a success.

As the engineer was on a plane flying the document to the end-user and as our writers were sleeping off many days and nights of working, I was filled with a deep sense of satisfaction. To see it echoed in the emails from the client has left us all smiling long after the exhaustion has burned off.