 |
Don’t Forget Quality in the Process |
|
Recently, as I was entering a new job environment, a former employee of the company mentioned to me that the VP “was real big on processes.” Okay, I can follow and adhere to processes. However, I later realized that it was ALL about process and not about the quality of the item being delivered. The first few weeks in the new job were utter chaos. I had network problems, I could not get builds of the software to load, and I couldn’t find anyone to take responsibility for getting these items resolved. Okay, I did find one, but let’s just say that he was not much help. (I learned from another writer that people knew not to use this particular person because instead of fixing the problem, he usually made the problem worse.) The acting manager was of little help. I was taking over projects (and equipment) from him, yet when I asked questions, he responded to the question and nothing more. I had previously been employed at another company where the majority of people were good workers, with only a few exceptions. At this company, it seemed the opposite prevailed: a few good people with the majority not being very good. I also noticed that within the Documentation group there were not any levels of quality to strive for. It seemed that if you followed the process and produced your deliverables (good or bad) you were treated the same. For example, when the acting manager discussed the yearly bonus plan, he said “Well, Jane (the previous manager; not her real name) always gave everybody five per cent (the maximum amount permitted), so I will do the same thing.” I got the impression that nobody cared. As long as you delivered your doc items by the delivery date, all was well. Unless, as I learned, you didn’t follow the process! My first projects had all been with groups that were not resident in the main office. All correspondence was conducted via email and all meetings took place via conference calls. This “remote” project structure was less structured than the process followed if all participants were in one location. I did well with my remote projects but didn’t fare well in the structured, on-site process. My philosophy is more “deliver on the delivery date.” However, this company’s process for delivery was more focused on “following the process.” For example, you were required to update the schedule each week and specify, by hours, what had been done and what work remained to be done. That sounds easy enough, but this particular project had a very intense project manager who would panic at the least sign of a possible slippage – and his focus usually seemed to be on doc slipping! In retrospect, the cause of his panic may have been the fact that I was the new kid in the group, and, since he wasn’t familiar with my work, he was worried about doc delivering. Also, I think I should have just kept to the schedule (entering that I was done even if I wasn’t), because I knew I would deliver on time even though it may not have always looked that way on the schedule. However, I am honest and try to convey exactly what is going on. As much as I assured him that I always deliver on projects, my assurances were not enough. I was amazed at the level of focus on “the process” and hitting each milestone, rather than on what was delivered (at least concerning documentation). Yes, the process is important for keeping everything on track, but what counts (or should count) in the end is that you deliver quality material by the designated date. It is easy to create a concrete, physical structure such as a process. However, it takes effort and time to build quality into that process and to set standards of quality for people to aspire to. In this particular experience, the feeling was that documentation was a necessary evil but that if you didn’t follow the process you are out of here, even if you were to deliver quality documentation and hit your deadline! |
|
|
About the Author: Jeff Staples STC Senior Member of the Houston Chapter, is an Information Developer in Houston, where he creates online and print documentation. |