#29463
Adapting to Scrum: Challenges and Strategies 
Read about some of the challenges facing technical writers who create product documentation in a Scrum environment, as well as strategies for confronting these challenges.
Sigman, Christine Marini. Intercom (2007). Articles>Project Management>Agile>Scrum
#27997
After the CMS Implementation Project
Much effort is focused, on the selection and subsequent implementation of a content management system (CMS). While it is obviously vital to ensure that the initial implementation project is successful, this is only the beginning of an ongoing commitment to growing and enhancing the use of content management throughout the organisation.
Robertson, James. CM Briefing (2004). Articles>Content Management>Project Management>Workflow
#27801
The purpose of this article is to define a set of ideal practices for an agile software development project.
McLennan, Liam. Code Project, The (2006). Articles>Project Management>Agile
#31040
Agile methodologies have had a lot of press in recent years. To listen to some people, agile methodologies are the answer to all the ailments that have ever plagued software development from the beginning of the computer age. But what are they, really? And do they really deliver on that promise? The answer is: (drumroll, please) it depends.
Little, Karen. BA Collective (2007). Articles>Project Management>Agile>Methods
#28359
It's true: even simple projects get messy. Christina Wodtke comes clean on Swiss Army knives, the writing on the wall, and the untidy glory of the Boxes and Arrows redesign contest.
Wodtke, Christina. Boxes and Arrows (2006). Articles>Web Design>Project Management>Case Studies
#26563
Review: The Art of Project Management
Can project management be an art? Has Berkun truly created a jargon-free guide for the whole project team? Kalbach leads us through the high-level tasks and the major milestones of this new book, while keeping us on task.
Kalbach, James. Boxes and Arrows (2005). Articles>Reviews>Project Management
#31849
Be Productive When a Project Stalls 
With more and more companies adopting the Darwin Information Typing Architecture, Baril discusses how to choose a compatible content management system that also supports your company's processes.
Gutowski, Amanda and Lori L. Pennington. Intercom (2008). Articles>Project Management>Planning>Collaboration
#30292
A Beginner's Guide to Project Management
Presents the basics of developing a project plan, managing the project, troubleshooting the project, and evaluating the completed project.
Houston, Bill. STC Proceedings (1993). Articles>Project Management
#26820
Betriebswirtschaftliche Lüsungen zur Kostensenkung Technischer Dokumentation 
Die meisten TD-Verantwortlichen besitzen einen technischen Hintergrund. Daher verwundert es nicht, dass sie Lösungen für Kostenprobleme ebenfalls in der Technik suchen: Datenbanken, Content Management oder Translation Memory. Doch die Investitionskosten sind hoch. Und oft dauert es Jahre, bis sich entsprechende Systeme amortisieren – wenn überhaupt. Ein Betriebswirtschaftler würde das Problem anders lösen: ohne Technik und ohne Investition, durch gezieltes Setzen von Prioritäten und mit optimierten Prozessen. Bewährte Ansätze aus der Betriebswirtschaft gibt es viele, denn andere Unternehmensbereiche leiden unter genau denselben Kostenproblemen. Dieser Beitrag zeigt die wichtigsten Methoden und gibt Beispiele für deren Anwendung in der Technischen Dokumentation.
Achtelig, Marc. indoition engineering (2006). (German) Articles>Management>Project Management>Workflow
#21727
Big Architect, Little Architect
First came the primordial soup. Thousands of relatively simple single-celled web sites appeared on the scene, and each one was quickly claimed by a multi-functional organism called a "webmaster." A symbiotic relationship quickly became apparent. Webmaster fed web site. Web site got bigger and more important. So did the role of the webmaster. Life was good. Then, bad things started to happen. The size and complexity and importance of the web sites began to spiral out of control. Mutations started cropping up. Strange new organisms with names like interaction designer, usability engineer, customer experience analyst, and information architect began competing with the webmaster and each other for responsibilities and rewards. Equilibrium had been punctuated and we entered the current era of rapid speciation and specialization.
Morville, Peter. Argus Center (2000). Articles>Web Design>Interaction Design>Project Management
#21577
Bilingual Team Writing: Planning a Project
A two-person bilingual writing team enabled a software application development group to produce on-line documentation and a user guide simultaneously in two languages. Team writing in an international environment requires detailed planning, constant monitoring, and continuous communication in order to succeed.
MacKay, Brenda. STC Proceedings (1994). Articles>Project Management>Localization>Collaboration
#23622
This paper identifies challenges for obtaining managerial buy-in for a user-centered design process using performance tasks. Initially, it presents lessons learned from a case study. Next, it provides strategies (leadership, persuasion, organizational conflict, active listening, and teamwork) for obtaining buy-in from work team and their constituencies. Last, it concludes with recommendations for obtaining buy-in from managers.
Carey, Jennifer and Gloria A. Reece. STC Proceedings (2003). Articles>Project Management>User Centered Design
#22137
Change Management For Content Management Projects
A content management initiative is a lot about change--changing the way people think and work. Ensure that you have a change management plan in place. If you have change management personnel in-house, get them involved in your project as soon as you make the decision to adopt a content management initiative. If you don't have change management personnel, consider hiring consultants who specialize in change management.
Rockley, Ann. STC Hoosier (2004). Articles>Content Management>Project Management
#28599
A CIO's Playbook for Adopting the Scrum Method of Achieving Software Agility
Scrum is a proven, Agile software management method that has been widely adopted by organizations seeking to reliably deliver higher quality software. Scrum is a simple process: it has a small set of interrelated practices and rules, is not overly prescriptive, can be learned quickly and produces productivity gains almost immediately.
Schwaber, Ken, Dean Leffingwell and Hubert Smits. Rally Software Development (2007). Articles>Project Management>Agile>Scrum
#28612
A CIO's Playbook for Adopting the Scrum Method of Achieving Software Agility
Provides a brief overview of the Scrum method as well as 'playbook' of guidelines and tactics for enterprise-wide adoption of Scrum.
Schwaber, Ken, Dean Leffingwell and Hubert Smits. Rally Software Development (2006). Articles>Project Management>Agile>Scrum
#19891
Collaborating in Project Management, Long-Distance
From early 1993 through July of 1994, three STC chapters jointly managed a research project on Technical Communication in Western Canada. Based in Winnipeg, Calgary and Vancouver, the managers were thousands of miles apart, relative strangers and simultaneously engaged in running their own businesses. In this volunteer assignment, they involved committees within their own chapters. As team building and collaborative arrangements become more prevalent in technical communications projects, it can be instructive to look at how such a farflung research project fared. We will relate this experience briefly to some research results reported in Technical Communication.
Jones, Sheila C. STC Proceedings (1995). Articles>Project Management>TC>Collaboration
#28921
Every project has its own unique set of 'opportunities'--also known as challenges. Many of these challenges relate not to the quality of our work, but rather to the communication of our ideas. Often in the course of design, you must communicate complicated concepts to a non-technical (and often uninterested) project sponsor, client, or stakeholder. So how do you capture their interest, get their understanding and buy-in, and finally move on?
Sedaca, Rebekah. Boxes and Arrows (2007). Articles>Project Management>Collaboration>Technical Illustration
#18651
A postmortem is a meeting of all members of the project team at the end of the project to identify what went well and should be repeated on future projects; and what did not go well and how to avoid these situations on future projects. In addition, the postmortem should provide time for the members of the project team to thank one another for their contributions. Often during the course of a project, team members become so comfortable working with one another that they do not thank each other for their contributions or acknowledge exceptional work. As a result, team members might not realize that their colleagues appreciate their contributions. The postmortem provides a formal opportunity for team members to offer one another such recognition.
Carliner, Saul. STC Northeast Ohio (2002). Articles>Project Management>TC
#31975
Conducting Effective Team Technical Reviews
Mention team technical reviews to a group of tech writers and chances are good that you will either get a loud, collective groan, or the group will vie to tell the best review horror story. On the one hand, technical reviews are a vital part of our jobs because they help us to produce high quality product documents. On the other hand, technical reviews gone wrong are the bane of our existence. The good news is that we have the power to conduct consistently effective technical reviews. This article summarizes why we do reviews and what often goes wrong in reviews, and then summarizes steps to take before, during, and after technical reviews that can help you conduct effective team technical reviews. Although your process and team may differ from what's described here, you can apply the information in part or in whole to improve your current review process.
Brown, M. Katherine 'Kit'. TECHWR-L (2008). Articles>Project Management>Collaboration>Assessment
#28563
Content Management and the Need for Change in Technical Communication
Many technical communicators find it difficult to manage all of the corporate content that their organizations create. Learn how CM can work for you by providing value to your organization as well as your customers and shareholders.
Abel, Scott. Intercom (2007). Articles>Content Management>Project Management
#30343
Control Costs of Translation with Advance Plan
The liability of a translated manual is several times greater than the English version. This increased liability can be tied directly to the accuracy of the translation.
McBride, Bill. Boston Broadside (1993). Articles>Language>Translation>Project Management
#18918
Every piece of user research is part of an ongoing research program, even if that program is informal. However, making a program formal provides a number of advantages: It gives you a set of goals, a schedule that stretches limited user-research resources, and results when they're needed most. It also helps you avoid unnecessary, redundant, or hurried research.
Kuniavsky, Mike. Adaptive Path (2003). Articles>Project Management>Usability
#29338
Dealing With an IT Scourge: Process Documentation
In this article, we outline how IT analysts can effectively make determinations about the value of process documentation, and in the process, transform a potential scourge into a possible blessing.
Schiesser, Rich. TechRepublic (2005). Articles>Documentation>Programming>Project Management
#27211
A potentially deadly illness, clinically referred to as UML (Unified Modeling Language) fever, is plaguing many software-engineering efforts today. This fever has many different strains that vary in levels of lethality and contagion. A number of these strains are symptomatically related, however. Rigorous laboratory analysis has revealed that each is unique in origin and makeup. A particularly insidious characteristic of UML fever, common to most of its assorted strains, is the difficulty individuals and organizations have in self-diagnosing the affliction. A consequence is that many cases of the fever go untreated and often evolve into more complex and lethal strains.
Bell, Alex E. Queue (2004). Articles>Project Management>XML>UML
#22115
Deciding What Needs to be Done
Before you begin editing a document, you need to analyse it and plan what needs to be done. The exception is when your job is strictly limited (by your supervisor or the client) to correcting only the glaring errors of spelling, punctuation and grammar (a 'light edit'). There is no point to attempting a more substantive edit if doing so will only get you into trouble (or if the client won't pay you for the time you spend).
Hollis Weber, Jean. Technical Editors Eyrie (2001). Articles>Editing>Project Management
