Corrigo Volume 8 Number 4 December 2008

Managing the Chaos of Freelancing by Taking Control of Your Schedule Geoff Hart Previously published as: Hart, G. 2008. Managing the chaos of freelancing by taking control of your schedule. http://www.stcsig.org/cic/pages/links.htm#Consult

Volume 8, Number 4, December 2008 Managing the Chaos of Freelancing by Taking Control of Your Schedule Page 1

Entering the Field of Technical Editing: Many Approaches Page 4

Votes are in

As freelancers, we all face the problem of feast or famine: sometimes we’re overwhelmed with work, and can hardly find time to think, let alone keep up with our other responsibilities, but other times dust gathers on our computers while we wait for new work to arrive. Clearly, marketing our services and finding new clients is important to avoid the “famine” part of the freelance lifestyle, but what do you do when too much work is arriving? As a freelance editor, my work primarily involves a large number of small jobs rather than a small number of large projects over the course of the year. In this article, I’ll use this situation, which many other freelancers are familiar with, to provide some suggestions on how to manage your work schedule more effectively and attain a slightly more sane work life. The advice I’ll provide is equally suitable for freelancers who work on a few large projects, since even the largest projects can be broken down into smaller and more manageable chunks. (Indeed, the really big projects can’t be managed any other way.) The same strategies apply, but with an obvious modification: you’ll need to budget time at the end for cleaning up and finalizing the whole project.

Page 5

Scholarship Winner: Lessons Learned as a Technical Editor Page 6

There’s no foolproof solution to the chaos of freelancing, since life sometimes happens all at once and there’s nothing whatsoever we can do about it. But there are several tricks that let us juggle life and work considerably better than if we give up and simply accept whatever life throws at us. One of the first and most powerful solutions involves gaining more control over our schedules. Doing so requires only four simple steps: •

Learn how much work you can complete within a normal-length day.

•

Use some form of calendar to reserve dates for anticipated work and your known commitments.

•

Always build some slack time into your schedule.

•

Develop a support system.

Continued on Next Page

Managing the Chaos, Continued from Previous Page

Learn how much work you can complete per day Tracking your productivity is important, because it’s the only way you’ll ever be able to know how long a job will take and thus, how many days you’ll need to reserve for a given job. This knowledge is what lets you schedule your work. Each job is at least slightly different from the work you’ve done previously, but over time, you’ll gradually get a feel for your range of productivities, including both your long-term average and the worst-case scenario. A conservative approach to scheduling your work relies on using the worst-case productivity, since that way you can be reasonably confident you’ll finish ahead of schedule. Basing your schedule on your average productivity may be more realistic in the long run, but it also means that you’ll end up working under significant deadline pressure for half of your jobs and severe deadline pressure for a significant number of jobs. If you track productivity separately for each client or each type of product, you can further refine your estimates. Best of all, if you get a chance to examine the whole job (e.g., the full text of a manuscript to be edited or a carefully defined functional specification for software) before you are asked to provide a quotation, you can base your estimate on the actual work you’ll be doing and come up with a much better estimate for that specific job. However, there’s a common gotcha to be aware of: early chapters in a book that you’ll be editing or the initial product features you’ll be documenting in a help system tend to have been developed early in the project, while the author or developer was still well-rested, excited by the project, and not facing insane deadlines. Later parts of the job often take longer than early parts because of creative fatigue, loss of interest, or simple lack of time to do the job right. So try to examine the whole project, not just one or two initial components, before you create an estimate. The first step to gaining control of your work life is to learn the trick of estimating how long a job is going to take each time a client contacts you with more work. For suggestions on simple ways to track your productivity, I’ve provided two resources on my Web site: •

•

is a free download, and provides details of a simple way to track your productivity. The chapter and the book both contain other useful information on how to manage the freelance life. Chapter 3 of my book on onscreen editing

For a more detailed discussion of how to budget, read Estimating project times and costs without losing your shirt—or your sanity.

