This is Part 7 of our The Life of a Project Series.
It’s great when a project goes as expected; when all the required material is given to the technical writer, all the SMEs are there to give their input and review the document in progress, and it all comes together on time. I’ve had many projects like that over the years. By far, the most amazing project I ever had – in all my years as a technical writer – was one in which the client sat the development team and the technical writing team (that would be me) down at a table and handed us each a long document of specifications and mock-ups.
Go program this, they said to the developers, who smiled and began reviewing the document.
Go write this, they said to me.
“Um…are you crazy?” I wanted to say but figured there had to be a more diplomatic way. I asked them if they didn’t think that perhaps I should wait until the programmers actually had some of the interface done. No.
What about changes during development? Won’t be any, they assured me.
I tried to explain that what they were asking us to do was pretty darn close to handing me a magic marker, tying on a blind fold and putting me in one corner towards the left and telling me to start making a line along the wall to the right.
In the meantime, taking the programmer to the corner on the right, handing him a magic marker, tying on a blind fold, and telling him to go ahead and draw a line moving to the left.
When we bumped into each other somewhere in the middle, there would be two distinct lines, with no meeting point. It would be fine, the project manager assured me. With nothing to test and nothing to see, I was free to go back to my office and write. The single source of my knowledge was a document telling me what would go where, what would happen when my end-user pressed a button that I was assured would read Schedule, which would be right next to two other buttons: Update and Delete.
While I believe my skepticism was well deserved, I was wrong. The project manager kept close tabs on the developers – they were never allowed to change anything from the specs and so, a month or so later when I presented my document and compared it to what they had developed, I was amazed to be inserting screen captures that matched my text, and confirm procedures according to the steps I had written!
Most projects, however, don’t go nearly as smoothly as that one did because there are changes along the way: new developments, unexpected bugs, additional feature requests and, so much more.
How do you cope when the project becomes more complex? First, by understanding that this is often the nature of the work we do. Companies can rarely afford to bring technical writers into the picture after the product has been fully developed. We almost always are running after a moving target. The sooner we accept that, the easier it will be for us.
Secondly, by acting as team players, it isn’t that the project has become more complex for us, but rather that we as a team have additional challenges. When the project we were working on became so much more complex, we realized we were working with more unknowns than the team had discussed at the beginning.
One problem was a misunderstanding of what the end-customer needed. Once that became clear to our client, the document’s format shifted again and more requirements were added.
This post isn’t so much about how projects can become more complex, but how to cope with that when it happens. My way was a bit of humor. I turned to Facebook and several lists I was on and posted this:
This is the project that never ends.
Yes, it goes on and on my friends.
Some people started writing it not knowing what it was,
And we’ll continue editing it forever just because…
This is the project that never ends.
Yes, it goes on and on my friends.
Some people started writing it not knowing what it was,
And we’ll continue editing it forever just because…
Even as I posted it, I knew that we were nearing the end both in terms of the deadline and in terms of the work load. Getting angry or upset would have been a waste of time and certainly looking to blame others won’t help. The client’s engineers were right there with us through the long nights we worked and the many many days it took to complete this project. Their attitudes were positive and they were not only willing, but anxious to work that extra bit to help us all deliver the finished project.
When the project becomes more complex, you can cope by remembering the human aspects. We all worked hard – but knew, at each stage, that we were being appreciated.
Stay tuned for Part 8: Delivering quality (coming soon).