From stevefjong at comcast.net Tue Mar 27 08:41:41 2007 From: stevefjong at comcast.net (stevefjong at comcast.net) Date: Tue, 27 Mar 2007 14:41:41 +0000 Subject: Explaining the writer:developer ratio Message-ID: <032720071441.12111.46092D250000917E00002F4F220588617209020106000A900A9B9C@comcast.net> A colleague of mine asks the perennial question, "how many writers per engineer is typical?" but with a twist. Usually the person asking is a doc manager; this time the person impelling the question is a writer in a doc group who feels there should be more writers, and claims the group is below industry standards. (I suspect there's also an implication that the doc manager is understaffing.) Comments? -- Steve Steven Jong ("Typo? What tpyo?") Past President, STC Boston Chapter stevefjong at comcast.net, 978-413-2553 [C] * I am a candidate for STC Director | For more info, visit: www.StevenJong.net * From stcreg1dir at yahoo.com Tue Mar 27 08:47:40 2007 From: stcreg1dir at yahoo.com (stcreg1dir at yahoo.com) Date: Tue, 27 Mar 2007 07:47:40 -0700 (PDT) Subject: Yahoo! Auto Response Message-ID: <589084.37651.qm@web34302.mail.mud.yahoo.com> I'm currently away from my computer and won't be able to respond to your email until late this week. If urgent, please call me at 603 785 4946. Best, Cindy From davidovic.milan at gmail.com Tue Mar 27 09:06:36 2007 From: davidovic.milan at gmail.com (Milan Davidovic) Date: Tue, 27 Mar 2007 11:06:36 -0400 Subject: Explaining the writer:developer ratio In-Reply-To: References: Message-ID: <23d299f50703270806k2418d722meefc15e77eddf169@mail.gmail.com> On 3/27/07, stevefjong at comcast.net wrote: > A colleague of mine asks the perennial question, "how many writers per engineer is typical?" ...this time the person impelling the question is a writer in a doc group who feels there should be more writers, and claims the group is below industry standards. Why should there be an industry standard number of writers per engineer? I mean, even if we were to gather this data for a particular industry, what would make it meaningful? -- Milan Davidovic http://altmilan.blogspot.com http://www.terminus1525.ca/studio/view/2758 From rmcoplon at hotmail.com Tue Mar 27 09:31:01 2007 From: rmcoplon at hotmail.com (Rebecca Coplon) Date: Tue, 27 Mar 2007 11:31:01 -0400 Subject: Explaining the writer:developer ratio In-Reply-To: Message-ID: I have to agree that this isn't a practical metric. Most documentation estimating has to do with the estimated size of the documentation required, and is based on an estimate of hours per page of documentation, and then based on the project schedule constraint, determines the number of writers required. To try to tie the metric from writers to engineers is a little like trying to tie a metric from end users to software developers, rather than to system functions. It could be a simple system that can be coded in a day by one programmer, but be used by thousands of end users, or exceedingly complex and used by only one -- there's no necessary correlation there. Similarly, it could be a system that requires dozens of engineers, but with an interface so simple that the instructions fit on a single sheet. I'd reconsider the estimating technique. -Rebecca >From: "Milan Davidovic" >On 3/27/07, stevefjong at comcast.net wrote: >>A colleague of mine asks the perennial question, "how many writers per >>engineer is typical?" ...this time the person impelling the question is a >>writer in a doc group who feels there should be more writers, and claims >>the group is below industry standards. > >Why should there be an industry standard number of writers per >engineer? I mean, even if we were to gather this data for a particular >industry, what would make it meaningful? > _________________________________________________________________ It?s tax season, make sure to follow these few simple tips http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.aspx?icid=HMMartagline From jblaine at san.rr.com Tue Mar 27 09:44:00 2007 From: jblaine at san.rr.com (J. David Blaine) Date: Tue, 27 Mar 2007 08:44:00 -0700 Subject: Explaining the writer:developer ratio In-Reply-To: Message-ID: <002401c77086$bd766510$8aba504b@DFNRPR91> Dr. JoAnn Hackos wrote a paper on this entitled, surprisingly, "Ratios White Paper: A Study of the Relationship of Information Developers to Product Development Staff." The data is used for estimating jobs or justifying staff positions. A snippet of data from that paper is: Number of Technical Communicators to All Other staff Telecom 1 to 30 Medical 1 to 10 MobilePhone 1 to 10 Databases 1 to 5 You can purchase the white paper from her website, as I did, at: http://www.comtech-serv.com/white_papers.shtml best, --dave J. David Blaine San Diego, CA > -----Original Message----- > From: bounce-stcqsig-l-319032 at lists.stc.org [mailto:bounce-stcqsig-l- > 319032 at lists.stc.org] On Behalf Of stevefjong at comcast.net > Sent: Tuesday, March 27, 2007 7:42 AM > To: STC Quality and Process Improvement SIG Discussion List > Subject: [stcqsig-l] Explaining the writer:developer ratio > > A colleague of mine asks the perennial question, "how many writers per > engineer is typical?" but with a twist. Usually the person asking is a doc > manager; this time the person impelling the question is a writer in a doc > group who feels there should be more writers, and claims the group is > below industry standards. (I suspect there's also an implication that the > doc manager is understaffing.) > > Comments? > > -- Steve From Harold.Voorhees at baesystems.com Tue Mar 27 09:54:06 2007 From: Harold.Voorhees at baesystems.com (Voorhees, Harold A (US SSA)) Date: Tue, 27 Mar 2007 11:54:06 -0400 Subject: Explaining the writer:developer ratio In-Reply-To: References: Message-ID: <924EE6AD71BFBD44A930E3467E4955E129DEC6@GLDMS10007.goldlnk.rootlnka.net> -----Original Message----- From: bounce-stcqsig-l-321005 at lists.stc.org [mailto:bounce-stcqsig-l-321005 at lists.stc.org] On Behalf Of stevefjong at comcast.net Sent: Tuesday, March 27, 2007 10:42 AM To: STC Quality and Process Improvement SIG Discussion List Subject: [stcqsig-l] Explaining the writer:developer ratio A colleague of mine asks the perennial question, "how many writers per engineer is typical?" but with a twist. Usually the person asking is a doc manager; this time the person impelling the question is a writer in a doc group who feels there should be more writers, and claims the group is below industry standards. (I suspect there's also an implication that the doc manager is understaffing.) Comments? -- Steve Steven Jong ("Typo? What tpyo?") Past President, STC Boston Chapter stevefjong at comcast.net, 978-413-2553 [C] * I am a candidate for STC Director | For more info, visit: www.StevenJong.net * The ratio of writers to engineers is typically unspoken. Every industry will vary on this subject. With my employer the ratio is probably close to 10:1. That is 10 engineers for every writer. This is all dependent on contracts and scope of work. Is this individual's company small, medium, large? At the larger defense contractors you will see a decided difference (as in my company.) As far as being under manned, the manager normally will staff at the minimum to avoid layoffs in the event of lost or lack of contracts. Harold From Cindy.L.Holden at wellsfargo.com Tue Mar 27 10:11:27 2007 From: Cindy.L.Holden at wellsfargo.com (Cindy.L.Holden at wellsfargo.com) Date: Tue, 27 Mar 2007 11:11:27 -0500 Subject: Explaining the writer:developer ratio References: Message-ID: <17EFB20EF0117345BF103A0418A75228024CC40B@msgswbiadsm45.wellsfargo.com> My answer would be to ask the writer to make a business case as to why more writers should be hired on. That way, you could assess the validity of the writer's comments and concerns. Cindy Holden From techcommdood at gmail.com Tue Mar 27 10:15:50 2007 From: techcommdood at gmail.com (Bill Swallow) Date: Tue, 27 Mar 2007 12:15:50 -0400 Subject: Explaining the writer:developer ratio In-Reply-To: References:

Message-ID: <375e3cb30703270915p4dbef087x10e4b37a685e7171@mail.gmail.com> This is the second time within a working week that I've seen this paper referenced, and the second time I'll reply that the information is interesting but anecdotal at best when it comes to properly scoping staffing needs. On 3/27/07, J. David Blaine wrote: > Dr. JoAnn Hackos wrote a paper on this entitled, surprisingly, "Ratios White > Paper: A Study of the Relationship of Information Developers to Product > Development Staff." > > The data is used for estimating jobs or justifying staff positions. A > snippet of data from that paper is: > > Number of Technical Communicators to All Other staff > Telecom 1 to 30 > Medical 1 to 10 > MobilePhone 1 to 10 > Databases 1 to 5 > > You can purchase the white paper from her website, as I did, at: > http://www.comtech-serv.com/white_papers.shtml -- Bill Swallow HATT List Owner WWP-Users List Owner Senior Member STC, TechValley Chapter STC Single-Sourcing SIG Manager http://techcommdood.blogspot.com avid homebrewer and proud beer snob "I see your OOO message and raise you a clue." From DJones at zebra.com Tue Mar 27 10:16:08 2007 From: DJones at zebra.com (Jones, Donna) Date: Tue, 27 Mar 2007 11:16:08 -0500 Subject: Explaining the writer:developer ratio In-Reply-To: Message-ID: <56BB7301E340C54291D9728333B94F090AC692CA@03s03exch02.zebra.lan> > this time the person impelling the question is a writer in a doc group who > feels there should be more writers, and claims the group is below industry > standards. Asking for the standard number of writers per engineer is like asking for the standard number of engineers per project. You could probably figure that number out, but why? It's a completely meaningless metric in most situations. The way to determine if you are understaffed is to figure out how many man-hours are required to do the documentation that you're required to do in the timeframe that you have to do it. If you find that your department of three people needs to put in 10,000 man-hours in the next six months then you're understaffed--even if each of you supported only a single engineer. But if you require only 2000 man-hours for three people in the same six months, you'd better start looking for more to do before one of you gets the axe. Donna - CONFIDENTIAL- This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email. From davidovic.milan at gmail.com Tue Mar 27 10:50:38 2007 From: davidovic.milan at gmail.com (Milan Davidovic) Date: Tue, 27 Mar 2007 12:50:38 -0400 Subject: Explaining the writer:developer ratio In-Reply-To: References:

Message-ID: <23d299f50703270950q283e6accr153ee0063e7a3153@mail.gmail.com> On 3/27/07, Jones, Donna wrote: > The way to determine if you are understaffed is to figure out how many > man-hours are required to do the documentation that you're required to > do in the timeframe that you have to do it. How about an evaluation of recent performance? The problem may be just as much in how the work is being done (both within the doc team and in the systems that feed into it) as it is in how many people are doing it. -- Milan Davidovic http://altmilan.blogspot.com http://www.terminus1525.ca/studio/view/2758 From jblaine at san.rr.com Tue Mar 27 13:27:19 2007 From: jblaine at san.rr.com (J. David Blaine) Date: Tue, 27 Mar 2007 12:27:19 -0700 Subject: Explaining the writer:developer ratio In-Reply-To: Message-ID: <006201c770a5$f047a390$8aba504b@DFNRPR91> Characterizing the Hackos paper as "anecdotal at best," is not reasonable. The ratios white paper documents the results of study, not a bunch of girl scouts sitting about the campfire chattering about a hook-handed mangler. The purpose of the study was to help technical communicators justify staffing needs, not to scope a single project. Estimating a project could utilize the white paper data but could not depend upon it exclusively. From davidovic.milan at gmail.com Tue Mar 27 14:14:52 2007 From: davidovic.milan at gmail.com (Milan Davidovic) Date: Tue, 27 Mar 2007 16:14:52 -0400 Subject: Explaining the writer:developer ratio In-Reply-To: References:

Message-ID: <23d299f50703271314p2b56991co6ec44c66866ce53a@mail.gmail.com> On 3/27/07, J. David Blaine wrote: > The purpose of the study was to help technical communicators justify > staffing needs, So how would that work? Best practices, I sort of get - but not this. Thanks. -- Milan Davidovic http://altmilan.blogspot.com http://www.terminus1525.ca/studio/view/2758 From techcommdood at gmail.com Tue Mar 27 14:24:42 2007 From: techcommdood at gmail.com (Bill Swallow) Date: Tue, 27 Mar 2007 16:24:42 -0400 Subject: Explaining the writer:developer ratio In-Reply-To: References:

Message-ID: <375e3cb30703271324v566819b7oc520f3b7818750c7@mail.gmail.com> In my experience, not in my reading, ratios and other sweeping industry metrics play minor roles unless you add a lot of spin. Census poles are the same, as are demographics to a degree. They are studies, but the sample sizes are just too small to be of specific use. You can certainly keep these metrics in mind, but in the end they don't amount to a hill of beans unless you do your own homework to determine the exact need and balance you need in your own environment. The more granular and targeted the metrics are, the more effective they become at justifying need. Knowing that the average American household has 1.87 kids is all well and good, but even with rounding up to the next whole number, 2 kids is likely too few for a farming family and too many for a big city fast lane lifestyle. In the end, you have to have to get specific. or to put it another way, the STC salary survey is a great resource to see what, on average, we techcomm geeks are making. But when it comes to salary negotiations, unless you work for a small private company, there are likely far more precise mechanisms already in place to ensure your pay is competitive in the local market for your line of work. The paper may open the door to discussions, but I can't see how it could _justify_ staffing. On 3/27/07, J. David Blaine wrote: > The purpose of the study was to help technical communicators justify > staffing needs, not to scope a single project. Estimating a project could > utilize the white paper data but could not depend upon it exclusively. -- Bill Swallow HATT List Owner WWP-Users List Owner Senior Member STC, TechValley Chapter STC Single-Sourcing SIG Manager http://techcommdood.blogspot.com avid homebrewer and proud beer snob "I see your OOO message and raise you a clue." From Cindy.L.Holden at wellsfargo.com Tue Mar 27 14:51:56 2007 From: Cindy.L.Holden at wellsfargo.com (Cindy.L.Holden at wellsfargo.com) Date: Tue, 27 Mar 2007 15:51:56 -0500 Subject: Explaining the writer:developer ratio References: Message-ID: <17EFB20EF0117345BF103A0418A75228024CC64D@msgswbiadsm45.wellsfargo.com> What is this discussion about a white paper written by Hackos? Are most of the subscribers to this list a bunch of doctoral students? Where are the real-world solutions? Where's the real discussion? Give me a break. I had enough of this theoretical, qualitative, quantitative, non-practical discussion in graduate school. Move on. Get out of your dusty rooms and offer some real assistance to the originator of the question. Cindy Holden From diane_evans at merck.com Tue Mar 27 15:02:08 2007 From: diane_evans at merck.com (Evans, Diane L (Rosetta)) Date: Tue, 27 Mar 2007 14:02:08 -0700 Subject: Explaining the writer:developer ratio In-Reply-To: References: Message-ID: >Get out of your >dusty rooms and offer some real assistance to the originator of the question. My room is not dusty, although it does have paperwork piled all over. :) Real world experience: Your writer: engineer ratio is whatever the company wants it to be. If you think that you are overworked, then show your boss a schedule (Microsoft Project is good) with a list of all of the documents that you are expected to write for the next three months/six months/year or however far in advance that you can plan. Estimate the time it will take to write each document. You will then have a business case for either needing another writer or going back to work without grumbling. My name is Diane. I am a lone writer, in a group of 100 people (7 direct developers and many others that I assist). Diane Evans Requirements Analyst ASQ CSQE Rosetta Inpharmatics 206-802-6560 ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. ------------------------------------------------------------------------------ From kevin.x.sime at ampf.com Wed Mar 28 09:51:15 2007 From: kevin.x.sime at ampf.com (Kevin X Sime) Date: Wed, 28 Mar 2007 10:51:15 -0500 Subject: Explaining the writer:developer ratio Message-ID: I think it can be helpful to identify a ratio, but if you stop there you're still in trouble. At the end of the day it's about getting others to understand how you add tangible value in a way that matters to them, showing that your work is one of the solutions to their business needs and showing you understand both their content and their business model well enough that you can be treated as a partner or consultant and not a transaction or just a service. Toward that end, here are a few thoughts to help get you there... -Sharing industry standards is helpful to build credibility, but that information alone is too abstract to convince the people you work with when it comes to timing and resourcing that the information applies to your organization. It also doesn't justify in their minds getting or not getting the work done. "I still need it and I don't care why you can't do it" will be the unstated response. -A Six Sigma-style effort may be helpful where the group/company is large enough. It can show opportunities for process improvement and at least helps document cycle time in a relatively objective way that reflects your organization's unique environment -The Microsoft Project idea Diane Evans shared is great. MS Project has its flaws, but it's the way many product managers, line leaders, etc. work and reflects how they prioritize, plan and execute. In effect, it's a language they understand. Whatever way you do it, try to get at the work load issue by a proposed prioritization, then a schedule and a work plan in the same format(s) and language your business leaders use. In effect, convince them it isn't that you are inefficient or doing lots of unnecessary work, show them you know what you're doing and guide them toward agreeing to the informed prioritization choices and schedule changes you think make sense. If you do that, they agree you're doing your job well and they still "need" more help, your staffing issue will be much closer to being resolved because not your problem is their problem too and you're much more likely to get the staffing resources you need. >? >? >? >? >? >? > > Kevin Sime | Marketing Manager Brokerage and Managed Products Ameriprise Financial Ameriprise Financial, Inc. 1795 Ameriprise Financial Center | Minneapolis, MN 55474-9900 Office: 612.671.4775 | Fax: 612.671.6162 Mobile: 612.810.2932 | kevin.x.sime at ampf.com ameriprise.com ----------------------------------------- ******************************************************************* *********** "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." ******************************************************************* ***********