Use some form of calendar to reserve dates Once you know how long a job will take, the next step is to schedule the work. Doing so requires some form of calendar, whether you implement it on paper or in software. (Different strokes for different folks!) Basically, your goal is to recognize that there are only so many working hours in a week, and that all your work must be fitted into those available time slots. Once a slot is full, it’s no longer available for other work, and finding a way to account for this in your schedule is the key to regulating your workflow better. Continued on Next Page

Volume 8, Number 4, December 2008 © 2008 Society for Technical Communication (STC). All rights reserved. Corrigo is the official newsletter of the STC Technical Editing SIG.

Reprints Reprinting the material in Corrigo is permissible with proper attribution (source, including volume, number, and date of issue as well as the name of the author). Send a copy of the publication in which Corrigo material was reprinted to the author and the managing editor.

Submissions We invite writers to submit articles to be considered for this publication. By submitting an article, you implicitly grant a license to this newsletter to run the article and also for other STC publications to reprint it without permission. Email articles to the managing editor in a format that is compatible with Word 2002. Copyright is held by the writer. In your cover letter, identify if this article has been printed elsewhere of if it has been submitted for consideration to other publications.

Newsletter Staff Managing Editor Michelle Corbin [email protected] Newsletter Editors Anitha Abraham [email protected] Henry Wicko [email protected] Copy Editors Alysoun Taylor [email protected] Danica Rhoades [email protected] Dave Wright [email protected] Jennifer Smith [email protected] Lisa Adair [email protected] Sharon Powell [email protected] Graphic Designer Henry Wicko [email protected]

Managing the Chaos, Continued from Previous Page

STC Technical Editing SIG Information The Technical Editing SIG focuses on issues related to technical editing. Our goal is to provide editing resources and leadership to STC members who want to learn more about technical editing and its important contributions to our profession. The Technical Editing SIG maintains a Web site, which includes a blog for posting news and information:

http://www.stc-techedit.org/ To become a member of the Technical Editing SIG, see the information on our Web site:

http://www.stctechedit.org/about/join-thetechnical-editing-sig/ Co-managers Meredith Kinder [email protected] Pat Moell [email protected]

In the previous step, I asked you to determine how much time a job will take. Now your goal is to look at your calendar and find the first day when you can begin that work. Mark the day (or days) on your calendar as “Reserved for [name of job]” so you won’t double-book those days for other work. One of the biggest mistakes freelancers make is failing to reserve dates for future work on those rare and happy occasions when a client gives us advance warning about when a job will arrive. If you have clients that predictably send you work such as annual reports, quarterly newsletters, or annual funding proposals at specific times of year, reserve those days each time you start marking up your calendar for a new year, and add a note in your reminders program a month before these periods so you can contact your client and confirm whether the work will arrive on schedule. Don’t forget to include down-time and other non-work time commitments that will reduce the number of hours available for work. If you know you’ll be away or unavailable for part of a day, mark that part of the calendar as unavailable. Include doctor appointments, family gatherings, meetings, or anything else that will prevent you from working. Don’t neglect the obvious: for example, my first calendars were clearly marked “no work today, idiot!” on weekends and holidays because early in my freelance career, I was constantly working through the weekend and wondering why. As it happened, I’d simply neglected to block in those days as unavailable for work. (Sometimes I’m thick as a brick.)

Immediate Past Manager Michelle Corbin [email protected] Membership Manager: Kelly Graham [email protected] Treasurer Jeffrey Japp [email protected] Secretary: Virginia Janzig [email protected]

Reserve all your known commitments (e.g., an hour a day for exercise or watching your favorite TV show) before you start allocating your time for the coming month. You won’t always be able to honor every commitment, but you’ve got a much better chance of success if you’re at least willing to try to give your real life equal priority to your work life. For longer allocations of time, such as vacations, add a note in your reminders program to notify all your main clients well in advance so they can plan around your schedule. (Many won’t bother, but each one that does is one less client likely to cause problems around that time.) One useful, though mildly unethical, approach involves telling clients you’re leaving a couple days earlier than you really are leaving. This way, if any emergencies arrive at the last minute, you still have time to handle them—or to find someone else who can do so. (More on the latter topic in the penultimate section of this article.) Paper works adequately for calendars, but software solutions provide far more flexibility when it comes to rearranging your schedule. What software should you use? Options range from behemoths such as Microsoft Project to smaller and nimbler tools such as the task and calendar tools built into Microsoft’s Outlook or Apple’s iCal. Everyone eventually finds an approach that suits their unique needs, and the key is to invest some time experimenting until you find an approach that works well for you. For example, I’ve found an approach that, though kludgy and inelegant, works better for me than more complex and powerful solutions: I use iCal for reminders and small notes, but I use nested folders on my computer’s desktop to organize my work life. You can see what this approach looks like in Figure 1. The key concept behind my approach is that I use a single “Work” folder to gather all my work together in one Continued on Page 7

