Why outsource Technical Communication? To most of our clients, outsourcing their Network Engineering services, Data Centers, or Help Desk services makes financial sense. They can evaluate their Information Technology (IT) needs, perform a cost/benefit analysis, and contracting out the services can be traced to a specific cost saving.

Technical Communication, on the other hand, is seen as more of an overhead expense than a revenue-generating or cost-saving measure. Why not let the vendor who is offering the Network Engineering services take care of the documentation? Why not create the necessary documentation in-house? Why not let the technical people in charge of the systems write their own documents? This blog explores the pitfalls that come with this reasoning, and next week, in Part II we will provide tips on finding the right Technical Communication-as-a-Service team.  

Industry Challenge

The problem, poorly documented systems, stems from many sources. Typically:
  • Engineers and developers are too busy working on the systems to document
  • Some engineers and developers lack writing skills and avoid the task
  • Many engineers and developers hate writing or view documentation as a “waste of time”
  • Documentation is viewed as an “extra” task to be accomplished rather than an important part of the development lifecycle
  • Documents are viewed as a non-revenue generating activity and tend to be low on the priority list
In most cases, systems operate without proper documentation until some exigency brings the gaps to light:
  • A senior engineer or developer suddenly leaves, and there’s no knowledge transfer and nothing documented to help the person coming on board
  • Reviews or accreditation cycle due dates create external pressure for documents to be in place
  • A poorly documented system breaks down, and issues with systems that are poorly documented are harder to diagnose
  • A poorly documented system needs upgrades, and It becomes difficult to keep track of what’s the baseline versus what’s being added, creating layered and opaque systems that are hard to navigate

Bottom Line Consequences

At first glance it may seem like documentation is an unnecessary overhead expense, but poorly documented systems actually cost money. Here are some ways you are increasing your cost in developing and maintaining poorly documented systems:
  • Scope creep: Developing systems without proper documentation makes it harder to keep track of the scope and know when the system is considered “Done.”
  • Cost of maintenance: Senior Engineers spend more time diagnosing and fixing problems that could be delegated if the system is properly documented.
  • Compliance: The government mandates standards on documentation of system to qualify for continued accreditation. Non-compliant systems are costly. They increase pressure on the IT teams, who should be focusing on getting other aspects of the system ready for accreditation. Outsourcing documentation at the last minute will actually cost more.
  • Perception of quality of system: Even outside of the government sphere where a minimum standard of documentation is not enforced, users perceive poorly documented systems to be inferior in quality and that perception affects the price they are willing to pay for it.
  • Increasing burden on IT Team: End users rely on the IT Team for support when documentation is not readily available.  IT systems with excellent documentation create a “self-service” platform for end users to access the information they need reducing reliance on the IT Team for every minor request.

Clearly, documentation is both a necessary component to your bottom line, and one that is often difficult to produce in-house. It may make perfect sense to leverage your IT team’s skills, allowing them to turn documentation over to the experts so they can focus on what they do best. When freed up to focus on the systems themselves, engineers can attack the actual never ending list of work they have to do including development, upgrades, maintenance, and more.  But how to choose the right team of experts?

In Part II, we’ll examine the criteria to use in selecting the right Technical Communication-as-a-Service team.

Recommended Posts