Managing Techpubs projects

Subject: Managing Techpubs projects
From: Peter Collins <peter -dot- collins -at- BIGFOOT -dot- COM>
Date: Sat, 24 Oct 1998 12:53:43 +1000

Mark asked, Q: "I'm wondering whether anyone has any techpubs project
management experience using the RSS trio, and what metrics you used. The
trick is to get as quantified as possible."
A: True. Jane Chew expresses better than I the need for keeping good
past records, spending time with the client getting a feel for which
previous work the new project is like, and the problems the client might
give you in doing so.

How do you put this advice into the RSS context?
1. Scope the job, based on your experience. Answer the questions "Who
are you writing for? What are the major and minor sections that have to be
written? To what level of reader? How big (pages, words - whatever is the
measure of your historical records) will each be? How much research is
required for each (touches on resources - what written knowledge is
available and how well centralised, what must be interviewed for and how
accessible are the subjects?). What graphics does the writer have to
capture, to obtain from the client's 'clip library' or have prepared by an
artist? How good are the reviewers - will they make up their minds
completely on only one editing pass? How many review and edit cycles do you
expect, therefore? Tabulate the results which should end up looking like an
annotated table of contents (TOC).
2. Time contraints are easily dealt with. What's the date now? When
must we be finished? How many working days? The schedule comes later.
3. Resources. To each entry in the Scope (quasi-TOC entry), based on
your past experience, note the days for one person to do each task in
categories such as research, interview, write text, capture screens, gather
graphics, negotiate with artists, present drafts and edit corrections?
Allow, too, for final assembly. Keep separate the figures for each task
category within each TOC entry. A spreadsheet or commercial estimating
package is handy.
The spreadsheet is easier for beginners and small projects. All cell
entries over three days should be further split, either into lower TOC
levels, or additional task categories.
Divide the grand total by the number of working days and add thirty
percent. The answer is the size of the team. Allow a desk, computer or
whatever the duties and skills require, for each. Each spreadsheet cell is
a schedulable task, and each is capable of completion within one week (it
will take a week to complete a three day task).
4. Progress reporting. Assign tasks (to yourself or others) in sensible
sequence, leaving inessentials till last. Everyone prepares weekly
reports - Task(s) for next week (with time expected and problems expected -
with suggested solutions), task(s) for last week (finished or not, time
expected and taken, problems, how long they have added and how they need to
be or were solved).
5. Progress Analysis. Expect three full days output per week. Report on
tasks as complete or not, and extend your spreadsheet (which initially had
'time expected' cells) to include 'actual time' cells, 'difference' cells
and a 'completed' cell. You can also have 'assigned to ' cells. Best if you
can assign each task to only one person - split responsibilities are harder
to administer.
6. Management. Report the progress analysis as tasks completed and in
progress. Percentage of task has no relevance - all tasks in progress will
be complete by next report or you will know the reason why (permit 'poor
estimating' as a problem - if it occurs you must review the scope of the
suspect task(s), rework the estimates and obtain your sponsor's leave to
apply the changes to the project). You should apply a predictor - "we are
on schedule (ahead | behind by X days) - if this continues the project will
be on time (Y days earlier | later than expected) with the current team and
resources. The problem(s) are due to .... The team have done all within
their power to overcome this problem, but we need ... if we are to make up
the time (or worse, "and we need help solving this, as we have not come up
with any solution ourselves, even if we had an unlimited wish-list." Late
in a project adding people will slow things down. Sometimes, you will just
be late, or have to leave low priority sections out. This is the resason
for leaving low priority stuff till last, by the way).

Yes, it is solid work, and nowhere near as much fun as the writing. It
does require the document design to be generally completed before or as
part of the estimating. When do you cost a new house? After the plans are
approved. Could you find a contractor who would take one look at a
photograph of your land and then give you a price and schedule for your new
house? Stop laughing - it's the same thing exactly. Try this metaphore on
your clients, it often helps.
P
========================================================
Peter Collins, VIVID Management Pty Ltd,
26 Bradleys Head Road, MOSMAN 2088, Australia
+61 2 9968 3308, fax +61 2 9968 3026, mobile +61 (0)18 419 571
Management Consultants and Technical Writers
email: peter -dot- collins -at- bigfoot -dot- com ICQ#: 10981283
web pages: http://www.angelfire.com/pe/pcollins/
========================================================


From ??? -at- ??? Sun Jan 00 00:00:00 0000=



Previous by Author: Re: metadiscourse
Next by Author: Other kinds of technical writing
Previous by Thread: Re: Managing Techpubs projects
Next by Thread: HTML behavior


What this post helpful? Share it with friends and colleagues:


Sponsored Ads