In Documentation Process and Content Management (ETWR 2477), you team-write chapters for simple tasks for a project-management application and take the documentation project from competitive proposal straight through to completion, moving through important phases such as initial proposal, team building, documentation plan, scheduling, prototypes, style notes, drafts, edits, revisions, and finished deliverables.
Your teams will divide into typical roles such as coordinator, writers, editors, and graphics specialists, although each team member regardless of role will write a chapter on a simple tasks for the application. Although your team is welcome to use whatever application you wish to schedule and track your project (typically an Excel spreadsheet), your documentation of simple project management tasks will show you a typical way projects are set up and managed. To develop your project collaboratively, please use a CMS like Google Docs.
Getting organized. In this first week, read about the schedule, policies, objectives, and requirements for this course (using links in the gray panel to the left and up). I'll ask you to fill out the online questionnaire below (your information will be kept confidential), write a brief get-acquainted memo that will be posted on our course website so we can all get know each other (it will also be password-protected), and fill out the skills, talents, preferences profiler so we can know how to set up teams!
Creating a blog with WordPress. You'll create a blog, open only to members of our class, in which you introduce yourself to the rest of us and summarize what you read about management of documentation projects.
Getting to know you. We'll fill out a profile questionnaire to get a sense of the group's strengths, experience, aptitudes, and preferences. We'll divide into one or two teams depending on your preferences. As instructor, I will act as subject matter expert for the project management application and as upper-level management to resolve disputes.
Reading Hackos. JoAnn Hackos's Information Development (2007) focuses on the process of developing information from a management perspective. Ideally, you would have read this book before this course began so that you could apply its principles. Sigh. While some of the chapters may match up with what you are doing or will do, with the rest perhaps you can say, "Oh well, we could have done it that way." The same in the case with Hackos's Content Management (2002).
Because few of us could read 1,000 pages in under 11 weeks, we'll divide the readings, summarize themi, and comment on each other's summaries. Keep in mind that you will be the expert on your chapters and may be asked for help on the details.
As you can see below, the chapters are grouped into nice 100-page sets. Use the randomizing program at the link below to find out what you'll read.
Use this week to complete your readings, summaries, and comments on others' summaries. I will evaluate your work on this unit according to the quality of your summary and the quality of your comments on all other summaries.
Developing team spirit. With the number of people we have in this course, we can break up into either or one or two teams. Use class e-mail to ask questions and voice your opinion, and then click Quick survey: fill out to indicate your preference.
Team blog setup. Create a blog for your team at WordPress. Have some fun—give your team a name (The Mighty Eggplants?) Create "pages" at your blog in which you describe team roles, due dates, and procedures to use for project problems (such as slackers, incompetents, ego conflicts).
Content management. Traditionally, project material is developed as separate "documents" (user guides, online helps, quick-start guides, product white papers, promotional materials, reference manuals, and so on). However, in content management systems, information is divided into resusable "topics." This approach cuts down on the necessity of rewriting the same material for different contexts and enables assembling the topics in different ways for different contexts. This is out of the scope for this course, but be aware of it.
PM Project. Read about the project and then use the task-assigner link below to find out which task you will be determining.
Project estimating. To get ready to write the project proposal, you will need to know how to estimate how many hours, people, and resources it will require.
Information-project proposal. Your job right now is to write a proposal that convinces your potential client that your team has the best plan for the project, has the best credentials, and projects the best financials—or, well, the best balance thereof.
Project tracking. Now that your team has won the contract to do the documentation project with that terrific proposal you wrote, it's time to do some serious project planning. And that means having a system to track your project. Big, complex projects involving lots of people typically require some tracking mechanism to show team members what's due when, who's doing what, and which project details have changed.
Information-development plan. One of the first items scheduled in your project plan should be the information-development plan (also known as the documentation plan), which records your team's decisions about items in the documentation library, media to be used by those items, and other elements such as schedules and responsibilities.
Style notes, templates, and prototypes. Ideally, your team would set up a style guide, templates, and a prototype. Actually, you need a template to enable everyone to produce material that is formatted the same way. If you were working in something like word, that would be a .dt file. In FrameMaker, it would be a simple .fm file. In HTML, it would a CSS file.
Formatting and editing. During this next period of the course, your team formats the information according to your plans, and someone on your team watches editorially for inconsistencies and other problems.
Formatting and editing — continued.
Editing complete and final drafts
Content management. If we had a good content management system, we would crop in all our information and experiment outputting it to web pages, PDF, and help. We would also experiment with taking different parts of our information and outputting them as well. This latter is known as "database publishing," which is implemented by Author-it.
Post mortem. When your team has completed the project, get together in some way to discuss how things went, what went wrong, what could have been better, what went right, and appoint a team member to post a summary of your meeting to your team blog in the Pages area. (This includes a post mortem on this course: how things went, what went wrong, what could have been better, what went right.)