Improving Your Team’s Political Clout

CIDM

April 2006


Improving Your Team’s Political Clout


CIDMIconNewsletter Pedro Meza, nSight, Inc.

Imagine this: we’re in the elevator when the CEO, two product managers, and the marketing researcher get in. They nod politely to us and continue their chat about a customer-retention survey, alluding to a new ad campaign aimed at capturing more market share. When we leave the elevator, the documentation manager remarks, “I need to be part of that kind of conversation, part of the business mainstream. Documentation has to get out of its isolated role.”

This is an easy scenario to visualize, isn’t it? In my experience, documentation typically has no direct relationship to earnings or business strategy. And, despite the fact that the guides and help files are part of the product package, when it comes to giving bonuses for higher-than-expected earnings, the corporate culture says documentation doesn’t influence the sale and is therefore not part of the team working toward revenue targets and bonuses.

As discussed at the recent Best Practices conference, you can increase your political clout and sustain the viability of your team by solving these problems.

Changing the Culture, Changing Documentation

Upper management’s perception of documentation’s role changes when the team lead speaks management’s language and all team members understand the business ramifications of their actions.

I recently worked with a documentation team to create a database-driven tracking and reporting application that has changed the way their documentation group is perceived. The team supports a wide range of products in a multinational computer company.

The writers, editors, and vendors enter data about their work—budgets, schedules, milestone achievements—into the database. By tracking their own work, the team members have learned the business operations. For example, they see firsthand what happens when a schedule slips—how additional resources may be required to meet the deadline, which in turn affects the budget. The team members are connected to the mainstream of work on new products.

The documentation managers now have all of the data they need. They have a complete overview of every aspect of their team’s work and can quickly slice data into reports for themselves and various levels of management.

Having solid data from which to speak about their group and its work has also given the documentation managers greater political clout in peer meetings about the programs and decisions that impact their budget.

The tracking and reporting project was honored to receive The Center for Information-Development Management’s 2005 Rare Bird Award.

Recording Details, Building Reports

Prior to my being called in to build the tracking application, the documentation managers had already come to the conclusion that they had to change their group’s working model to

  • make the documentation strategically relevant to the company
  • improve quality in response to customers’ needs
  • balance workloads

To meet these goals, the managers had initiated an extensive single-sourcing project.

But despite the advantages and streamlining that single sourcing would bring, the managers still needed a consistent, easy-to-use method for tracking project data and developing relevant reports for stakeholders. To manage effectively, they needed an overview of various aspects of each project and a more effective way to communicate with upper management.

We determined that the solution was a modular tracking and reporting application that interfaced with a database chock full of relevant documentation information. No such animal existed, so we created one.

Project data had always been kept on separate and so mewhat redundant forms, and it took hours to compile data into reports. With the modules, project data can now be viewed from four key perspectives and used to create reports in minutes. Table 1 lists the change from forms to modules.

From dozens of static forms To four dynapic modules
  • Project part numbering
  • Documentation plans
  • Localization schedules and forecasts
  • Art
  • Production
  • Budgets
  • Vendor administration
  • Project
  • Localization
  • Budget
  • Single Sourcing

Table 1. From Forms to Modules

Table 2 describes the modules, the type of data each contains, and the reports generated within each module.

Module Data components Report types
Project Staff and vendor assignments, part numbers, document plans, and revistins, schedules, illustrations, localization requirements, timesheets, production requirements, project team, subject matter experts Project costs/status
Staff costs
Scope of work
Milestones
Division reports
Localization Forecast, budget, actual costs, billing, accruals, process milestones Localization cost per project
Language costs/status
Budget Vendor process, program review, purchase orders, invoices, accruals, rollup reports, operating expenses Comprehensive project costs
Budget versus actual costs
Forecasts
Bids submitted
Purchase orders
Invoices
Impacts of scope creep and slippage
Vendor versus in-house staff costs
Project analysis data
Single Sourcing XML conversion, content management system load status, content sharing, metrics on reuse savings Progress reports on XML conversion
Forecasting writer and localization costs
Percentage of shared content
CMS status
Executive summary report

Table 2. Module Componenets and Reports