Entering the Field of Technical Editing: Many Approaches A summary of a panel discussion at the Bay Area Editors’ Forum, by Micah Standley Panelists: Patricia Egan, Robyn Brode Orsini, and Lyn Smirnov Forum date: Wednesday, September 24, 2008 Forum organizers: Patricia Egan and Karen Asbelle Our September meeting focused on the educational opportunities available to those who want to enter technical editing. Three distinguished technical editors led the discussion: Patricia Egan, who teaches in the Technical Communication program at UC Berkeley Extension; Robyn Brode Orsini, who teaches Professional Editing in the SF State Technical and Professional Writing program; and Lyn Smirnov, technical writing instructor at De Anza College in Cupertino. One of the main functions of an editor is to serve as “another pair of eyes”– evaluating and refining an author’s work to make it as clear as possible. In technical communication, an editor’s role is often critical to a project’s success. One classic example is Edward Tufte’s analysis of the O-ring charts that NASA engineers used before the space shuttle Challenger’s fateful launch, as shown in his book Visual Explanations. The data in the charts were so poorly presented graphically that it’s easy to see how the engineers glossed over the information. If the data had been shown in a more easily comprehensible way, the Challenger disaster might have been avoided. So, what’s the difference between technical editing and general editing? It comes down to subject matter. When asked to name some industries where technical editing is used, the panelists listed these examples: software and computers, medical, manufacturing, finance, engineering, science, bio-tech, legal, government, and gaming. According to Orsini, the need for technical editors in the fields of “green” technology and sustainable energy sources is definitely on the rise: “We’re at a major tipping point in that industry, and the need for technical editors will be huge.” The panel agreed that the first thing you need when entering technical

editing is interest in the subject matter. “You might have a degree in it, you might have a professional background in it, or you may have interest in it and you want to just go in and learn, but you have to decide what interests you and go after it,” said Orsini. What if you have an interest in a particular field, but no experience? Get creative. One audience member expressed an interest in the biotech field but said that all of her experience was in software development. Smirnov immediately suggested applying the audience member’s background to the biotech field by seeking out those companies that develop medical software. “Reach out to them and see if you can come in through the high-tech side; then you can absorb all the buzzwords by osmosis and slide in. You may be narrowing your choices initially, but you would be leveraging your strengths to get your foot in the door.” Egan offered a handout discussing how technical editors add value to content and contribute to quality assurance as a compelling case for including technical editors in the publication process from the earliest stages of development, as described by Corbin, Moell, and Boyd. (Corbin, M., Moell, P., and Boyd, M. (2002, August). Technical editing as quality assurance: Adding value to content. Technical Communication, 49(3), 286-300.) Even if an editor is not a subject matter expert in a particular field, he or she can certainly bring significant value to a project. Egan recounted a project early in her career when she was asked to edit a peer-reviewed article written by a team of researchers from two different companies with four different native languages represented–and the article was being published in the Netherlands. “I was very clear and told them, ‘I can’t validate your content; I don’t have that background. What I can do is make sure that your work conforms to a style guide and ensure that there are no inconsistencies in the article.’” Continued on Next Page

Entering the Field, Continued from Previous Page

