This is Part 9 of our The Life of a Project Series.
It’s funny that this post seems to be the hardest of the series to write. Till now, I was basically explaining what had happened or what should have happened. This post is supposed to be about the lessons that we learned and how we can be better tomorrow. The last post, which I only decided on in midstream, will be lessons I hope the client can learn. In essence, these last two posts are, on the one hand the most important of all of them, and on the other hand the post-mortem we have scheduled.
Wrapping It Up
Well, we finished the job – on time. It was sent to the company in the early morning hours before the engineer was scheduled to fly. Once he knew there was nothing left but our work, that his team had delivered all of the parts that would make up the whole, he finally left to go home to pack. A team stayed there until we delivered the file; they printed the copies, burned the CDs, and assembled the final deliverables.
The plane took off and within hours we received two notes from the company. One was from one of the vice presidents, with a picture of the document, all bound and beautiful. The second was from one of the senior people who wrote simply, “We had a very intensive weeks but…..I am glad we were together throughout this journey.”
Lessons for Tomorrow
Okay, here they are (feel free, if you’ve read this series, to add more):
- Though we like to begin a project by writing and getting to work, I think had we invested more time, perhaps even a significant bit of time, going through ALL the requirements at the outset, we would have identified a critical flaw in the process much earlier. The client did not have all the materials that were needed on hand. It wasn’t a question of at hand (meaning where to find them) but ON hand (meaning that some of it simply didn’t exist and had to be created).
- We were tasked with preparing and assembling the materials for the final document. We all focused on the preparing part, when the assembling part turned out to be a bigger obstacle. Again back to that initial meeting – we accepted the outline provided to us, with the names of the various contacts and who was responsible for what…in retrospect, I would have preferred to have built this table with the engineer. Had we sat together with him explaining each section, I think we could have identified what later turned out to be a series miscalculation on what was needed. At one point, the engineer estimated 20 hours of work. I knew he was off on that, but did not, at that time, realize that he was literally 6 times below what would be the final number.
- We had more resources we could have put on this project – earlier and for longer periods of time. We had three writers working on it – but the third writer put in much less time and we could have used him much earlier had the client agreed. I think, had we pushed harder, we could have gotten the client to agree but during the initial stages when we had more time, the client was happy with our two main writers and towards the end, we only really had two main tasks and so were back to the two main writers.
- Interviewing the experts – much of this job involved the engineer gathering the information, selecting what he felt was appropriate and feeding it to us. We appreciated this because we felt it would save time and keep the flow of material coming to us. In some ways this worked, in other ways, it was less effective. At one point, I was working with someone in Ireland as we clarified, edited, and finalized an important section of the document. I had compiled the first draft; the industry expert reviewed it. Amazingly enough, he had printed out the document and then marked his comments, suggestions, deletions, etc. with pen/pencil. He then scanned the pages in and emailed them to me. I have to admit, it is years since I worked with a printed-out document, let alone a printed out document that had then been scanned. Luckily, I have two computers and some very nice, large, wide monitors on my desk. On one workstation, I viewed his scanned document and the original document on a second monitor. On my laptop, I had my working document where I was inputting his comments as we spoke. He even suggested initially that I print out a copy and mark it up as we spoke. My response was a very polite, “um…no.” Needless to say, working off paper, even scanned paper, is just not the way to go. A few hours, not many in the scope of things, but still, a few hours could easily have been saved if the industry expert had simply worked with track changes. But there’s a reminder there, if not a lesson, that there are still experts and engineers out there who want to print out a file rather than edit electronically.
- A clear lesson, though I have no idea how we could have known this in advance or implemented any changes even if we had known this, was that the client had significantly and almost dangerously underestimated the start date on this project. I really don’t think this project could have been done in much less time (though at least 10% was wasted on inaccurate or changing information). The big difference could have and should have been in the span of the time. What we accomplished in the last 5-6 days should have been spread over double that period. On the scale of documentation projects, 120 hours is not really huge, especially considering that we delivered a 180 page result. But it leaves us with the feeling that it was massive because the hours were very long – one stretch…the final…had one writer working for 22 hours straight.
I’m sure there are other lessons to be learned but it’s been a long day with a bunch of meetings so I’ll stop here. I’d love for some of you to jump in with other lessons you think should have been learned from the technical writer’s side of things. Tomorrow or Sunday, I’ll try to tackle the lessons that I want to present to our client for the next time we have a similar project.
Here’s a link to the last post in this series: Part 10: Lessons for the Client-Side