TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
RE: Questions - Going from Hourly to Per Project Basis
Subject:RE: Questions - Going from Hourly to Per Project Basis From:"Sharon Burton-Hardin" <sharon -at- anthrobytes -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 2 Oct 2003 08:01:05 -0700
On a bill toward project, I watch the time sheets and our schedule very
closely. I know where the writer(s) and/or illustrator(s) should be in the
project, according to the schedule. If we are at week 8 and should be close
to first draft and we are not, then we have a problem.
Since I have been cc-ed on all communications AND talk to my people, I
should know what the problem is. If it is on my side - i.e., the writer is
struggling with the concepts and needs help, I get them that help. It may
cost me, and is not part of the budget and will not be billed to the client,
but I get them the help.
If it is on the client side, then I talk to the client. I make it clear that
we have a problem and we need to fix it or we are not going to be in
budget/on time. I tell them as soon as I see it that there may be a problem.
I hate money surprises and assume clients do as well. I explain that we are
off track and may not be able to deliver what they want. I tell them
specifically what is needed to get this back on track. I avoid blame but I
do identify bottlenecks and suggest ways to cope with that.
Scope creep is the most easy to deal with. When we first define the scope of
the project, we define clearly the scope of the project. That means in
writing, detailing exactly what we are writing about and what the
deliverable is. That may mean literally writing "The user manual will only
describe the features and functions in the product as of <insert date,
probably today>. Any features added after that date that require
documentation are out of scope for this project." Or we create a detailed
outline and that defines the scope. After that outline is approved, anything
outside of that is out of scope. Or both.
I have not been awake that long yet and need more coffee, but these are all
part of managing your projects. I teach this stuff in several of my classes.
It is important to learn, whether you are contract or salary. This is not
rocket science and it makes your life a lot easier if you have control over
your projects.
And, yes, we have done exactly what you describe in #3 below. Some projects
are doomed from the start and nothing can save them. If the client doesn't
care and doesn't help and is inattentive, no amount of begging, pleading,
etc on my part is going to make a difference. Do the best you can and move
on.
-----Original Message-----
From: bounce-techwr-l-71429 -at- lists -dot- raycomm -dot- com
MList -at- chrysalis-its -dot- com
Sent: Thursday, October 02, 2003 7:20 AM
To: TECHWR-L
Subject: RE: Questions - Going from Hourly to Per Project Basis
Sharon Burton-Hardin [mailto:sharon -at- anthrobytes -dot- com] described:
[...]
> A bill towards cost makes clients happy because they know
> that the most the
> project is going to cost is X. We bill hourly towards that. It may be us
and it may be them but we can see the numbers and know
> there is a problem. All the stuff I said about change orders
> stands in these
> projects as well.
OK, if I understand what you just described:
3) when, despite best efforts on your part (well documented)
and mediocre efforts on their part, it turns out that
the billable limit is being reached significantly before
the project finish... you stop working and give them a
sum-up report that shows how they have failed to provide
you the necessaries (with copies of all your heads-up
warnings and pleas to get back on track) and there is no
more money in the contract for you to get to their initially
stated target deliverable... ???
If that's not it, then what is the mechanism by which you
ensure that there will be enough billable hours left on
that ticket, when the customer allows slippage or scope-creep
in their part of the project, such that you still, somehow,
magically come in at/below your contracted cost?
That bit of the incantation would be important to the original
querant if she's to go the bill-to-cost route for the very
first time in her life. :-)
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or view a live demo at: http://www.ehelp.com/techwr-l3
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