The Bay Area has long been a technology hub in America; many employment opportunities exist for technical editors with an interest in a specific industry and the necessary skills. According to Egan, one of those necessary skills is successfully passing an editing test. When she first moved here, Egan was sent by a recruiter to a potential employer who administered an editing test that lasted an entire day. A grueling experience to be sure, but Egan passed and got the assignment. One of the first handouts she gives her students is an article Geoffrey J.S. Hart wrote for Intercom, the magazine of the Society for Technical Communication. The article explains what to expect from such a test and some strategies for successfully completing it. (Hart, G. J. S. (2003, April). Editing tests for writers. Intercom, 12-15.) As educators in technical editing, the panelists also reviewed the specific aspects of their respective programs and the educational opportunities available to those who may want to enter the field. Each program takes a comprehensive approach by teaching the general skills necessary–grammar and syntax review, editorial querying, creating style sheets, creating and developing the author-

Votes are in by Pat Moell and Meredith Kinder, Co-Managers, STC Technical Editing SIG

The votes are in! Congratulations to the STC Technical Editing SIG officers for 2009! •

• • •

Vanessa Wilburn, 2009 - 2010 Co-Manager (Meredith Kinder will continue in 2009 as second term co-manager) Wayne Kliman, Treasurer Virginia Janzig, Secretary B. S. Gururaj, Membership Manager

In addition to these elected offices, we also have a great team of support volunteers working to make the SIG a success. Thank you to everyone who has committed to take a lead role next year. 

editor relationship–and then applying those skills to realworld situations in technical communication. In Smirnov’s experience, “A technical editor needs to be a jack-of-all-trades. You need to be able to go in and do the ‘deep dives’ as well as the copyedits.” Smirnov said that most of her students are working professionals who want to branch out into new aspects of their field and develop new skill sets to give themselves a competitive advantage. Orsini summed it up this way: “There are many approaches to entering the field of technical editing. When I started editing corporate annual reports, I didn’t know what I was doing. But I was fascinated by what was being presented, so I sat down, analyzed the information, and took it one step at a time.” 

Scholarship Winner: Lessons Learned as a Technical Editor by Daniel Beck Editor’s Note: This year, the STC Technical Editing SIG offered scholarships to one undergraduate and one graduate student in technical communication. One part of the scholarship application was to describe a project or research that the applicant was involved in. We asked the scholarship winners to write a newsletter article summarizing their project or research. This is the second of such articles from our undergraduate scholarship winner.

This past spring, I took the last in a series of technical writing courses offered here at the University of Central Florida (UCF), creatively titled “Technical Documentation.” Unlike the two previous courses in the series, I was set loose with minimal supervision. My objective for the semester was to find a client, propose a project, and complete the work of the project entirely on my own. The instructor in the course would only review my work and provide substantial feedback once, at the middle of the semester. I felt that the class was a terrific opportunity to try something I hadn’t done before. I had missed some opportunities to work as an editor in my technical communication coursework. With this course, I had an opportunity to take advantage of and get some much-needed experience working with the results of other writers’ work. My part-time employer, the UCF’s Course Development and Web Services, had just the project for me. They had some documentation that was in desperate need of revision. UCF was transitioning from one Web e-learning platform to another. It was a somewhat painful process that I’m sure many people are familiar with — after spending years using one tool, thousands of users were ushered on to another. The difficulty of this change was exacerbated by the lack of well-maintained documentation. The documentation provided by the software vendor had not been updated in years; it only somewhat reflected the software in use on UCF’s servers. Furthermore, the documentation was internally inconsistent. Supplements to the documentation produced by Course Development and Web Services were visually and textually inconsistent with the vendor-supplied documentation.

Naturally, I chose to overextend myself that semester by trying to single-handedly solve all of these problems. It was a long, tiring process of reviewing hundreds of pages of instructions and attempting to coordinate their strengths and mitigate their weaknesses. Pages and pages had to be entirely rewritten; dozens of screenshots had to be recreated to match the software in use. And throughout it all, the details of the project were left up to me. Of course, I learned some interesting practical lessons. For instance, I “discovered”–probably in much the same way that Columbus “discovered” the Americas–a cheap trick for testing documentation out on an audience. In the day-today activities at Course Development and Web Services, I often responded to support requests via email from faculty members. Frequently I used portions of my documentation revision project as the basis for responses to email questions. It was easy, cheap testing. Instead of writing up one-off instructions for the faculty, I would send them portions of the documentation. I got unambiguous feedback without ever having to convince any faculty members to complete a survey or an interview: either the documentation resolved the issue or didn’t. I also learned that my weakness for playing with flashy new technology might someday be a problem for me. I committed myself early on in the project to use a new project management tool that Course Development and Web Services had purchased. It was fun to learn, but I think I spent more time figuring out the tool than actually using it to get the job done. As it turns out, one person doesn’t need a project management tool, one person just needs a to-do list. While working alone, I found that the project management software was overkill for the amount of tracking and reporting I needed to do. I could imagine such a tool being useful for a team of writers, but for me it was just a distraction. But the most important lessons I learned had to do with what it actually means to be a technical writer or editor. As the semester dragged on, I began to appreciate what other technical writers mean when they refer to the “lone technical writer,” a phrase I had heard often, but didn’t fully understand, despite many STC chapter meetings and two Continued on Page 10

