posted Mar 24, 2009 3:21 AM by harjot dhodi
[
updated Jun 24, 2009 11:20 PM
]
Often, I get to hear about a question, "What is the difference you observe, while writing for a product-based software company and a service-based software company?" First, let us look at the business models of the both the companies. The model will have a lot of bearing on how technical writers work.
A product-based company generates revenues by:
- Selling the product (to different customers, and different product to same customers)
- Customizing/Implementing the product (may be based on some other product/framework)
- Providing technical support
- Providing training
- Releasing newer/better versions of product with better features
Technical Writer working for a Product-based software company are always considered to be an integral part of the development team. The company owns certain responsibilities:
- Provide good quality, better-written documents. Objective is to restrict technical support and training cost.
- Train writers as it is looking forward to a long-term commitment.
- Use the required tools for documentation (considering cost for required number of licenses).
- Maintain quality of documents so the document structure is much better evolved.
- Get optimum output per hour (to restrict the total number of writers employed). So the writing and reviewing processes are elaborate. You will find a "Style Guide" and/or "Best Practices Guide" developed internally.
- Focus in long-term development of the writer.
- Considers outsourcing documentation activity only if in-house writers are not available. When it outsources, it has well-defined expectations about the deliverable.
- Look for Contractors more than freelancers (because of the predictability element)
- Asks writers to prepare estimates, project plans, milestones, proposals and so on. Writers are given more authority and freedom.
- Put writer in touch with its users (though not if the writer is a freelancer/contractor/TWSP resource).
- Expects a writer to understand the user's problems and cater to them.
- Retain the top 30% of the team. It provides opportunities to the middle 50% and tries to get rid of bottom 20% (even if there is no recession).
- Provide a writer an opportunity to acquire business and domain knowledge and become an Individual Contributor.
- Offers much better career growth path and stability.
- Establish an elaborate processes and excellent mapping of Document Development Life Cycle (DDLC) with software Document Development Life Cycle (SDLC).
- Involves the writers from very initial stages of the product and may dedicate them to one or more products. Many companies offer the writer good visibility of what is going to happen to a product in next two-three years.
- Make the writers an integral part of the product group. Such writers do not interact with other writers in the organization.
A Service-based software company generates revenues by:
- Selling the services (different projects for different customers, or different projects for same customer)
- Selling Customization/Implementation services
- Providing technical support services
- Providing training services
- Releasing newer/better versions of product with better features (depending on the company's contract with the client
Technical Writer working for a Service-based software company is either an overhead or a billable resource. This difference can lead to different observations. If the writer is seen as an overheard that the company had not accounted for; they will try to keep the expenditure on writing to be minimum. In such cases, you may observe that company:
- Provides documentation only because it is a part of agreed-upon deliverables. So it is merely a formality.
- Looks for trained resource; and that too when the project is about to end. This can lead to many problems while writing and releasing docs.
- May overlook shortcomings of documentation because it generates revenue out of User Training.
- Use low-end/freeware/open source tools for documentation. They may want to use MS Word more than FrameMaker (unless their client specifically asks for it).
- Do not maintain the documents so the document structure often looks like "different headings bound together."
- May not be interested in long-term development of the writer.
- Ready to outsource documentation work to freelancers, contractors, or TWSP (though they prefer freelancers or contractors because lower cost.)
- Do not prefer to put the writer in touch with its client. Such projects often result into glitches.
- Willing to lay-off the writer rather than putting on bench.
If the writer is seen as a billable resource you may observe that company:
- Is ready to give good quality and better-written documents.
- Is willing to train writers (as their billable rate improves.)
- Keeps looking out for other type of documentation that can be prepared (and billed for.)
- Involved early in the early stages of SDLC process.
- Is willing to use high-end tools for documentation. Either the client provides the license, or the company invests in it (looking at long-term gains.)
- Is interested in maintaining quality of documents so the document structure is much better evolved.
- Is interested in getting optimum output per hour (to retain client's interest in the services.) So the writing and review processes are much more elaborate. You may even find a "Style Guide" or "Best Practices Guide" developed internally.
- Is interested in long-term development of the writer (add one more to the controversial statements!)
- Considers outsourcing documentation only if in-house writers are not available. When they outsource, they have well-defined expectations about the deliverables.They tend to look for Contractors more than freelancers (because of the predictability element.)
- Ask writers to prepare estimates, project plans, milestones, proposals and so on. Writers are given more authority and freedom.
- Put writer in touch with its client (even if the writer is a freelancer/contractor resource). Company even expects the writer to develop a good rapport with the client, avoid glitches, and get more work.
- Adopt writers to other activities like, testing, UI design, training, proposal writing, and web content writing; rather than laying them off.
Please note that these are only my observations and and should not be taken as the industry rules !
Post a commentPost a comment
|
|