View All Tips

On Time and In Budget

How many of us can say that we consistently deliver to these two metrics? And yet, it is possible. TechProse does a significant percentage of our work on a fixed price and schedule basis, with a client guarantee, and to do this successfully we have learned a lot about estimating, budgeting, and managing projects.

For documentation projects (paper-based or online) the first and most essential piece in the puzzle is an accurate scope of the project itself. For documentation projects, the following factors affect the project scope:

• Estimated page count (or screen count for online projects)
• Number of original/existing graphics and number to be created
• Audience level, expectations
• Complexity of subject matter
• Type and availability of source of information (existing documents, interviews, hands-on experience, etc.)
• Development tools
• Reviewers (number, review process, availability)
• Travel or other expenses required (if any)
• Medium of final delivery (online, paper-based, database for single source document, etc.)
• Complexity of format and styles
• Access to Subject Matter Experts (SMEs)

In order to estimate the project, it is essential to fully understand these underlying factors, as well as some intangibles. These might include anything about the environment or the project that can affect the outcome, such as:

• How easy (or difficult) is the group with whom you will be working?
• What are some past successes/failures and why?
• How much of the team is virtual?

The full exploration of all these factors results in a detailed Documentation Plan. This plan becomes the blueprint for the project. It should include:

• A full description of the project
• A detailed table of contents (or topic-list for online help or screen list for an application) including a blurb describing each chapter, estimated page count, and a summary of existing source material
• Summary of methodology to create the deliverables, including time required from SMEs, source materials required, tools to create deliverables, and delivery milestones
• Specified reviewers, review methodology and review timeline
• Samples of final format(s)
• Cost of travel or other development or production expense (special binders, tabs, CDs, etc.)
• Estimated hours/budget to create the deliverables

The plan must include all the assumptions on which you base your estimate. These are assumptions about availability of source material, review cycle timing, participation of SMEs, etc. The client (and this can be an internal or external client), needs to clearly understand their responsibilities in the process. Thus it's your job to spell these out clearly in the Doc Plan. Once you have agreement, both parties sign off on the plan and its underlying assumptions, and then, and only then do you start development.

In our case, we include a time and materials estimate and a fixed-price bid at this point as part of the Doc Plan. When we present the document plan, the client can choose whether they prefer to work on a time-and-materials basis or on a fixed-price basis, which is always a higher estimate, as it includes a margin for our assuming the project's risk. Often, clients who have worked with us before choose the time-and-materials basis. If this is the case, it doesn't free us from our estimate. We still need to stay close to or, hopefully, under our budgeted time and dollar figures. We agree to notify the client if anything occurs during the course of the project that will cause us to exceed the estimate by more than 10%.

The basis for the estimate is a metric we've developed over years of practical experience, for number of hours/page or hours/screen or hours/topic or pages/hour, depending on the medium of the final deliverable, plus extra expenses, which we call out separately. All the above factors affect the metrics we use to determine the hours required for development. The range is huge. For example, the simplest project might be copy-editing and redlining an existing document. For well-written material, we might be able to edit as many as 10 pages an hour. For highly technical, poorly translated material that requires more substantive editing, that figure might drop to four pages an hour. We have created complex cost tables with average hours per task or pages per hour for most tasks involved in designing and delivering information. These are too extensive and complex to provide in this article, and they also represent years of estimating and refining.