Managing the Chaos, Continued from Page 3

place, and use Macintosh aliases (”shortcuts” in Windows) that point to the actual folders that hold the work for each project. Adding the date at the start of each folder name lets me schedule the work. Figure 1. Using nested folders to organize your work schedule.

one with an alias to the real folder once the files are on my hard disk. Folders that contain the word “alias” (the Macintosh version of Windows shortcuts) point to the actual working directory, thereby providing direct access to that directory without having to click my way several levels deep into my hard drive. This is important for me because I have clients in dozens of countries, and several large clients in two countries, requiring a strongly nested folder hierarchy on my hard drive. Note that I’ve also used a yellow-highlighted folder that does nothing but separate ongoing tasks (such as the newsletter that I publish for STC’s Scientific Communication SIG and a list of presentations I’m currently working on) from the actual paying work. Because most operating systems sort names beginning with a hyphen before names beginning with letters, adding a hyphen to the names moves these folders to the top of the list. Other useful tricks such as adding a number before each name lets you take advantage of the operating system’s default ordering rules.

Each month, I create a new series of named folders to reserve non-work days for weekends, holidays, and other times I won’t be available for work. For a weekend, a typical folder might be named “September 12-14 no work”. (Note that I’ve also marked most Fridays as unavailable for work. We’ll come back to that point in the next section.) Similarly, the screenshot shows a planned absence in the form of a working vacation during which I’ll be giving a workshop to a local STC chapter and then taking a few days of vacation: “October 12-20 no work (Phoenix trip)”. Folders representing dates when I’m not available for work are highlighted in red to distinguish them from folders representing work. In Figure 1, you’ll see two different types of work folder: Folders such as “September 8–808078 Harada alias” represent a project I’ve already received and that is ready for editing when time permits, but no later than that date, whereas the folder “September 9–808061 Harashima (long review)” is a placeholder for a job that hasn’t yet arrived but that is due to arrive on the specified date. I’ll replace that

The resulting display provides an “at a glance” list of the work that needs to be done, and when it needs to be completed. Using a consistent naming scheme lets me use the built-in display options on my computer to place the work in correct order, but there’s an obvious problem: although the order of the folders is correct within any given month, you can see that my absence in October displays above (before) the work that must be completed in September. I could solve this problem by working in icon view instead of text view, since that would let me manually drag the folders into the correct order rather than being constrained by the operating system’s sorting preferences. I’ve found that I prefer the text view, and can live with the tradeoffs. When I finish a job, I simply delete the alias pointing towards it, which has no effect on the actual folder that contains the project, and move on to the next project on the list. When new work arrives, I can see at a glance when I’ll be able to fit it into my schedule, and I can immediately propose that deadline to the client. If urgent work arrives, with a tight deadline, I can see (based on the dates in the work folder) which projects can be pushed back a day or two. For example, the folder “September 9 (due 18) 808062 Wada alias” tells me that I should try to get the job done by the 9th, but that I can let it slip by up to 9 days if more Continued on Next Page

Managing the Chaos, Continued from Previous Page

urgent work arrives unexpectedly. In the next two sections, I’ll discuss how to handle such surprises. Always build some slack time into the schedule When a client contacts you to discuss new work, learn to always ask them two questions: • •

When would you like to receive this job? When do you really need to receive it?

