Overcoming Workflow Problems

There Must Be A Plan

There has to be some plan, a management directive or some way to get relevant information and knowledge transfers to the tech writer. The most successful means in my experience, have been combinations of briefings, inclusion in important technology discussion meetings (as a fly on the wall!), access to spec and other design or strategic planning documents and meetings, and of course, in person subject matter expert interviews. Emails and posting to a SharePoint site work fine too. From any of these types of information and knowledge transfers I can easily and very quickly outline, or "throw together" drafts. I can even make many different outlines or drafts if time is short and of the essence. In any case, I need at least one reviewer with at least a little time to look over rough drafts and give additional guidance, direction and input. I almost always just get it right the first time. I research and prepare. I do not waste anyone's time which is why my team is always very responsive to me. They know 5 or 10 minutes with me results in even hundresd of pages of well-executed and effective documentation.

The Reality

The writing piece of any project is a team effort where the tech writer supports the project with documentation deliverables. Documentation rests on data collection based on close interaction with key staff, and inclusion in key meetings. There must be close collaboration and information exchanges. There must be designation and availability of the equipment or software being documented, along with the cooperation of whoever has whatever the needed information is. In this economy, I have found silly mean-spirited games which exist in the unfornunate and very poor company politics at times prevalent today. In all my interviews in recent years this problem has been brought up by the hiring managers interviewing me -many times. I think it is why internal staff is often unsuccessful dong the documentation deliverable themselves. This is a huge issue which we contractors solve. We are profesionals who know how to circumvent all the obstacles to just do it! I always reply, . "I understand, I just don't go there -I just get the work done."

Fostering Collaboration

Optimumly, in a cohesive team, everyone wants everything to be accomplished successfully. The key people are under management directove to collaborate to get that documentation deliverable. Without it any project fails. Or fails regulatory requirements.Those with the information must consider themselves vital and accountable to help accomplish an excellent documentation deliverable. Those key people need to give or make the necessary time and information available. In a cohesive and collaborative team, this aspect usually takes on a life of its own as the tech writer is aided and directed by the key personnel with obtaining of the necessary information and important input from the various key or lead team members. The more the tech writer is included in pertinent meetings with timely and key information passed on to the tech writer, the more efficient and successful the writing part of the project will be. In such an environment, seeing the documentation conceived, designed and developed is very exciting and very satisfying. It thus culminates with great management reception and acceptance of well thought out and presented documentation. The deliverable of a true team is greater than that of all the individuals combined, and maybe even greater than even the sum of the whole project -as implementation and operation depend on the documentation...

Even the Busiest People Always Respond and/or Attend My Meetings

Really? Yes, REALLY!

Although the first paragraphs in this section indicate that key people have the responsibility to provide effective and efficient knowledge transfers. That is true yet, in a way, that is a half truth. Successful tech writers must know how to draw blood out of a stone! I am one of those! When that is necessary, I have very successful and time-tested techniques to get the most unavailable, reticent, resistive people to compy. Yet, when I run my techniques, in the end, they believe it was all their idea - and it was in a yway! The key people are the most vested in just getting it done. My role is to facilitate getting it done. I just become another reason it just must get done! How can you say no to your grunt!?

I am also one of those key people. How do I do this? 1) I research and prepare so as to not waste anyone's time-I read the specs, the design docs, the CAD-CAM and other drawings, and other key engineering docs). I know before I go. 2) To me, work has always had to be engaging, challenging and worthwhile - why I have my niche - I work with world class people who act like world class people with world class projects. Everyone else should strive to be world class to pull off their projects. That said, we all want to perform and a job well done is world class-especially in world class companies. Birds of a feather...

