A directory of resources inthe field of technical communication.

Articles>Documentation>Project Management

36 found. Page 1 of 2.

About this Site | Advanced Search | Localization | Site Maps
 

1 2  NEXT PAGE »

 

1.
#36726

Abby and the Broken Fence

There is a decision doc managers need to make all the time: balance savings today against expenses tomorrow; balance constantly patching a doc with tearing the whole thing down and starting anew. My solution to fixing my fence was the exact same I would have taken to patching a doc.

Raymond, Robert. Indus (2010). Articles>Documentation>Project Management

2.
#38632

Adjusting to Scrum   (peer-reviewed)

Scrum, the new development methodology in the Agile development family, is fast gaining acceptance in software development. But how can writers, who have little or no experience in any of the incremental development models, adjust to this methodology? And, how does the Documentation Development Life Cycle (DDLC) change in Scrum?

Bidkar, Prasanna. tekom (2011). Articles>Project Management>Agile>Documentation

3.
#36089

The Case of the Stolen Documentation

The non-writer who takes over the documentation can act like a bull in a China closet, copying and pasting from Word, mixing styles, not understanding the setup, basically wrecking the consistency, the bullet levels, the formatting. If you see the documentation later and find that the client has added steps without numbers, included text that breaks every rule in the style guide, won’t that be unnerving? Yes, it will make you want to jump out the window.

Johnson, Tom H. I'd Rather Be Writing (2010). Articles>Documentation>Project Management>Collaboration

4.
#29338

Dealing With an IT Scourge: Process Documentation   (members only)

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

5.
#37400

Developers and the Missing Help File

Sometimes our developers are just a bit too eager. It doesn’t happen that often but when it does, it takes us Technical Writers by surprise. One such occasion happened today when the first build was created for the next release of one of our applications. No real issue there, but when they came to us half an hour after the build process completed to say the help didn’t look right, we went to investigate.

McAndrew, Colum. RoboColum(n), The (2010). Articles>Documentation>Programming>Project Management

6.
#24703

A Documentation Database for Managing Time and Costs   (PDF)

Keeping track of a technical writing team’s time can be a tedious task, especially when that time has to be charged to various internal departments. Using Lotus Notes™ (Lotus Development Corporation and Iris Associates, Inc.), we developed a relational database to track this information. This database uses a single form for all documentation status inputs. Then it summarizes the data in a variety of view. Separate forms track SEI statistics and simplify department employee time administration.

Lang, Darice and Debra Ricks. STC Proceedings (1994). Articles>Documentation>Project Management

7.
#31035

Documents That No Project Cannot Be Without

Short deadlines force project teams to quickly design, test, and release the product with little or no design documentation. If these documents are written, they generally are not well-written and are not comprehensive. The fact of the matter is that most project teams do not have enough staff to design the product, let alone write and manage documentation. This situation creates an ideal opportunity for technical writers to assist the project team in more ways than writing a user guide.

Dick, David J. Carolina Communique (2008). Articles>Documentation>Project Management>Collaboration

8.
#24241

Easy Tools for Documentation Management   (PDF)

The use of three simple tools can assist the documentation manager, from start to finish, on any new project. A revamped pubs plan, a new concept with engineering worksheets, and a matrix of modularized information are all utilized with a slightly new twist. The Pubs Plan is redefined to help you launch your project with a team approach, identifying issues, and proposing solutions. The Engineering Worksheets list all the critical pieces of information your writers/illustrators need for each component of the product. These pieces of information are then tracked by completion date on an Information Matrix. These documents work together as complimentary management tools that can be easily developed and scaled to the complexity of any project.

Shumate, Chona E. STC Proceedings (1999). Articles>Documentation>Project Management

9.
#21351

Estimating Scope and Schedule for a Help Project   (PDF)

During this session, we will learn how to create a topic list to determine project scope, and then we will begin to calculate how long it will take produce all of these topics. When we’re done, you will have a methodology for doing this for your own project.

Deaton, Mary M. STC Proceedings (1997). Articles>Project Management>Documentation>Help

11.
#20787

A Guide for Software Project Managers - Planning User Documentation   (PDF)

A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–2000 Edition is the main sourcebook in the project management field. Whilst it covers Project Communications Management, it doesn't extend to user documentation. This article seeks to provide guidance for project managers as to how the user documentation process fits in with the overall project planning. It examines: the traditional way documentation is approached and how it impinges on project planning the effects of making changes to this traditional approach.

Johnston, Carol. Cherryleaf (2003). Articles>Documentation>Project Management>Body of Knowledge

12.
#30314

How to Plan On-line and Paper Versions of a Software Manual

On projects for which you must produce both on-line and paper documentation, there are many things you should consider before you start.

Kozuma, Bruce. Boston Broadside (1991). Articles>Documentation>Project Management>Planning

13.
#24451

Improving Publication Quality Through Project Management   (PDF)