Most of the time, there’s a significant gap between the two. When you record the job on your calendar, carefully record both dates. If unexpected or more urgent work arrives, knowing the true deadline provides an opportunity to juggle your schedule (i.e., push back the date on a less-urgent job) so you can fit in the new work. This approach is a specific example of a more general principle: always build in a day or two per week of empty time that you can use when a job takes longer than expected or something urgent arrives. The more flexible the schedules of your clients and the more predictable your workflow, the less empty space you’ll need to set aside. Over time, you’ll gradually get a feel for how much work is likely to arrive in a typical week. For example, my major client typically sends me two to three jobs per week, and more than that during busy periods. Knowing this, I no longer accept more than two or three jobs from other clients in any given week because doing so might leave me unavailable to that primary client. If my major client is less busy than usual, it’s easy for me to complete other work earlier than originally scheduled or accept work I’d otherwise have to decline, thus giving my other clients a pleasant surprise. Of course, whether to do work earlier than scheduled is a bit of a judgment call. If you’re as busy as I am, you’ll find that it’s a wise choice, because you never know for sure what will arrive on your desk next week, and freeing up time now by finishing next week’s work early makes it less likely that you’ll have to turn away work or pull an all-nighter. On the other hand, sometimes you simply need a day off to decompress, and the risk of longer work days next week isn’t the worst alternative.

As I noted in the previous section, I’ve implemented my own advice by marking my Fridays as unavailable for work. This serves two purposes. First, I’m growing sufficiently old and prosperous that free time is becoming more valuable to me than a few extra dollars. During slow periods, this means that I can often take a 3-day weekend and use the extra time to work on my own writing. Second, this automatically gives me one day per week of flex time that I can allocate to rush jobs or unexpectedly long jobs that require more time than I budgeted. I still often end up working most Fridays, particularly when I know that I’ll be leaving for a long trip and need to store away a bit of extra money to cover my lack of earnings during that period, but asking clients when they really need a job returned often lets me defer a job until the following week. Then, if I do need to work on a Friday, or if I know something big is coming the following week, I use the extra hours on Friday to avoid a serious work crunch the following week. Develop a support system All of this is great in theory, but in practice, sometimes everything hits the fan simultaneously and there’s simply too much work for any one mortal to handle. Pulling an all-nighter or working a 60hour week is sometimes possible, but it’s not a good long-term survival strategy, even if you’re young enough to survive what programmers glibly refer to as a “death march”. (I no longer am.) Yet there’s always the fear that if you turn away a client because you’re too busy, they’ll never come back to you. Fortunately, there’s a reasonably effective solution. That solution involves finding one or more colleagues you can trust to do work that’s up to your personal standards and who also won’t steal your clients. Yes, such people exist; I’m one of them. In those periods when you have some downtime, spend some time finding two or more colleagues who are willing to do this kind of work and who you can trust. Discuss the possibility of covering for each other during rush periods, with an explicit but informal verbal agreement that you won’t steal each other’s clients. (You can also make this a formal legal contract if you want more reassurance, but starting your relationship by making it clear that you don’t trust your colleague without a signed contract is not an auspicious beginning.) You may still lose an occasional client this way, but if you choose wisely, an ethical colleague won’t steal your clients and everyone will sleep a bit easier knowing they have someone to cover for Continued on Next Page

Managing the Chaos, Continued from Previous Page

