Wednesday, July 11, 2012

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.


2 comments:

  1. SME means nothing to me, and google showed Small and Medium sized Enterprises

    ReplyDelete
  2. Sorry, it means Subject Matter Expert

    ReplyDelete