Staffing Within a Centralized Model

Gail Angel
Cognos, Inc.

Is your organization centralized or decentralized? If you follow a centralized model (or one that is largely centralized), there are different considerations you can use when making staffing decisions for a medium-to-large project. For some, the size of the project is not determined by how many documents are needed but by the amount of work. For example, a software release that involves 120 documents and requires 6.5 writers to update them is not the same as a software release of a 1.0 product that requires 20 writers to produce a documentation set of 24 documents. The bigger the project, the more complexities you must consider. The considerations I describe are not suggested in any particular order or relative importance. Everything should be evaluated as a collective set of project characteristics. Our job as documentation managers is to find the best possible outcome after weighing all the factors.

In a centralized model, it’s possible for new projects to be given to the manager with the most available resources to work on it. Resources can be assessed against the technical project requirements in addition to past experience with key SMEs. A centralized model permits the reassignment of one or more writers if the project needs them.

Consideration 1: Company priorities
At last year’s Best Practices Conference, a recurring theme was the need to understand what’s important to senior management in your organization. Consider that the objectives of senior management are always important, even during staffing exercises. Consider the priorities of your company. If you know which releases are most important to the company, either strategically or because of revenue projections, you can determine which projects require your very best effort, your most experienced team leader, or your most gifted writer.

Consider also if the documentation project is for a product that is in maintenance mode (sometimes referred to as a cash cow); investing in the acquisition of knowledge in your writer isn’t a consideration for a product that will soon hit its end of life.

If the project is for a 1.0 product, you know that the material will be new to everyone. In this case, it’s unlikely that one writer or manager will be better suited than another when considering past project experience. However, depending on the culture of the organization, a 1.0 project has unique project challenges that might make it more appropriate to choose writers who are known to be highly adaptive and possess a high tolerance for uncertainty.

Consideration 2: Negotiations with product management
It’s obvious that you need to staff according to the scope of the project. Sometimes, you can start with a small project team and add resources later when more project stability exists. Product management’s first set of requirements can be a long list of wishes and needs. In cases like this, the job of a documentation manager often starts with teasing out the wishes from the needs, so that you clearly appreciate the relative priorities of what you are being asked to do. At times, requests for new documents to be added to the documentation set can be postponed or cancelled once you explain that the effort required from all parties (Documentation, Product Management, and Development) is out of proportion with the expected value to the customer.

Often, our role as documentation managers means that we find ourselves in the position of investor. We want to be sure that our investment provides an acceptable return for the company and for the customer. Each time you are asked to supply documentation for a project, you must evaluate the effort. One way of looking at it is to ask yourself, “If I hired a contract writer to do the work, would I still have a strong business case?”

Consideration 3: Suitable for contractors
When resources are strained due to conflicting release schedules, it is common practice in some organizations to consider using independent technical writing contractors. However, some projects might not be suitable for contractors. For example, if the project is a new initiative and we want to retain the project knowledge for future releases, it’s better to assign a permanent employee. To retain product knowledge, you can backfill permanent employees on their current projects with independent contractors.

 

Consideration 4: Team dynamics
When assigning writers to a project, it’s a good idea to consider how you can complement skills, experience, and personalities. Consider also how team dynamics can be capitalized by different project expectations. A strong researcher will be critical when you know information is going to be a little hard to ferret out, perhaps because of the development style. However, it’s best to have a mix of strengths on the team; adding someone who just pumps out information once they have it would be an unbeatable combination.

 

Consideration 5: Project complexity
Writers with strong technical skills and knowledge will need to be involved in projects that are especially technically complex. It’s important that you assign the most technically skilled writers to the projects that really need them. If a project isn’t taking advantage of a specific aptitude and you need it elsewhere, think about moving writers from one project to another for net benefit to the organization.

 

Consideration 6: 1.0 Version or update
If this is a 1.0 release, you need writers who thrive on uncertainty and aren’t distracted by frequent churn. Those are the same writers who would feel sapped of energy if all of their work was about documentation updates release after release. For a release that has a lot of updates, you need writers who are happy working on maintenance projects—people who find satisfaction in the daily reward of having done a good job. Maintenance projects are also good training ground for junior and intermediate writers.

 

Consideration 7: Project requirements
If there is a knowledge specialty that would make the project easier, then consider which writers have some connection to that area of knowledge. Most often their expertise comes from past project experience and an accumulation of product knowledge from release to release. Sometimes the connection is less obvious. In Canada, technical writers come to the profession in a variety of ways. Some are ex-programmers, some engineers, some with a psychology or economics background, and some with translation backgrounds. You never know when some little nuance will come in handy.

 

Consideration 8: Work style
Every person has his or her own style, SMEs and writers alike. Consider how individual styles might work together, rather than working at odds. For example, think about pet peeves of the product manager and how those might be aggravated by a writer’s work style or vice versa. If both people share the same passion for attention to detail, personal development, the need for examples, or punctuality, it’s a much more pleasant experience.

 

Consideration 9: Timing
It’s easy to assign writers when they are available or will be shortly because their current projects are winding down. Sometimes, writers aren’t available as soon as you’d prefer. If so, you must delay participation in the earlier part of the project to protect the projects that are coming to an end.

Because technical writers function as user advocates, there are many articles that encourage writers to get involved early in the project to participate in user interface (UI) design. If your organization is lucky enough to have a dedicated team of UI designers, you can postpone some of your involvement and buy some time.

Consideration 10: Localization
Over the last decade, there’s been a steady rise of articles about making your documentation ready for localization. Clearly, more and more products are being localized into several languages. Depending on the company’s release targets, you may need to consider sending documentation to translation earlier than ever before. Working with your localization experts may create many different timing considerations. Your staffing decisions must consider translation deadlines. To finish documentation earlier than you customarily do, you will need to use more writers on a compressed schedule and increase your efforts around delivery dates to localization rather than to the overall project schedule.

 

Consideration 11: Location
Despite modern methods of communication and an international team of professionals, sometimes it helps when someone on the writing team has physical access to the key decision makers. Therefore, it’s preferable if the team leader or lead writer on the project is in the same office as the lead product manager for the release. At last fall’s Best Practices Conference, one of the presenters on outsourcing made the point that the most efficient documentation projects exist when the writers are in close proximity to the key decision makers for the release.

 

Consideration 12: Ongoing monitoring
Once the team is selected and work begins, attention to staffing matters doesn’t end. You should constantly monitor the changing scope, shifting requirements, and unforeseen difficulties that make resource balancing an ongoing concern. The centralized model provides for frequent management team meetings to address additional staffing concerns for any current and upcoming projects. By keeping a close eye on work balance across projects and teams, you can use your centralized model to ensure that people are fairly assigned work loads and that reliable predictions can be made for extra help from contractors.
We use cookies to monitor the traffic on this web site in order to provide the best experience possible. By continuing to use this site you are consenting to this practice. | Close