Re: Early contracting experiences? Learning the haard way!
I'm wondering if some of you would share your early contracting
experiences? The good news is: I'm working and many are not but *what* a
way to learn. My goodness. I'm contemplating writing a survival manual for
new tech writing contractors. This is my first contract.
Fortunately, modestly does not forbid me mentioning my article on the Techwr-l site about contracting (mainly because I haven't any). You can find it at:
http://www.raycomm.com/techwhirl/employmentarticles/establishingreputation.html
But I think I could also write another article about how not to contract. Among its points:
- Always spell out working conditions and your expectations in a contract or a letter of agreement. It helps prevent problems, and keeps people from cheating you (it sounds like you have already reached this conclusion). Never start work without one, and run from any client who says you don't need one or accuses you of being paranoid.
- Don't be rigid about tools or formats. You can advise or steer clients towards certain tools or formats, but, in the end, you need to accomodate yourself to the client's needs rather than the other way around. If you're too rigid in these areas, you're going to have a lot less work.
- Never work for a flat flee without leaving any room for reopening negotiations because developers miss deadlines, add features, or are uncooperative. Otherwise, you'll end up working for free. An hourly rate combined with regular time sheets and progress reports is fairer for everyone.
- Leave the project in a finished state that reflects well on you. Don't for example, leave a kludge that allowed you to deliver on-time, but could cause maintenance problems later on; use the kludge if you must, but finish it before you go.Make sure that files are properly stored and backed up, and include a readme file about anything that another tech writer might want to know.
- Don't assume that a client knows what you're doing. Educating the client is an essential part of the work - not for altruistic reasons, but for practical ones. Explaining yourself reassures the client, and ensures that the client appreciates what you're doing and what problems you encounter.
- Don't work off-site all the time, especially at the start of the project. You need to establish lines of communication, especially with the developers.
--
Bruce Byfield bbyfield -at- axionet -dot- com 604.421.7177
"We're making you a very special offer of tomorrow
In delicate pastel shades,
Have a jar of instant happiness, a bottle full of glamour,
An amazing value dream that never fades."
- Leon Rosselson, "We Sell Everything"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Want to support TECHWR-L? Get shirts, bags, hats, clocks,
and more from the TECHWR-L Store. All proceeds support TECHWR-L.
http://www.cafepress.com/cp/store/store.aspx?storeid=techwhirl
Check out the new release of RoboDemo, our easy-to-use tutorial software.
Plus, buy RoboHelp Office in August and save $100 with our mail-in rebate.
Get details and download free trial versions at http://www.ehelp.com/techwr-l
---
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.
Previous by Author:
Re: Technical Documentation solutions?
Next by Author:
Re: Early contracting experiences? Learning the haard way! (1 of 2...)
Previous by Thread:
Early contracting experiences? Learning the haard way!
Next by Thread:
Re: Early contracting experiences? Learning the haard way!
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads