From interview to investigation
Interviewing as a consultant for an assignment is more than just determining whether it’s a good fit. It can pay off to do some investigating in the interview, but that means looking beyond things like company culture and pay scale. Don’t be afraid to ask questions about their requirements and readiness for a technical writer. Some organizations haven’t worked with one and aren’t familiar with what you need to get started. You never want to be in a situation where they’re not prepared for you; that can be frustrating for both parties. By asking specific questions, you can assess their readiness, and potentially uncover a need they hadn’t considered.
Asking questions about scope, tools, timelines, and other resources can give you a sense of what you might be walking into. Does it seem like the project is well-managed and on schedule? Do they have enough resources with the right skills in place? Are they expecting you to produce materials in unreasonable timelines?
If you’re exploring an opportunity on a software project, ask about:
- Is there a list of documents/topics to be created?
- What is the estimated number of documents/topics?
- What are the planned outputs and formats (online help, job aids, PDFs)?
- What milestones or deadlines are planned for the documentation?
- How are the due dates tied in with overall project milestones?
Tools and applications:
- Which tools/applications will be used to author and publish the materials?
- Have any templates been developed?
- What is the document review process?
- How many people will be involved?
- What level of knowledge do the reviewers have?
- What is their involvement in the project?
Subject Matter Experts (SMEs):
- How many SMEs will be available during the documentation phase?
- What is the availability of SMEs during the documentation phase?
- Is there a SME for the tools/applications generating the documentation?
- Is there a style guide?
- Are business requirement documents available?
- Has a training needs assessment been completed (if applicable)?
- What’s the current stage of the software (development, functional testing, user acceptance testing, delivery)?
- How stable is the software?
- Are there outstanding fixes and changes impacting the functionality or user interface?
Getting a sense of the project, as well as the tools and resources in place can help you assess whether it’s a good fit. What constitutes a good fit? Here are 10 things to consider:
- How prepared are they for what I’ll need (SMEs, style guide, templates, review process)?
- How familiar am I with the subject matter and how interesting is it to me?
- What is my competency level with the application(s) I’ll be working with (both the system I’m documenting and the authoring tools)?
- Is all the work to be performed on-site or can some be done from home?
- Is the worksite convenient for me (distance, travel time, transportation costs)?
- Do the timelines seem realistic based on the current stage of development and scope?
- Will I be part of a writing team or on my own?
- Is this the right time in the software development cycle for starting documentation?
- Does it appear to be a well-managed project and on schedule?
- Were they able to answer all my questions, or am I comfortable with figuring it out along the way and offering input?
If any answers raised red flags, you can choose to share your recommendations for those areas of concern, or take some time to evaluate whether this is a worthy venture for you. Even if the assignment is short, it’s always better to know what you’re saying yes to.
This article was written by wendyhollingshead
Wendy Hollingshead is a technical writer with a passion for simple and effective training and reference material. She is a freelance contractor specializing in software documentation and instructional design.