them. Better still, an insanely busy period for one of your colleagues may coincide with a slow period for you. If you hit a dry spell, write to these colleagues and let them know. They may be happy to send you some of their work. I work this way and refer potential clients to a few colleagues purely as a friendly gesture: I don’t charge them any money for this service, and I don’t count up their debts to me. I’ve been blessed with more than enough work, and have several colleagues who aren’t so fortunate and who could use a few extra billable hours. The benefit of this approach to me is that I’m not responsible for the quality of their work, and I make this quite clear to the clients when I give them the referral: “Here’s someone who can handle this work for you. I will not be supervising their work, but they’ve been doing this work long enough that you can feel confident in their expertise.” If you’re more entrepreneurial than I am, you can also subcontract such jobs, and then do quality control on the subcontractor’s work to ensure that it’s up to your standards. Personally, I find this way too much overhead, but it might be a very good solution for you, particularly if you’re still building your client list and need a bit of extra income. Parting thoughts I started this article by noting that this approach can be modified to cover a range of other situations. For example, what can you do if you receive offers for two large projects that must be worked on simultaneously? Typical examples might be when two publishers ask you to edit large textbooks simultaneously, or when a software developer asks you to document two large modules of a larger program at the same time. Although it’s clearly more efficient to focus on one project at a time, it’s often appropriate to budget half your work week for each project, and switch horses every Wednesday at noon. Each job will take roughly twice as long as if you worked on only one project at a time, but if you designed your initial scheduling estimates to account for this situation when you accepted the work, you’ll often still be able to complete both jobs on schedule. This is particularly true for software documentation early in the development process, when many parts of the software are being delayed or constantly revised, and you may not have enough work to devote a full week to the product. Things become dicier towards the end of the job, as the software begins to stabilize, more features are complete, and deadlines tighten, but it’s unusual for this to happen at exactly the same time for projects from different clients. More often, different parts of each project progress at

different rates, and a slow period for one project will overlap a work crunch for the other project; in that case, you can adjust your schedule to fit in more of the crunch project and less of the slower project. This can also happen with large books, particularly when multiple authors are contributing chapters over a period of several months. For this approach to work, you need to discover factors that might impose the same deadline or a non-negotiable deadline on two large projects. In software documentation, this might happen when two programs must be released at the same trade fair, such as INTEROP or in time for the annual tax preparation season. For books, you might need to complete a project sufficiently far in advance that the book will be available at the start of the school year, in time for the Christmas book-buying season, or a big annual book fair. The only way to discover such pressures is to ask your clients whether any such factors might affect their delivery schedule for the product. (Note that I said their schedule, not your schedule. Clients can sometimes be amazingly clueless about how your schedule relates to their schedule, leading to unpleasant surprises.) For some additional tips on learning about organizational schedules, consult the “survival skills” part of my article on Improving your editing efficiency. Learning to schedule your life more sanely also has strong ties to what may be your most crucial task as a freelancer: establishing a slush fund to cover your expenses those times when the work stops flowing or illness prevents you from working. (This also helps you to afford periodic vacations.) This isn’t optional if you freelance: make it a priority to build up 3 to 6 months worth of savings that you can tap during slow periods or illnesses, even if it means giving up beer and movies for a couple of months to save that money. If you have a family to support, consider buying disability insurance to cover you against illnesses; other forms of income-replacement insurance may be available, so ask an insurance broker about your options. Knowing that your slush fund is full lets you sacrifice work on the occasional Friday, whereas knowing that it’s underfunded or that you’ll be drawing it down soon (e.g., to pay a quarterly tax installment) reminds you to work longer weeks. For some tips on this, see my article Tax tip: a personal savings plan that works. The freelance life isn’t always unpredictable, and is sometimes unpredictable in a very stressful way. But the first step in mitigating that stress is to take steps to gain Continued on Next Page

Managing the Chaos, Continued from Previous Page

some control over your schedule. This article covers a few basic strategies you can use to improve your control. Your own work situation will clearly differ from mine, requiring various modifications to the approach I’ve proposed, and there are other stresses I haven’t covered that require different solutions. But as this article shows, the important thing is to decide that you’re willing to devote a little time to developing strategies that will minimize those stresses— and these strategies don’t need to be particularly complicated. Such simple steps can take you a long way towards a more enjoyable freelance career. 

Scholarship Winner, Continued from Page 6

Summits. There is so much value in having at least the camaraderie, if not the outright assistance, of other writers working with you. And it was that lesson that ultimately led to a big realization as to what it is about technical communication that really appeals to me. The loneliness of being the “lone technical writer” let me finally figure out that it’s not about the writing. Though long hours in front of a keyboard, actually writing, can be fun, it’s not the point to write or edit for its

own sake. Rather, the point is to reach out to others in a fascinating and productive way. Since I did not have the benefit of being in the same room as those potential other people, I learned to ask myself, again and again, how can I make what I do an improvement for me, a future writer or editor, my coworkers, and my audience? 