However, I can provide some basic metrics that may be of use to you. For an average technical document (a user's guide, or a reference manual), for which information is partially available from existing materials, partially from SME interviews, and partially from research, using a standard template in FrameMaker, with minimal original graphics, we estimate four hours/page from initial outline through two drafts to final production. If production is in Word, we add .25 hours/page for dealing with the inevitable Word formatting problems on long or complex documents. For original graphics, we may estimate separately-for example, a single CAD drawing may take from 2-8 hours, depending on complexity. The hour/page estimate drops back as much as an hour per page if there are multiple screen shots, which take up page real estate without requiring much work (assuming you are using a standard set of tools that makes this process routine).

Online metrics vary enormously depending on the amount of research involved, whether you are working with actual software or vaporware, and the complexity of the development tools. A good way to estimate this is to estimate the content on a per page basis, as if it were hard-copy text, and then add time for research and development complexities. For example, if you are doing a simple Windows Help system, on existing software that is fairly robust, you might be able to use the same metrics as if you were formatting the text on a page-the process of developing the help system shouldn't be more complex than designing the manual. If you are designing a complex online information system, however, that includes metadata and topic maps, you will have to allow significant time for analyzing and structuring the information in addition to developing the content. If you are documenting vaporware, include an assumption limiting the allowable amount of change to the software while you are in development. Anything beyond this amount requires a change order.

Be sure to include project management hours in your Doc Plan. Remember, the more complex and/or larger the project, the more project management hours are required. This may run from a minimum of 10% management time for a simple editing project to 25% management time for a complex project with many players and new tools and processes. This time covers planning, tracking, meetings, resolving questions, dealing with the unexpected, and ultimate responsibility for a quality product.

So how do you manage to this plan? The key to this is to track the estimated hours for each piece of the project against the actual hours. This requires weekly monitoring. Breaking tasks into weekly chunks, with hours assigned for each individual, allows you to do a check each week of budget to actual time spent. This helps you identify any problems early, and keeps you from getting very far out of scope. That's part of what all those project management hours are for. For simple projects, this is a simple task. We have spent over a year working out a time management system that allows us to review projects based on individual tasks and hours. It simplifies the process, but still requires detailed budgeting up front; without that, no monitoring can occur.

If you do notice discrepancies, you need to analyze the cause. This is where the detail of your Doc Plan is essential. For example, perhaps you made the assumption that 90% of the source material for Chapter One would be derived from an earlier release of the manual. When you start writing, you find that only 40% of this material is still relevant. Because this was a stated assumption in your plan that was signed off by the client, the discrepancy becomes the basis for a change order. We use change orders for any change in underlying assumptions or requested scope of the deliverable that affect the budgeted hours and/or cost. We use a simple form that describes the change and details its impact on the project. We get signoff on the change order before we proceed.

In the case where we have simply incorrectly estimated the scope of a deliverable, we have to assume responsibility, and dedicate the extra hours for completion. This is the risk we assume when we do fixed price estimates, and it's part of the reason why fixed bids are always higher than time and materials.

In addition to tracking the progress of the deliverables every week for our internal team use, we do weekly (or in some cases bi-weekly or monthly) status reports to the client. This is a good practice whether your client is an internal manager or an external one. These reports are usually less than a page, and the first item is "Delayed Tasks and Other Critical Issues."  We use this to note any delays or potential problems as soon as we are aware of them, along with suggested solutions. This supports our "no surprises"  guarantee to the client, and lets us bring up any potential problems before they impact the project, or notify the client of any unavoidable delay as soon as we know about it.

Good communication throughout the process is essential to bringing in projects on time and within budget. With teamwork and creativity, it's possible to resolve at least 80% of the problems that can occur without impacting the final deliverable. Poor communication can scuttle the best-managed project. Every project is really a partnership between the client and the service provider. For example, if we are working offsite on the project, we have a weekly call to the client to discuss progress and any open issues. Doing everything you can along the way to provide a truly client-friendly attitude goes a long way to smoothing the inevitable bumps.

As part of our process, we also follow this mantra: under promise, over deliver. Almost all our delivery dates are scheduled for a Monday. Internally, our date is the prior Thursday. This allows time for internal review and at least one work day and if necessary, weekend time, to deal with unforeseen issues.

In summary, on-time, in-budget delivery is based on three basic principles:

• A fully researched, detailed plan
• Ongoing tracking and communication
• A customer service orientation throughout

Following these principles is the basis for successful delivery.