From ndcgroup at yahoo.com Sun Dec 3 13:45:46 2006 From: ndcgroup at yahoo.com (Nicholas Di Ciaccio) Date: Sun, 3 Dec 2006 12:45:46 -0800 (PST) Subject: New Member Introduction Message-ID: <802435.25114.qm@web53615.mail.yahoo.com> Hello my name is Nick Di Ciaccio and I am hoping to enter the field of Technical Communications. For many years, I worked as an Information Technology professional until I lost my job overseas to outsourcing like many other Americans. As an IT professional, I had full project life cycle experience from initiation to completion including analyzing, designing, coding, testing, debugging, documenting, supporting, and maintaining systems and databases. I?ve always been interested in quality and process improvement issues and would like to learn more this and the possible career paths available in this area within the field of Technical Communications. Nicholas Di Ciaccio ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com From j_grey at writeangles.com Sun Dec 3 14:27:10 2006 From: j_grey at writeangles.com (That Darned Writer) Date: Sun, 03 Dec 2006 13:27:10 -0800 Subject: Another new member intro Message-ID: <4573412E.10404@writeangles.com> Hi, I'm Joanne Grey. New to this SIG, but not to STC or technical communication. I'm very interested in process improvement. I went from 12 years as a contractor to being a staffer, and the biggest issue I see is the lack of(or broken) process. Always wanting to do things better and more efficiently, I'm hoping to gain wisdom from you. ________________________________________ joanne grey j_grey at writeangles.com Principal writer www.writeangles.com It?s all right to have butterflies in your stomach. Just get them to fly in formation. -Rob Gilbert From Gyorgy.Balassa at sei.hu Thu Dec 7 04:28:13 2006 From: Gyorgy.Balassa at sei.hu (Gyorgy Balassa) Date: Thu, 7 Dec 2006 12:28:13 +0100 Subject: =?iso-8859-1?Q?Yet_Another_New_member_Bio_-_Gy=F6rgy_Balassa?= Message-ID: <7D9FB6590B287C4EA08429B084257131AB5D4F@debdc01.sei-it.net> Hi All, For the last 6 months I have been a solo team (have a junior colleague now) documentation department for an upstart software development company in Hungary founded by 100 per cent American capital with international clients. I worked as university assistant lecturer and research assistant before, teaching (mostly) linguistics, grammar and vocabulary and professional communication, ITC research and authoring for Hungarian English majors. I also did freelance technical translation / authoring jobs, especially localization and internationalization of mobile applications, as well as translating end-user documentation for a wide range of mobile devices. I also tried my hand at development (a few applications written in Java and Perl plus some arcane embedded languages, in addition to web-design/scripting in PHP, Perl). I am brand new STC and SIG member - I could not afford to join earlier from a teacher's salary Now I have to manage and maintain the documentation policy and the product documentation bundles for about a dozen complex software application as well as occasionally doing odd office jobs (VIP correspondence, translation). I face the challenge, the pitfalls and the sheer excitement of building a documentation department from scratch while producing an ever increasing volume release notes and deployment guides, just to mention a few from the dozen of genres we work as part of our daily routine. I read a lot of non-fiction, especially like 19th - 20th century European novel (in English, Hungarian and some Russian), a select elite of drama and poetry (some English but most of them Hungarian) usually watered up - for ease of daily consumption - with enormous amount sci-fi and fantasy. I am addicted to baking bread and cooking in general (whenever I can coup out some room in the family kitchen). I am sorry for the long lurking and the late (3 months lag !) introduction. I look forward to exchanging ideas about this job(s) of ours and to share experiences with anyone/everyone interested. _____________________________ Gy?rgy Balassa Technical Writer ROC Development Hungary Kft. E-Mail: gyorgy.balassa at sei.hu From joann.hackos at comtech-serv.com Tue Dec 12 13:58:27 2006 From: joann.hackos at comtech-serv.com (JoAnn Hackos) Date: Tue, 12 Dec 2006 13:58:27 -0700 Subject: ATTN: DITA Boot Camp in the Bay area Message-ID: <72E2EA99C8FA4F4B930539BF7939C6DF0136DDD4@CSI001.Comtech.local> DITA Boot Camp A JoAnn Hackos workshop January 29-February 2, 2007 Seaport Computer & Conference Center Redwood City, CA Sponsored by Comtech Services and Astoria Software http://www.comtech-serv.com/workshops/ditabootcamp.shtml This workshop includes a complimentary copy of Jen Linton and Kylene Bruski's new Introduction to DITA: A Basic User Guide to the Darwin Information Typing Architecture book. The Boot Camp will begin with the DITA Basics. By structuring a task in DITA, learn the structure inherent in the core DITA specialized information types: task, concept, and reference. Work with sample content that gives you insight into the changes that you may need to make so that your content works in DITA. DITA is the starting point for introducing structured writing to your organization. The Boot Camp takes you from the DITA Basics to the skills you'll need to create a specific standard for your industry and your content. In the Structured Authoring portion of the workshop, you'll learn * the core requirements of an Information Model * the business value of structured writing * about an information architecture team * the DITA information Types and Content Units * a sample Information Model to help you create your own Minimalism comes next. Learn why eliminating empty text and focusing on what users really need to know is a critical first step toward structured authoring. You can't create structured topics out of text that nobody wants and no one ever reads. During the Minimalism portion of the Boot Camp, you'll learn * to evaluate when minimalist strategies should be used * the minimalist agenda * the four basic principles of minimalism * why minimalist information is read by 90% of users * how major corporations have implemented minimalism in their technical information For those unfamiliar with the basics of HTML and XML, attend a special evening session on Tuesday night: * Understand basic XML concepts and terminology * Understand how XSLT and style sheets transform XML tagged text into formatted deliverables * Learn how to read a Document Type Definition (DTD) Move from structured authoring and minimalism into the details of the Darwin Information Typing Architecture (DITA). DITA is the OASIS standard for topic-based information development. Learn why it is fast becoming the standard for technical communication worldwide. During the third and longest portion of the Boot Camp, you'll learn to * build a business case for moving to the DITA * plan a topic-based project using annotated topic lists * transform your own topics based on the three core information types: concept, task, and reference * create a DITA map to organize your topics into deliverables for PDF, HTML, and help systems * set up relationship tables * handle conditional processing and content reuse through conrefs * create a DITA specialization * process a DITA map using the DITA Open Toolkit The Boot Camp workshop requires that you bring a laptop computer, sample documentation to complete exercises with and be prepared to learn a DITA XML editor to author topics. During the wrap-up session, discuss how to evaluate XML editors and XML-compliant content management systems. Conclude with an open discussion of applying change management principles to your organization. We expect DITA Boot Camp to be very popular. Space is limited to 25 participants. ATTENTION CIDM MEMBERS. Because of very limited space, we will not be offering the standard 2 for 1 deal for DITA Boot Camp. However, you will receive a 10% DISCOUNT. The CIDM member price is only $1,755. Please register with Lovonya Thomas at lovonya at comtech-serv.com to receive this CIDM member discount. For more information and to register visit the workshop web site at http://www.comtech-serv.com/workshops/index.shtml. From estanley at cisco.com Fri Dec 15 16:52:04 2006 From: estanley at cisco.com (Erin R. Stanley) Date: Fri, 15 Dec 2006 16:52:04 -0700 Subject: How is your editing/DTP/graphics team structured? Message-ID: I am a manager of an editing, desktop publishing, and graphics services team at a high-tech company. I am currently in the process of redesigning my team, and I would like to contact other STC members who manage or work on similar teams at other companies to see how their teams are structured. Specifically, I'm interested in information such as these: How is your team organized? (Team hierarchy, functionality.) Is your service (editing, DTP, or graphics) structured with employees, contractors, or both? What are your workflow processes? How do you handle the issue of time-to-market vs. quality? What processes have you put in place for a team like this? And so on. If you can and are willing to help me, I'm interested in talking with you--either through this forum, by e-mail, or by phone. Thanks in advance. Sincerely, Erin Stanley From mbheitz at msn.com Sat Dec 16 07:40:29 2006 From: mbheitz at msn.com (Margaret) Date: Sat, 16 Dec 2006 09:40:29 -0500 Subject: How is your editing/DTP/graphics team structured? Message-ID: Hello Erin: You've asked some great questions. I hope you and your other responders copy the whole group on their responses. I didn't manage exactly the same configuration of services. But *maybe* my experience will be helpful to you. At different times, I managed between 3 and 10 technical writers, contract editors, and user interface designers. I hope this makes some sense and is not too tied to my own peculiar way of working. Time-to-market vs. quality: We developed a standard outline for each book type that we had to produce. The writer could take the outline and run with it, as opposed to starting with a blank documentation spec. This worked very well for domestic writers. It also helped books that were handed off to writers in India, though in those cases books took longer. Team organization: Mix of full-time and contract. Full-time writers had ranks of principal, senior, and technical writer. Principal writers worked alone or led small groups; seniors were assigned books within projects and sometimes books within 1-3 projects; technical writers worked on one project in close association with a principal. U.i. specialists were brought in on important/critical projects. The specialists performed work while educating me, our in-house u.i. designer, and the development team on methods for collecting and incorporating user input into u.i. designs. Contract editors used our style guide and process document to do developmental and copy edits for new or critical projects. (Revisions were handled by peer editors using the same documents.) Final "sanity-checking" was done in-house using a checklist. Workflow: We developed a standard workflow and stuck to it. The workflow was very useful in setting schedules and communicating status. Process: We created an standard process for doc development as well as work instructions for sub-processes that tended to have problems. The main problems were the technical review and sign-off process and the final production/handoff process. Investing in internal process documentation really paid off; I recommend it. Good luck, Erin. I hope this helps some. Cheers, Margaret Heitz -----Original Message----- From: bounce-stcqsig-l-283650 at lists.stc.org [mailto:bounce-stcqsig-l-283650 at lists.stc.org] On Behalf Of Erin R. Stanley Sent: Friday, December 15, 2006 6:52 PM To: STC Quality and Process Improvement SIG Discussion List Subject: [stcqsig-l] How is your editing/DTP/graphics team structured? I am a manager of an editing, desktop publishing, and graphics services team at a high-tech company. I am currently in the process of redesigning my team, and I would like to contact other STC members who manage or work on similar teams at other companies to see how their teams are structured. Specifically, I'm interested in information such as these: How is your team organized? (Team hierarchy, functionality.) Is your service (editing, DTP, or graphics) structured with employees, contractors, or both? What are your workflow processes? How do you handle the issue of time-to-market vs. quality? What processes have you put in place for a team like this? And so on. If you can and are willing to help me, I'm interested in talking with you--either through this forum, by e-mail, or by phone. Thanks in advance. Sincerely, Erin Stanley From ann at annlwiley.com Sat Dec 16 09:57:14 2006 From: ann at annlwiley.com (Ann L. Wiley Consultants Inc.) Date: Sat, 16 Dec 2006 11:57:14 -0500 Subject: How is your editing/DTP/graphics team structured? References: Message-ID: <002c01c72133$a9a28e80$6600a8c0@ACERTMate> Erin, Thanks for your hard work in posting the inquiry in so many places. When you have all your responses, please post a summary on the STC Forum, as a Reply to your original post in the Questions and General Topics forum. Thanks for this excellent question. Ann Ann L. Wiley, Ph.D. Ann L. Wiley Consultants Inc. ann at annlwiley.com Fellow, Manager QPI SIG From Hannah.Kirk at OntarioSystems.com Sat Dec 16 10:26:32 2006 From: Hannah.Kirk at OntarioSystems.com (Hannah Kirk) Date: Sat, 16 Dec 2006 12:26:32 -0500 Subject: [SPAM?] How is your editing/DTP/graphics team structured? In-Reply-To: Message-ID: I work as a supervisor at a small software company. My technical communications team is relatively small--only 17 or so employees. Our team is organized into two groups for supervisory purposes only. With regard to hierarchy, we have a mix of interns and full time employees with varying skill levels in each group. Our group handles only writing and updating documentation. We do not do graphics beyond creating flowcharts and screen shots. Our marketing team does graphics separately for whitepapers, quick references, and manual covers. Our editing team is separate from our technical communications group, but the two teams work very closely together. Formerly, the editing team was part of the technical communications team. When we assign work, we look very carefully at individual strengths and weaknesses of individuals, which is perhaps more of an art than a skill and is perhaps somewhat unconventional. Our workflow is highly structured. Our programmers do not document their work thoroughly, or sometimes at all, thus our writers do extensive research in interviewing SMEs, testing the system, and reading and testing code. Writers first research the area to write about, then create or change a conceptual plan. Writers submit the plan to a managerial committee for review and approval, then write the documentation. Next, they review the documentation with stakeholders and SMEs, revise, and send to a first edit, revise again, and submit for a supervisory edit. Less experienced writers turn their document into their supervisor for preliminary review before reviewing the documentation with stakeholders and SMEs. The issue of time-to-market vs. quality is one we struggle with daily, however, we strongly emphasize priorities as they come up and weekly re-prioritize with our team members to ensure they know their deadlines. Since we have a small team, but a great deal of work, this helps writers to be clear on their priorities. The team has gotten very used to frequently changing their priorities. The best way we have found to approach this is to make individuals experts in certain general areas, so they are familiar with functionality on some level if they have to switch priorities. For changes to major processes, we typically create committees that consist of 4-5 writers with varying levels of experience to devise and propose a process to management. Thanks. I'd be interested to know your processes as well. Sincerely, Hannah Kirk Supervisor, Technical Communications Ontario Systems 765-751-7000 Attention: This message and all attachments are private and may contain information that is confidential and privileged. If you received this message in error, please notify the sender by reply email and delete the message immediately. From estanley at cisco.com Sun Dec 17 08:29:27 2006 From: estanley at cisco.com (Erin R. Stanley) Date: Sun, 17 Dec 2006 08:29:27 -0700 Subject: [SPAM?] How is your editing/DTP/graphics team structured? Message-ID: Hi, Hannah, This is great information. Thank you! I'd like to follow up with you via the phone. I'll send you a separate e-mail to discuss this. Thank you! Erin From estanley at cisco.com Sun Dec 17 08:33:07 2006 From: estanley at cisco.com (Erin R. Stanley) Date: Sun, 17 Dec 2006 08:33:07 -0700 Subject: How is your editing/DTP/graphics team structured? Message-ID: I will be more than happy to do this. I'm just thankful that there is a forum where I can ask questions like this, and that there are such helpful people willing to provide feedback. This will probably take me a good 2-4 weeks to follow up with people and synthesize the information. So look for a summary post from me in a few weeks. Take care, Erin > Erin, Thanks for your hard work in posting the inquiry in so many places. > When you have all your responses, please post a summary on the STC Forum, as > a Reply to your original post in the Questions and General Topics forum. > Thanks for this excellent question. > > Ann > > Ann L. Wiley, Ph.D. > Ann L. Wiley Consultants Inc. > ann at annlwiley.com > Fellow, Manager QPI SIG From estanley at cisco.com Sun Dec 17 09:29:03 2006 From: estanley at cisco.com (Erin R. Stanley) Date: Sun, 17 Dec 2006 09:29:03 -0700 Subject: How is your editing/DTP/graphics team structured? Message-ID: Hi, Margaret, Thank you for responding. You've been very helpful! (I will post my summary of all of the responses and follow-ups within the next month.) I have a few comments and questions about your response . . . . > Time-to-market vs. quality: We developed a standard outline for each book > type that we had to produce. The writer could take the outline and run with > it, as opposed to starting with a blank documentation spec. This worked very > well for domestic writers. It also helped books that were handed off to > writers in India, though in those cases books took longer. How do you determine the schedule for each project? Is it based on what your client needs? Do you have writing and editing metrics (e.g., # pages per hour) that you apply? Do you keep any metrics on your projects, that is, metrics that show customer satisfaction, the quality of your work, etc.? In previous groups, I've never been required to provide information such as this, but now that I'm in a different group, this is an important requirement. Previously, my team's priority was quality (as dictated by a previous team and mindset). We were heavily invested in the quality of the final ILT that was produced (e.g., through editing, desktop publishing, and graphical enhancements). Now, I'm changing that mindset to one where we are responsible for the quality of the work we produce, while the PM is responsible for the quality of the product as a whole. This will enable us to take on a faster model of work, that will lead to lesser quality. > Team organization: Mix of full-time and contract. Full-time writers had > ranks of principal, senior, and technical writer. Principal writers worked > alone or led small groups; seniors were assigned books within projects and > sometimes books within 1-3 projects; technical writers worked on one project > in close association with a principal. This set-up interests me because as part of my restructuring, I'm looking to hiring contract editors who are less experienced than my current contract editors. I am thinking that I will use them for the less in-depth edits that I'm going to implement. Do you have formal reviews of the less-experienced writers? If so, I'm interested in learning more about that. > U.i. specialists were brought in on important/critical projects. The > specialists performed work while educating me, our in-house u.i. designer, > and the development team on methods for collecting and incorporating user > input into u.i. designs. I'm interested in learning more about how you collect this information and how you determine what feedback you incorporate. > Contract editors used our style guide and process document to do > developmental and copy edits for new or critical projects. (Revisions were > handled by peer editors using the same documents.) Final "sanity-checking" > was done in-house using a checklist. I'm interested in learning more about your processes for editing. I have questions such as these: How are editors scheduled? How are editors chosen for projects? Does someone review the editors' edits and queries before the writer sees them? Does the editor work directly with the writer? Among other questions. > Workflow: We developed a standard workflow and stuck to it. The workflow was > very useful in setting schedules and communicating status. I would like to learn more about this as well. Margaret, would you be willing for me to meet with you by phone, for about an hour, to follow up with you about the questions I included in this message and a few others that I have? Thank you! Erin Stanley From ann at annlwiley.com Sun Dec 17 17:55:01 2006 From: ann at annlwiley.com (Ann L. Wiley Consultants Inc.) Date: Sun, 17 Dec 2006 19:55:01 -0500 Subject: How is your editing/DTP/graphics team structured? References: Message-ID: <000e01c7223f$29670590$6600a8c0@ACERTMate> It's clear that Erin's work is going to produce signifcant new knowledge. >Now, I'm changing that mindset to one where we are responsible for the quality of the work we produce, while the PM is responsible for the quality of the product as a whole. This will enable us to take on a faster model of work, that will lead to lesser quality. This may lead to equal or greater quality rather than lesser. Ann Ann L. Wiley, Ph.D. Ann L. Wiley Consultants Inc. ann at annlwiley.com From estanley at cisco.com Mon Dec 18 11:54:25 2006 From: estanley at cisco.com (Erin R. Stanley) Date: Mon, 18 Dec 2006 11:54:25 -0700 Subject: How is your editing/DTP/graphics team structured? Message-ID: I'm intrigued now, Ann. How would you see it as being of equal or greater quality? I've been thinking about this for so long, that sometimes I think I can't even see my own hand in front of my face. ;-) Thanks! > >Now, I'm changing that mindset to one where we > are responsible for the quality of the work we produce, while the PM is > responsible for the quality of the product as a whole. This will enable us > to take on a faster model of work, that will lead to lesser quality. > > This may lead to equal or greater quality rather than lesser. > > Ann From mbossart at prisma.com Mon Dec 18 12:18:22 2006 From: mbossart at prisma.com (Mitch Bossart) Date: Mon, 18 Dec 2006 13:18:22 -0600 Subject: How is your editing/DTP/graphics team structured? Message-ID: <01942E1251CD014798AB04F05559A97501CA1C9A@borg.prisma.com> Hi, gang. I hope this hasn't been discussed yet. Some of the discussions on quality that I found challenging included the idea that if your product is not delivered on time, then it is not a quality product. Same idea for price. These two ideas are often irritating to writers who, like most creative people, consider themselves artists. And art takes "as long as it takes." Therefore, for business reasons, it seems critical to define what your customer considers a quality product. A former co-worker in the manufacturing industry once told me: "Price, quality, cost--pick two." In other words, if quality is to be higher, then the price will be higher. If you want it fast and cheap, expect your quality to go down. Following this logic, you cannot let your customer choose all three, which is a cop out answer. Minimally, they need to give you a priority, which you may already know. Mitchell T. Bossart Prisma International From dgreen at associatedbrands.com Mon Dec 18 12:44:08 2006 From: dgreen at associatedbrands.com (Dori Green) Date: Mon, 18 Dec 2006 14:44:08 -0500 Subject: How is your editing/DTP/graphics team structured? In-Reply-To: Message-ID: Mitch Bossart wrote: Some of the discussions on quality that I found challenging included the idea that if your product is not delivered on time, then it is not a quality product. "Price, quality, cost--pick two." ************** Did you mean "_Speed_, quality, price -- choose two"?? That's how I've heard it expressed (and framed it and hung it on my office wall). Dori Green From davidovic.milan at gmail.com Mon Dec 18 13:18:45 2006 From: davidovic.milan at gmail.com (Milan Davidovic) Date: Mon, 18 Dec 2006 15:18:45 -0500 Subject: How is your editing/DTP/graphics team structured? In-Reply-To: References: Message-ID: <23d299f50612181218g5fa2da27n54da706242c920bd@mail.gmail.com> On 12/18/06, Mitch Bossart wrote: > Some of the discussions on quality that I found challenging included the idea that if your product is not delivered on time, then it is not a quality product. > > Same idea for price. If your standards deal with time and cost, then failing to meet those standards results in a product of less quality, does it not? -- Milan Davidovic http://altmilan.blogspot.com http://www.terminus1525.ca/studio/view/2758 From mbossart at prisma.com Mon Dec 18 15:14:02 2006 From: mbossart at prisma.com (Mitch Bossart) Date: Mon, 18 Dec 2006 16:14:02 -0600 Subject: New Member Message-ID: <01942E1251CD014798AB04F05559A97501EA6484@borg.prisma.com> I am new to the STC community. I earned my university degrees in English and Communication with an emphasis on writing and linguistics. My 15-year career in the technology industry has been mainly comprised of writing (technical newsletters, software implementation case studies, feature articles on technology-related topics), localization project management, and sales. My passions, career-wise, are technology, business process reengineering, and the art of persuasion. I hope to keep current on the latest and greatest tools and trends in the technical writing arena, and I want to keep close to the art and practice of writing, since I am currently in a sales position and do very little "real" writing. Looking forward to communicating with y'all! Mitchell T. Bossart Prisma International From mike at techscribe.co.uk Tue Dec 19 00:56:15 2006 From: mike at techscribe.co.uk (Mike Unwalla) Date: Tue, 19 Dec 2006 07:56:15 -0000 Subject: How is your editing/DTP/graphics team structured? In-Reply-To: Message-ID: <20061219075619.B36CED5D52@mra02.ch.as12513.net> Hi Mitchell and All, >> These two ideas are often irritating to writers who, like most creative people, consider themselves artists. I certainly don't consider myself a 'creative'. I'm an engineer and a scientist. I strive to bring engineering rigour to my work. The work does not take 'as long as it takes'. It's scheduled based on metrics. Regards, Mike Unwalla +44 114 266 6933 www.techscribe.co.uk -----Original Message----- From: bounce-stcqsig-l-255261 at lists.stc.org [mailto:bounce-stcqsig-l-255261 at lists.stc.org] On Behalf Of Mitch Bossart Sent: 18 December 2006 19:18 To: STC Quality and Process Improvement SIG Discussion List Subject: [stcqsig-l] RE: How is your editing/DTP/graphics team structured? Hi, gang. I hope this hasn't been discussed yet. Some of the discussions on quality that I found challenging included the idea that if your product is not delivered on time, then it is not a quality product. Same idea for price. These two ideas are often irritating to writers who, like most creative people, consider themselves artists. And art takes "as long as it takes." Therefore, for business reasons, it seems critical to define what your customer considers a quality product. A former co-worker in the manufacturing industry once told me: "Price, quality, cost--pick two." In other words, if quality is to be higher, then the price will be higher. If you want it fast and cheap, expect your quality to go down. Following this logic, you cannot let your customer choose all three, which is a cop out answer. Minimally, they need to give you a priority, which you may already know. Mitchell T. Bossart Prisma International From ann at annlwiley.com Wed Dec 20 20:49:01 2006 From: ann at annlwiley.com (Ann L. Wiley Consultants Inc.) Date: Wed, 20 Dec 2006 22:49:01 -0500 Subject: New Member References: Message-ID: <000b01c724b2$f4d077f0$6600a8c0@ACERTMate> Welcome, Mitch. I'm glad we have a member in the localization industy who is interested in process in the QPI SIG. Thanks for the introduction. Ann ----- Original Message ----- From: "Mitch Bossart" To: "STC Quality and Process Improvement SIG Discussion List" Sent: Monday, December 18, 2006 5:14 PM Subject: [stcqsig-l] New Member I am new to the STC community. I earned my university degrees in English and Communication with an emphasis on writing and linguistics. My 15-year career in the technology industry has been mainly comprised of writing (technical newsletters, software implementation case studies, feature articles on technology-related topics), localization project management, and sales. My passions, career-wise, are technology, business process reengineering, and the art of persuasion. I hope to keep current on the latest and greatest tools and trends in the technical writing arena, and I want to keep close to the art and practice of writing, since I am currently in a sales position and do very little "real" writing. Looking forward to communicating with y'all! Mitchell T. Bossart Prisma International From ann at annlwiley.com Sat Dec 23 11:13:55 2006 From: ann at annlwiley.com (Ann L. Wiley Consultants Inc.) Date: Sat, 23 Dec 2006 13:13:55 -0500 Subject: How is your editing/DTP/graphics team structured? References: Message-ID: <002d01c726be$1d4b3be0$6600a8c0@ACERTMate> 'Speed, quality, cost--pick two.' This is mistaken. Quality is that which satisfies the customer. It must be defined through specifications. Through process improvement we lessen the effort required to meet the specifications. The three factors are then optimized for the situation. It is up to the supplier to control the process and to the purchaser to evaluate the quality of the output. Over time, the partners achieve balance to obtain full satisfaction with the output, consistently. Ann Ann L. Wiley, Ph.D. Ann L. Wiley Consultants Inc. ann at annlwiley.com From DJones at zebra.com Thu Dec 28 06:04:21 2006 From: DJones at zebra.com (Jones, Donna) Date: Thu, 28 Dec 2006 07:04:21 -0600 Subject: How is your editing/DTP/graphics team structured? In-Reply-To: Message-ID: <56BB7301E340C54291D9728333B94F0909894827@03s03exch02.zebra.lan> > -----Ann Wiley wrote:----- > > 'Speed, quality, cost--pick two.' > > This is mistaken. Quality is that which satisfies the customer. It must be > defined through specifications. > > Through process improvement we lessen the effort required to meet the > specifications. > > The three factors are then optimized for the situation. > > It is up to the supplier to control the process and to the purchaser to > evaluate the quality of the output. Over time, the partners achieve > balance > to obtain full satisfaction with the output, consistently. > > Ann > > Ann L. Wiley, Ph.D. > Ann L. Wiley Consultants Inc. > ann at annlwiley.com I disagree with you, Ann. Just because a customer accepts something, you don't get points for "quality" if it's full of typos, poor writing, and poor organization. Customers can be satisfied with what the writers know is poor or mediocre quality. If a customer's requirements are for something top-notch, there's a good chance that it can't be done both quickly and cheaply. One of those will have to be sacrificed. If the requirements are only for something that is poor or mediocre, then it can usually be produced quickly and fairly cheaply. So in my opinion, the statement stands. 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 Thu Dec 28 09:55:42 2006 From: davidovic.milan at gmail.com (Milan Davidovic) Date: Thu, 28 Dec 2006 10:55:42 -0600 Subject: requirements (was: How is your editing/DTP/graphics team structured?) Message-ID: <23d299f50612280855l75db4031g71e6786d5f3580a8@mail.gmail.com> On 12/23/06, Ann L. Wiley Consultants Inc. wrote: > Quality is that which satisfies the customer. It must be > defined through specifications. Seems to me that "quality" is that which satisfies the requirements (or "specifications"). The intent of the requirements is to specify what the customer wants. (Splitting hairs? Perhaps... ) So, meet the requirements and you've got "quality". But it won't matter if someone got the requirements wrong, or if the client comes back and says that what they told you before isn't what they really want (Michael Schrage mentions something about this in 'Serious Play', and I think the agile development folks have something to say about this as well). -- Milan Davidovic http://altmilan.blogspot.com http://www.terminus1525.ca/studio/view/2758 From stevefjong at comcast.net Thu Dec 28 10:20:36 2006 From: stevefjong at comcast.net (stevefjong at comcast.net) Date: Thu, 28 Dec 2006 17:20:36 +0000 Subject: How is your editing/DTP/graphics team structured? Message-ID: <122820061720.28935.4593FCE4000BB3B000007107220702085309020106000A900A9B9C@comcast.net> Donna Jones wrote: > If a customer's requirements are for something top-notch, there's a good > chance that it can't be done both quickly and cheaply. One of those will > have to be sacrificed. If the requirements are only for something that > is poor or mediocre, then it can usually be produced quickly and fairly > cheaply. So in my opinion, the statement stands. "Good, fast, cheap: pick two" is still good for a laugh, but it's not an ironclad law. I wrote about this on TECHWR-L a few years ago: http://www.techwr-l.com/techwhirl/archives/9911/techwhirl-9911-00505.html I wrote about it at length in the DocQment newsletter, and both Geoff Hart and I wrote about it in the STC magazine Intercom: Hart, G.J. "Cheating the quality triangle." STC Intercom (April 2001) Jong, Steven. "The Quality Revolution and Technical Communication." STC Intercom (October 1997) -- Steve Steven Jong, Past President STC Boston Chapter 978-413-2553 [C] Boston Chapter Web site: www.stcboston.org * I am a candidate for STC Director * From ann at annlwiley.com Fri Dec 29 17:46:31 2006 From: ann at annlwiley.com (Ann L. Wiley Consultants Inc.) Date: Fri, 29 Dec 2006 19:46:31 -0500 Subject: requirements (was: How is your editing/DTP/graphics team structured?) References: Message-ID: <001501c72bab$f8a36bd0$6600a8c0@ACERTMate> >So, meet the requirements and you've got "quality". Yes. Quality is not an absolute; it is not "goodness." It is whatever the customer requires. Of course, you can bring up your supplier specifications to the customer, and negotiate the requirements. >But it won't matter if someone got the requirements wrong, or if the client comes back and says that what they told you before isn't what they really want (Michael Schrage mentions something about this in 'Serious Play', and I think the agile development folks have something to say about this as well). The customer's processes must be in control, and the supplier's execution flawless--also a function of process control. I'd be interested in links related to agile development and this issue. Thanks for the pointer to 'Serious Play.' Ann Ann L. Wiley, Ph.D. Ann L. Wiley Consultants Inc. 315-252-2086 ann at annlwiley.com From davidovic.milan at gmail.com Fri Dec 29 18:04:57 2006 From: davidovic.milan at gmail.com (Milan Davidovic) Date: Fri, 29 Dec 2006 19:04:57 -0600 Subject: requirements (was: How is your editing/DTP/graphics team structured?) In-Reply-To: References: Message-ID: <23d299f50612291704x45714c9dl64833c05ccc633bb@mail.gmail.com> On 12/29/06, Ann L. Wiley Consultants Inc. wrote: > I'd be interested in links related to agile development and this issue. Ah, it's a book that a guy at work is reading, and I'm not back in the office until next week. I'll post a reference then... -- Milan Davidovic http://altmilan.blogspot.com http://www.terminus1525.ca/studio/view/2758