Project Management is the discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives.
#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
#22568
Computer to Plate Basics Explained 
In Europe and the US, Computer to Plate (CtP) seems to be a fast growing market. In some areas of the print market the majority of printers have already made the transition from traditional plate techniques to CtP. The reason why is easy to see: CtP gives almost instant colour register on the press, and there is no need to worry about stopping the press for removal of dust marks and scratches that sometimes would plague traditional film.
IT Enquirer (2009). Design>Project Management>Prepress>Printing
#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
#21772
A template to provide a brief description of the project. It should outline the objectives, audience, and assumptions for the project and details the creative concept the team intends to use moving forward. This document should accompany the materials for the Conceptual Design Review. Information should be filled in to give an overview to project reviewers who may not be intimately involved in the project. Differs from project overview in that this is specific background information related to design constraints, concerns and other information directly relating to the solution presented for review. The Creative Brief can also be used to inform outside firms about a project when brought in for consulting.
Malone, Erin. AIfIA (2003). Resources>Project Management>Workflow
#18675
Critical Thinking in Design Part 3: Project Management
Designs must be realized to change the world. How does project management intersect with the challenges of design? How can a manager enable great designs to reach the customer?
Berkun, Scott. UIWeb (2001). Design>Project Management
#27569
The first and most basic rhythm of the Agile feedback cycle is the daily standup. It's just what it sounds like - a daily meeting where everyone stands up for the duration of the meeting. When I give Agile workshops, one of the questions I'm often asked is how to do daily standups when the teams are geographically dispersed. While this can be a challenge to coordinate and maintain, you'll soon find that the benefits of the daily communication make it well worth the effort. Here are several options to consider with your team:
Sliger, Michele. Rally Software Development (2005). Careers>Project Management>Agile>Collaboration
#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
#22152
Demystifying Information Modeling
The information model is a framework for organizing all the information people need.
Hackos, JoAnn T. ComTech Services (2002). Design>Information Design>Project Management>Metadata
#27289
The Design and Development of a Project-Oriented Information System 
In this paper, the idea of building a project-oriented information system based upon a specialized information database was discussed. It attempts to provide tools for helping researchers use Internet resources effectively in the course of their research. Based on this idea, a web-based project-oriented information system was constructed. The paper systematically expounds the design and development process of the project-oriented information system. Furthermore, examples of utilizing the project-oriented information system to obtain useful information and suggestions for specific projects were described. According to our discussion and utilization of the system, we believe that building a project-oriented information system can help researchers with their research projects.
Zhao, Yuehong, Chao Liu, Hao Wen, Hezhen Zhang and Zhihong Xu. Data Science Journal (2003). Articles>Project Management>User Centered Design
#21776
Useful checksheets with questions for consideration by the design team and reviewers when reviewing work at different stages of the process. There is a checksheet for Concept review, UI/interaction design review and Visual design review. Has space indicated for approvals and signature sign off by selected approvers. These sheets are great for tracking the progress and making sure key people approve and sign off on each step.
Malone, Erin. AIfIA (2003). Resources>Project Management>Workflow
#21775
A template to capture the dates in the Design Review Process and key milestones and stakeholders.
Malone, Erin. AIfIA (2003). Resources>Project Management>Workflow
#21774
The Design Scope template should outline the general aims and goals of the project design and lists the major deliverables and milestones. To be completed by the experience design team lead.
Malone, Erin. AIfIA (2003). Resources>Project Management>Workflow
#28405
'Design' encompasses a very wide spectrum of disciplines and applications, which address an enormous range of different problems. When designing a product, the techniques and priorities a designer should use change according to its purpose.
Hunt, Ben. Web Design From Scratch (2006). Design>Project Management>Methods
#21751
Designing for Limited Resources
When resources are limited, the design must be optimized to make the best use of all resources. To account for this complexity, it is important to have a clear understanding of both sides of the design equation—what you have to work with and what you are trying to build.
Quinn, Laura S. Boxes and Arrows (2004). Design>Web Design>Project Management
#26345
Designorati:Strategy covers the strategic as well as the tactical technology influences and decision-making found throughout the creative and production workflows, from content conception through to content distribution. Who is the customer? What is the message? How do they want to receive the message? What methodology will you use to deliver it? Was it successfully received? Did the customer act on it? Strategy will encompass infrastructure, workflow, services, production, mangement, new technologies, and some “how to.” Strategy will focus on industry trends that will impact the growth of your company and how you integrate with your strategic partners. Stories will include everything from strategic technology planning, to creative/production workflows, how “best in class” products affect disciplines of all size and manner, lean principles, performance improvement and much more. Who is the Strategy audience? Everyone that makes a technology decision or influences a technology decision will find something worthwhile here to consider. The technology, workflow, and services of the creative and production environments of content publishing affect all of you.
Indiano, Cate. Designorati (2005). Resources>Project Management
#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
