Post Mortem from Technical Writing in a Surprise Lean/Agile Environment

Not too long ago I was assigned the task to write the documentation for this new product. although slightly bigger than the standard document size in my field I did no think it would be a big issue tackling the task.

I would be gravely proven wrong. In fact this project would grow and eat up all my time leaving my looking like a question mark a whole bunch of times.

The main reason the this project came to be more complicated that is should have been was in my opinion these factors.


Inconsistent Project Directions from customer
The documentation type, quality and target audience requirements kept changing for about half the project.


Not knowing what type of work process the customer used
Previously not dealing with lean/agile methods for this customer, not knowing they started using this for this team made previous processes quite inadequate.


Previous projects of this type did not follow the guidelines
In addition to creating new documentation it was later added to merge similar projects not following the specified requirements into this project.


Time Constraint
This was all done with a very short time frame. I believe it was the fasted up to date for our customer.



This in turn lead to a series of problems. I have listed the ones I found to be the most time and energy consuming below.

This Specific Project

• Not knowing the project used lean/agile methods of working
• Having my assignment description changed
• Doubting all information channels
• Not being on site
• Inconsistency in input documents

Agile/Lean

• Not attending daily project meetings
• Working with off shore assets
• Doubting all information channels
• Weekly changes due to the scrum iterations

I'll try to illustrate by showing where my time went at first.

When I realized that they where working in a lean environment with daily project meetings. I started attending them and changed my approach. I found out that information flow to follow and somewhat decided on one of the order requirements. As a result my time could be spent somewhat differently.

Looking at the purple section which shows the time where I can actually produce content one can instantly see a huge increase in time spent (This is a good thing). Freeing up time from getting the right information made and instructions made it at all possible to finish this project although many a late night was required.

From this experience I take some lessons learned with me for future projects. Some are general issues that

Lessons Learned

• Know how your team is working
• Attending daily project meetings
• Work flow focus
• Review Process
• Communications in and outside the team
• Workload
• Identifying and contacting SMEs
• Identifying project goals and project type early
• Identify document type
• Who is the target audience
• Key points to cover
• Document style

Let me know if you have any ideas or opinions on this.

Workload

The workload has been increasing rapidly and I now deal with four major tasks at work. One of these has been the first contact with CPI in a lean environment. Something that has been tricky to say the least. Not having much experience as a tech writer it´s been challenging working with a project that changes direction every week and getting larger and larger by the day. However it´s my project and I´ll be dammed if I can´t make the end result be, acceptable. By that I mean be outstanding from someone with my limited experience. Working towards telecom one might guess what companies I write for in Sweden. The most challenging task aside from getting the right technical information in time has been starting working with the range of the client’s tools and accesses. These two factors can probably take up to 50% of my time on projects. I guess there is just one thing one can do about it. Be a bit of a bitch and get in people’s faces until stuff happens. Usually literally getting into peoples face is the best way. Always arm yourself with a good smile and people skills though. Swedes and I think people in general have a real hard time saying no to people face to face when they think it´s a reasonable request.
I think to manage technical writing fast one needs two things: a good feel for structure and a way with technology or academia. One does not need to understand everything and this is where the shoe needs to fit. I think understanding is superfluous at times as a tech writer. It is great to understand, but it´s not always feasible to understand everything for every project. The important thing is to understand enough. I guess this takes one to the old dilemma of the good enough concept.
My approach is much like one would to back in school. Look at examples, analyze and re-engineer. Trying to divide your way of describing things in modules that has been proved to work will minimize chances of getting things wrong and also your creativeness. Then again how creative is a tech writer supposed to be?
It will be interesting to see how a dyslectic like me will fare throughout this project. So far all feedback has been over expectations. If I can manage my projects and my time here with good or great reviews I think I´ll give myself a pat on the back and determining I can do writing as a profession, with a little help from the spell check function and lots of read troughs ;)