A story: I recently worked for about a dozen directors and senior directors. They were under very tight deadlines to update key documentation. Many worked all time zones communicating with their staff all over the world. I could see they were all beyond busy. A few of them quickly set up a SharePoint space for me with their redlined and commented documents... each gave me a few words about what they needed. Then they were gone. In meetings. Travelling. In training. Wow. How do you chase Directors and Senior Directors!!? There were deadlines. Directors meet deadlines. Ever hear of 'deadline driven?' I worked very hard on all their documents. I was amazed and very pleasantly surprised. Setting up Zoom meetings, getting their reviews, modifications, additional updates was effortless. This was one of my most amazing experiences. It was amazing, Their speed and light touches, with smiles, encouragement and acknowledgement of my efforts was astounding. It all got done well ahead of deadlines and my contract ended early! Oh it was a 5 month contract. I finished everything in less than 2. Templates were in flux as were a few other things regarding the content. So, I got another month, then up to 3. Some do care about their word, so they drummed up a bit more work so I ended up with 4.5 months - close enough to 5 even though I tore through the work in 2. They kept their word, tried to get more funding for me, and gave me plenty of notice. Wish all clients were like that!

It's a Process! (Long or Short!)

Arriving at the final deliverable is a process that can be long, very frustrating and painful, -or- efficient, timely and collaborative with lots of knowledege sharing. It is important to note that the tech writer is not a subject matter expert (SME) nor a manager with any rank at all, basically being at the bottom of the food chain. That said, I have become a SME of sorts regarding subjects I have fully documented in depth; a go-to person. The tech writer is a facilitator that collects information from SMEs and then digests, organizes and presents it for review via various authoring tools designed for various audiences. Different audiences may have different entry points and purposes in operating the hardware or software being documented. Policies and procedures can also be included in user guides, systems and operations manuals, and even included in help and other reference material systems to ensure proper staff comprehension and implementation, along with referencing the actual (regulatry purposed) documents.

Documentation, in my experience, is most successful with communication and confirmation of a clear visionthat is givenand part of stated expectations with sufficient instructions and good direction, guidance, and collaboration -to get it right the first time.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The art of tech writing, to me, is to make all this happen despite all odds, with very busy staff who have very little time dealingwith the design and development of leading-edge, state-of-the art, and very complex technologies! All this can also be moving targets, under the pressure of meeting stiff deadlines all within and under budget! I love it!

An Unusual Problem

In just one situation (luckily!), despite my indicating that "somebody has to tell the tech writer", I was not invited to any meetings! This went on and on despite my request for information and knowledge transfers. Usually, at least the technical staff know that technology and especially documentation is not magic! In that particular situation I considered myself in my mind's eye to be The Telepathic Tech Writer. I gave myself that title! I have been resisting the urge to put it on my resume!

In another situation (is this deja vu!?), again, I was not invited to meetings, and, I did not have the equipment I was writing about (due to budget, demands on staff, lack of their time, and other logistic contraints). I indicated that "somebody has to support the tech writer" -to get and provide what the tech writer needs and is supposed to be writing about. I stated clearly that doing it this way (with no support for the tech writer!?), would result in a little more time with a few more reviews. Nonetheless, I performed, and and the documentation deliverables all rolled out as needed.

My point: I just get it done. I overcome financial or other constraints, oversights, or perhaps even negligence or destructive political games, or refusal of infomration sharing for job security!. I do not take it personally I just carry on. I rise above it all and just get the work done. In this particular situation I pointed out that support is a two-way street in that key staff, and the subject matter experts, must support those supporting them to acheive the best possible result in the most streamlined and efficent workflow pssible. I do not play politics, I just roll and get the job done and then move on... whatever!

My Work Experience

Each project has their own particular challenges, project problems, -and often weird politics...we live in strange times! that's life! Especially in these times everybody is running ragged and scared.

Oh well, as the pendulum swings, we will get back to funner and kinder times someday.

I foster collaboration and get the job done in any situation.

 

 

Incorrect Writing Estimates and Failed Projects

I never look for 2 or 3 month projects. I never knowingly accept 2 or 3 month projects. The shortest projects I consider are 6 months or more.

