| |||||||||
|
1. #15101 Contracting: Flat Fee or Hourly Rates? Recommends that technical writers working as independent contractors quote flat fees for projects instead of hourly rates. The article offers tips on preparing portfolios and conducting client interviews. 2. #23643 Developing a Project Life Cycle for Technical Publications Having a technical publications project life cycle (pLC) that parallels an organization's product life cycle (PLC) greatly facilitates its adoption by engineering or development organizations. A technical publications project life cycle relates major documentation project management strategies, tasks, and deliverables to the same model used by technical organizations to control product development in an efficient and cost-effective manner. Some technical organizations perceive the documentation development process as being “intrusive” into the product development process, particularly during the Implementation Phase of the PLC. Communicating a technical publications pLC to these organizations early in the PLC eliminates this misperception. Le Vie, Donald S., Jr. STC Proceedings (2003). Articles>Documentation>Project Management 3. #15117 Documentation Metrics: What Do You Really Want to Measure? Examines several metrics--systems for measuring production and production standards--to determine their value to technical communicators. He argues that qualitative metrics are more meaningful than quantitative ones. Le Vie, Donald S., Jr. Intercom (2000). Articles>Documentation>Assessment>Heuristic Evaluation 4. #13293 An eCommerce Primer for Technical Communicators The burgeoning eCommerce industry has redefined not only traditional business processes, but the technology required to impart them. Roles are being created or redefined, where programmers, systems analysts, and engineers now have to have almost as much knowledge of business process development as they do of their technical specialty. The same can be said for technical communicators. Technical communicators involved in eCommerce today need to have an understanding of the major issues involved in eCommerce. This paper addresses five of these major eCommerce areas: the statistics behind eCommerce issues, eCommerce infrastructure providers, managed electronic commerce, business object technology, and data mining. Le Vie, Donald S., Jr. STC Proceedings (2000). Presentations>Web Design>E Commerce 5. #15147 Internet Technology and Intellectual Property This article outlines the complex legal environment surrounding the Internet, copyright law, and intellectual property. Le Vie, Donald S., Jr. Intercom (2000). Articles>Technology>Intellectual Property 6. #15185 Lists ten common mistakes in resumes and ten suggestions for improvement based on his experience as a hiring manager. The article includes a sidebar on how to write effective cover letters. Le Vie, Donald S., Jr. Intercom (2000). Careers>Resumes 7. #13204 Understanding Data Flow Diagrams Data flow diagrams (DFDs) reveal relationships among and between the various components in a program or system. Le Vie, Donald S., Jr. STC Proceedings (2000). Presentations>Graphic Design>Charts and Graphs 8. #13172 Using JavaScript to Develop Interactive Self-Assessments Interactive self-assessments are effective tools for a variety of audiences; from determining one’s Myers- Briggs Type Indicator (MBTI) or personality characteristics to self-scoring quizzes of all types for online training. Many Web sites contain such selfassessments that help customers select from among other offerings the type of product or service that meets their requirements. The strategic design and development of interactive self-assessments can also help steer customers to your specific product line or service, or even help them make the decision to buy or award a contract. This paper looks at the effectiveness of self-assessments as a business tool and the use of JavaScript for supporting the interactive elements. Le Vie, Donald S., Jr. STC Proceedings (2000). Presentations>Web Design>Interaction Design>JavaScript 9. #14964 What's the Value of Technical Communication? Unlike many other professions, our work products rarely stand by themselves. The work product of an engineering team may be a new pager or PDA; the work product of a development team may be a general-market software application. Data sheets, programmers reference manuals, and microprocessor design guides don't have their own standalone markets. They are designed and produced specifically for supporting standalone products. Their value, therefore, lies in how well they serve as a conduit for transferring and translating knowledge about the product to customers or end users according to their requirements. Le Vie, Donald S., Jr. GaryConroy.com (2002). Articles>TC>Assessment 10. #13157 Writing Killer eCommerce/IT Proposals that Win New Business Winning new eCommerce/IT business depends on many factors, not the least of which is a requirements-focused, bloat-free proposal that prospects and customers will read. But to get to that point, proposal development must be tied to a business development process that will guide a qualified opportunity toward becoming a business proposal, and ultimately, a sustainable or repeatable business deal. Before committing resources to proposal development, a Needs Analysis/Return on Investment (ROI) study (billable service) for the prospect or customer should be necessary. Such a study not only shows the prospect how well your organization knows its business, it helps steer a prospect to your organization’s process. The Needs Analysis/ROI study results provide a head start on proposal development, where the proposal turnaround time can be as short as one day. Le Vie, Donald S., Jr. STC Proceedings (2000). Presentations>Business Communication>Proposals 11. #27447 Writing Software Requirements Specifications For technical writers who haven't had the experience of designing software requirements specifications (SRSs, also known as software functional specifications or system specifications) templates or even writing SRSs, they might assume that being given the opportunity to do so is either a reward or punishment for something they did (or failed to do) on a previous project. Actually, SRSs are ideal projects for technical writers to be involved with because they lay out the foundation for the development of a new product and for the types of user documentation and media that will be required later in the project development life cycle. It also doesn't hurt that you'd be playing a visible role in contributing to the success of the project. Le Vie, Donald S., Jr. TECHWR-L (2000). Articles>Writing>Specifications>Technical Writing
| |||||||||
| |||||||||
Click here to learn how to embed the RSS feed by this author in your website.