The application gives the documentation managers oversight and control of key business areas and the ability to actually manage their group’s complex activities. The knowledge provided by the application puts them on a par with product and marketing managers in other parts of the business. Put another way, documentation managers can now take part in that elevator conversation.

Solution_Section -- Meza

Figure 1. The Tracking Solution

Figure 1 illustrates the flow of some of the data types and reports managed by the tracking and reporting application. The data-driven application

      • enables our client company’s documentation managers to make decisions based on facts
      • prevents details from getting lost
      • makes reporting a simple task instead of a day-long project

Getting There From Here

Creation of the customized tracking and reporting tool had two major phases: requirements gathering and design.

Requirements gathering
We began by mapping the business and project requirements. This analysis gave us a concrete picture of what the application had to be able to do and what the database should contain.

The final product had to be intuitive so that training would be minimal and team members would follow their normal workflow within the application.

Achieving the combination of an intuitive user interface with rich functionality required close collaboration with users. We listed the steps of each work process and associated each step with key data points to be entered into the database. For example, project tracking includes data such as

      • number of projects in any given timeframe
      • size of project (small, medium, large)
      • cost per project, cost per project by division
      • budgeted versus actual cost
      • scope increases, schedule slips

To keep communication clear, I illustrated proposed screens with a series of storyboards and static prototypes. These examples enabled users to correct workflow and data-point errors before programming began.

Once we decided what functionality the application had to have, the managers prioritized the requirements. After documenting the rationale for each requirement, the actual design and programming began.

Design process
Developing the application was treated like any other project: we started with a realistic project scope and timeline and put project-success measurement parameters in place.

I used an iterative, component-based process to design the application. The highest priority functions were developed first.

Close communication with users and management was critical during the development of the application because it was being customized for their use. I created static screenshots of the interface for soliciting rapid feedback.

Usability testing was conducted according to staff role. The testers included writers, project leads, administrators, production staff, and localization personnel. This testing ensured the application’s usability for all team members.

Using the Solution

The client company’s writers, managers, and vendors—each of whom enters his or her own data into the tracking tool—are very pleased with the time savings.

The documentation managers have seen efficiency gains in these areas:

      • Reporting on budgeted versus actual spending to upper management
      • Calculating cost by project, division, quarter, or year
      • Contrasting vendor and permanent employee costs
      • Balancing workload between in-house staff and outsourcing
      • Determining comprehensive project costs relative to the type of program team: permanent, vendor, or localization
      • Analyzing competitive bids
      • Creating purchase order and invoice reports for division and financial managers
      • Accurately forecasting costs
      • Showing the impact of scope creep and schedule slips

In summary, the new data-driven tracking and reporting software has enabled the documentation managers to

      • ensure the viability of their documentation team through the strong business acumen gained by tracking and analyzing their business group’s data
      • bring greater order and efficiency to their complex daily operations because of the consistent and predictable tracking and reporting available to the entire team
      • teach their team about the variables that affect operational efficiency

Creating a Solution For Your Team

I encourage you to consider developing a database-driven application to track your team’s work. The application I’ve described here has been highly effective for our client on several levels. If a software application is out of the question right now, I strongly recommend that you go through the requirements gathering exercise. Map out the processes and workflows that your team uses, and note the key data points. Capture that data, and use it to your advantage.

Your career, your team, and your customers will benefit from your efforts to heighten your business acumen and create documentation that is strategic to improving company earnings.

And then the next time you get into the elevator with the CEO, two product managers, and the marketing researcher, you’ll be able to chat with them about the customer-retention strategy to which documentation is contributing. CIDMIconNewsletter

About the Author

Pedro Meza

Pedro Meza
Senior Technical Consultant
nSight, Inc.
pedromeza@aol.com

Pedro Meza is a Senior Technical Consultant for nSight, Inc., specializing in the areas of system architecture, design, and data solutions. Over the past four years, Pedro has worked on HP engagements focusing on solutions involving document analysis and DTD design, application development, stylesheet design, and legacy conversion along with knowledge transfer and implementation support to other HP team members.  Prior to his work at HP, Pedro spent eight years consulting with fortune 100 companies in creating and designing specialized technical business solutions. Pedro holds a BS in Computer Engineering with a specialty in Artificial Intelligence from the University of Central Florida.

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