That said, most writing projects are described as 4-6 months. In my experience that means 2 to 3 months of work. Six months means very, very short term, and that there is much less than 6 months of work. (That said, I have also turned 2 month contracts into a year or 2 or 3, even 4 years. So, if a short project is exiting to me, and I am available, -I will and do take short projects too.)

If a tech writer has 10 or more years of experience, or is exceptionally driven, and talented, and collaboration with SMEs to get knowledge transers and reviews is very timely, then the 6 months is actually 2 or 3 months. THAT'S THE REALITY.

Those estimating the work are clueless because they are not professional writers. I do NOT believe management lies or misrepresents writing tasks or workloads, though I have wondered about that at times. They estimate the time they would need for themselves to do the work, -how long it would take them - with all their workloads, meetings, managing and herding cats- as to how they would get it done. That is what their estimates are based on. Just incorrect. However, it is great when they give generous time estimates which often allow for better more complete work. Much appreciated. It is better to work calmly than stressed out. Stress and rushing might not help the writing, though many of us can pull off daunting tasks after procrastinating and getting slammed with deadlines. There must be a balance to have time to do the job correctly - with high quality but sometimes deadlines make anyone more fearless!

Another writing issue that goes beyond writing. Please look at a textbook or any training or in-depth reference material and look at the credits. Credits are either at the beginning or at the end. Notice the 100 or so people that conceived of and worked on that book. Notice all the roles that go into the book assembly. The tech writer often works alone filling all those roles. Almost any of those roles can get buggy and the hardware of software (HW, SW) can fail -when almost finished -before saving. So managers, be aware! And tech writers will often just get it done overcoming various bugs or HW and SW problems without a peep (kicking themselves!)..

In addition to inaccurate writing work estimates, it seems that there is a huge disconnect between HR and the contractor hiring managers. When HR is involved in contract or temp hiring, they apply the same ideas they have about hiring full time "permanent" employees. HR always looks for longevity, reliability, l-o-n-g employment and longterm projects -look for years of experience doing the same thing -excuse any gaps becasue sometimes the next contract isn't there for contractors after a 2 week notice or less.. Yet contract and temp work exists BECAUSE there is very little, or no longterm work, with the exception of contract-to-hire. Contract-to-hire openings are often positions that can be long term. When contract-to-hire plans exist for longterm assignments that means there is a vision and a plan for documentation -and documentation maintenance.

Nonetheless, the reality is that corporations are in flux in a volatile, at times often in an upredictable economy. And projects fail. Or budgets are burned through faster than expected and key people must move on due to no funding. Such factors impact projects in many ways. In addition to the factors already mentioned in this section, projects just fail. The short term projects on my resume were supposed to be longterm. Those projects failed -through no fault of my own. So work disappears and so do the contract assignments. HR does not understand this. Often HR mainly fills those entrenched longterm, full time employee (FTE) positions with benefits. HR staff just do not understand or realize that there are not enough FTE positions for everybody. Competition for the contract positions is fierce. So, HR people - please do not hold contractors to your FTE hiring standards looking for decades of consecutive employment! Contractors are often entrepreneurial and must think out-of-the box to do what we do and so we can come in and solve your corpration's problems that your own -entrenched- employees cannot solve.

Myself, and many, many other contractors have many, many years of doing the same work across many many different types of global and local companies. That is longevity.

I have about 15 years of technical writing. FIFTEEN YEARS. (Actually a bit more than that!) That is longevity. Reliablity. Steadfastness. Longterm vision and drive on my part, despite all odds to pursue my passion to work in leading edge, state of the art technologies with brillant teams and write. I love tech writing work. It is all I want to do.

We, The Contractors, keep on going without any corporate support and scant benefits, (other than our pay check -thank you very much, it is greatly appreciated!). We have no countryclub environments to work in! When corporate country club environments exist, we are often mostly excluded. We do not mind, we are there to just get a job done that could not be accomplished without us.