A methodology for developing high-quality software developed by the Software Engineering Institute at Carnegie-Mellon University can also be applied to developing technical publications. This workshop addresses several aspects of this methodology using various project management techniques. By bringing your development process under better control, these techniques will ensure a more uniform quality in your publications.

Firman, Anthony H. STC Proceedings (1995). Articles>Project Management>Documentation

14.
#30510

Information Metrics: Keeping Your Writing Projects On Track   (PDF)

Keeping information metrics for documentation projects gives managers the ability to more accurately estimate future projects. Publications departments can develop their own tools or they can use existing tools to track such things as page size, hours-per-page spent writing, illustrating, editing, and producing manuals; and the dependencies of each manual. This kind of information can help to determine development schedules, show how late changes affect the documentation process, and accurately determine what it will take to complete quality documentation on time and within budget.

Gordon, Judy L. STC Proceedings (1993). Articles>Documentation>Project Management>Methods

15.
#31715

It's In the Numbers: Using Metrics to Plan Documentation Projects

It's in the numbers. Creating documentation is not an exact science, yet as communication leaders, we are expected to provide real estimates for how much time we need to document a project, or what we can produce given a predetermined timeline.

Yundt, Margie and Sherry McMenemy. Writing Assistance (2006). Articles>Project Management>Documentation>Assessment

16.
#24903

Juggling or Struggling: The Art of Managing Online and Hardcopy Documentation   (PDF)

While company budgets are increasing little or none, the responsibilities of technical writers continue to multiply as they are expected to produce online help as well as hard-copy documentation in short time periods. This demonstration explains how technical writers at Computer Power, Inc. produce usable online and hard-copy documentation from one source file. Participants will learn how to plan the file, create appropriate graphics, and use macros to convert text and other information for use in online help.

Bates, Michael P. and Catherine Cooper. STC Proceedings (1995). Articles>Documentation>Project Management

17.
#29349

Manage the Document Life Cycle for the Important Documents on Your Project   (members only)

Not all documents require a full lifecycle, but if you understand the nature of building documents, you will be better able to plan for the time required to complete them successfully.

Mochal, Tom. TechRepublic (2005). Articles>Project Management>Documentation

18.
#35530

Managing a Documentation Project Successfully: More Jelly and Ice Cream

This video on simplifying business, using the metaphor of organising a children’s party, made me smile and consider how successful documentation projects are managed. The presenter is suggesting managers need to, in complex systems, give up rigid control from above. Instead, they should watch for organisational patterns, encouraging the good and discouraging the bad.

Pratt, Ellis. Cherryleaf (2009). Articles>Management>Documentation>Project Management

19.
#22621

Managing and Documenting Your Project, XML Style

Here are links to the listings described in Managing and Documenting Your Project XML Style.

Fisher, Timothy. XML Journal (2003). Articles>Documentation>Project Management>XML

20.
#22602

Meeting Crazy Deadlines

We are all against bonded labour and slavery. I ask you: are software professionals (including technical writers), better off than slaves and bonded labourers?

Kamath, Gurudutt R. IT People (2003). Articles>Documentation>Project Management

21.
#36844

Planning a Doc Sprint

A “doc sprint” is similar to a book sprint. We called ours a doc sprint because it focused on technical documentation and on developing a set of tutorials, rather than a single book. We invited a number of developers to join the technical writing team in a three-day sprint, with the aim of producing some quality tutorials on gadget and plugin development.

Maddox, Sarah. ffeathers (2010). Articles>Documentation>Collaboration>Project Management

22.
#36607

A Process for Developing Regular Release Notes

In my project portfolio, our release manager—the one who instituted release scrums—wants to standardize on release notes across applications. Many of the projects are in a maintenance period, so releases are planned for each project every month or two on something of a rotating basis. These releases will include small enhancements and bug fixes. One of the challenges of standardizing on release notes is coming up with a release notes process that can efficiently turn out these documents within about a week.

Minson, Benjamin. Gryphon Mountain (2010). Articles>Documentation>Project Management>Scrum

23.
#36766

Single Sourcing and Small Projects

Single sourcing is used successfully for large documentation projects thousands of pages or help topics. However, single sourcing is not useful for most small documentation projects.

TechScribe (2007). Articles>Documentation>Single Sourcing>Project Management

24.
#30262

The Six Biggest Mistakes Project Managers Make with Documentation and How to Avoid Them

Professional business writers, such as technical authors, typically break a document down into small, discrete units of information, organised around a skeleton of topic headings. If you use this 'component' or 'modular' approach, you can plan and structure the document using the heading 'labels' that describe each section.

Pratt, Ellis. Cherryleaf (2007). Articles>Documentation>Planning>Project Management

25.
#29415

Teamwork and the Product Documentation Process

Get to know your new teammates. Get to know your audience. Define the product's features. Create a mockup of the user interface. Begin to document the features and interface.

Hart, Geoffrey J.S. Geoff-Hart.com (1997). Articles>Documentation>Project Management>Collaboration

 
 NEXT PAGE »

 

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon