Your SlideShare is downloading. ×
How to write_well_(enough)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

How to write_well_(enough)

139
views

Published on

Slideshow for the presentation How To Write Well (Enough) given at Rochester Spectrum 2014. Thank you for your attention and feedback!

Slideshow for the presentation How To Write Well (Enough) given at Rochester Spectrum 2014. Thank you for your attention and feedback!

Published in: Business, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
139
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. How to Write Well (Enough) to Keep Your Projects on Track Kim Chmielewicz Rochester Chapter
  • 2. Why discuss project documentation? 4/17/2014 2How To Write Well (Enough)  Very often, technical writers’ unique perspectives and overview of details = effective business analysis (many of us eventually become project managers, whether PMI-certified or not)  Appropriate business analysis drives successful project management, as does summation of trends, the ability to pull together knowledge from many different sources, and the expression of complex ideas in easy-to-understand terms (hmm, sounds a lot like technical communication!)  The marketing flair inherent in making a compelling argument is also helpful when it comes to promoting projects, too!
  • 3. Project management parallels content management 4/17/2014 3How To Write Well (Enough)  Content management = a methodology of organizing documents by topical areas, rather than by creating static books or manuals  Recombination of appropriate topics creates documents that are geared to different audiences (e.g., technicians and end users)  Revision and editing only requires changing one instance within a topic in a content management system, thus making it much easier to focus on keeping content current rather than changing many references to a topic in different formats  The ideal way to create, compile, and maintain project documentation for the part-time manager is to utilize a content management approach; think of documents as information segments that can be repackaged for various needs
  • 4. Editorial considerations 4/17/2014 4How To Write Well (Enough)  Most project management documents are internal, so formal syntax is not required  Create concise reports of events by summarizing one event per line (more on this later), instead of one document per event  Write for your audience, who are probably juggling multiple responsibilities like you do and just need to know essentials  The project manager should oversee the initial charter/plan, but solicit input from other team members (set up simple templates)  Most project documentation can be saved to a central location (such as a wiki) and updated by project participants as needed  Project management software should be set up to be as simple as possible; spend extra time when setting up terminology/tasks
  • 5. 8 documents to (selectively) utilize 4/17/2014 5How To Write Well (Enough) 1. Project charters 2. Project plans 3. Goal logs 4. Approval/dependency tree 5. Risk logs 6. Issue logs 7. Action/agreement logs 8. Progress reports
  • 6. 5 Steps: Project Development 4/17/2014 6How To Write Well (Enough) 1. Project Charter: goals, scope, sponsors/stakeholders, schedule 2. Requirements: specific technical requirements, test for success 3. Schedule: task sequence and dependencies, resource allotment 4. Maintenance Plan: transfer from creation to operation 5. Lessons Learned: good points, improvements, surprises Note how the names of all 5 steps conveniently reference documents, thereby proving that documentation is crucial for project management success! My suggestions reframe the 5 steps to give you ideas for adapting your documentation plan to your particular circumstances or needs
  • 7. Project Charter 4/17/2014 7How To Write Well (Enough) IDEAL: Completely develop the problem statement and business case that inform project goals to create a solid foundation for both your project and your documentation  With such a base, your goals will demonstrate the ultimate value of your project clearly, keeping your scope manageable and hence increasing the likelihood that your project finishes on schedule and that your management acumen is appreciated!  Without demonstrable value, it is very difficult to gain project momentum  Research, write, and revise to be both clear and compelling
  • 8. Project Plan 4/17/2014 8How To Write Well (Enough) IDEAL: Plans may be integrated with the charter or stand alone  Include the scope, tasks to be completed, the team members who will complete those tasks, and relevant cost/time assessments that will be integrated into existing work schedules to complete your project  Again, as with the project charter, gather as much information and detail as possible to make your plan realistic, including conducting interviews with team members, checking with any outside contractors who may be involved, etc.  Try to be as accurate as you can be!
  • 9. Goal Log 4/17/2014 9How To Write Well (Enough) IDEAL: Goal separation from the project to simplify review  Create specific goals to permit a good understanding of solutions that are being addressed by the current project  Additionally, a separate goal log makes goals more visible to team members completing project tasks  For each goal, translate abstract wishes into specific actions, which may then be broken down into even smaller tasks  Effective goal setting will enhance your ability to create a realistic project plan, too!
  • 10. Approval/Dependency Tree 4/17/2014 10How To Write Well (Enough) IDEAL: If many signoffs are required to initiate action, the approval tree is a helpful tool for reminding team members about their obligations to review/refine projects tasks and actions on a regular basis  A dependency tree may also ease the transition from project completion to operations by tracking tasks that can be streamlined and completed simultaneously  Therefore, by tracking approvals and dependencies separately, you will increase the relevancy of project work by identifying places where there are lags during your project, which may simplify developing processes that deliver products/services
  • 11. Risk Log 4/17/2014 11How To Write Well (Enough) IDEAL: List any possible roadblocks to progress that exist and anticipated solutions  Also note the impact on your project if the listed risks should occur  The risks may be listed as part of project requirements, similar to goals being integrated into a project charter, but a separate listing makes for quicker reference and faster updates  A line per risk with the three variables (roadblocks/solutions/impacts) is sufficient; remember, one line per event, not one document per event!
  • 12. 4/17/2014 Kim Chmielewicz 12 Risk Log Sample: SGML to HTML manual conversion Project Stage Risk Name Description Potential impact Projected solution(s) Initial manual review Outdated graphics Component parts updated by supplier Inaccurate illustrations may mislead techs Check IPL for reworked components Word to SGML conversion Misaligned tables Tables have dangling misaligned cells Tables may require retagging Edit tag code in TextEdit to adjust prior to conversion SGML to HTML conversion Missing symbols Symbols absent or replaced Ranges of instruments may be misread Retag symbols using EpicEditor menu guide HTML delivery Garbled file Missing sections or out of order Manual is unreadable Test view files in different browsers NOTE: This risk log was composed following an initial test assessment of the conversion process. Other risks were added as work progressed and other potential issues came to light.
  • 13. Action/Agreement Logs 4/17/2014 13How To Write Well (Enough) IDEAL: Action/agreement logs are less complex and more streamlined solutions to use instead of project minutes  The logs create a single reference point and can be referred to easily, and contradictions highlighted, as project work proceeds  Action logs can be very helpful to use for projects in which many small, simultaneous tasks must be completed and tracked  Agreement logs also assist in keeping track of agreed-upon solutions  List dates, a simple description of the action or agreement, and who participated in the discussion
  • 14. 4/17/2014 Kim Chmielewicz 14 Action Log Sample: SGML to HTML manual conversion Project Stage Action Name Description Actors Action(s) taken Initial manual review Brief initial review Quick check to update components, edit, clarify Kim Jan Resaved source files Created new graphics Word to SGML conversion Realign tables Tables have dangling misaligned cells Kim Betty Retagged tables Edited DTD script SGML to HTML conversion Post- conversion review Recheck HTML file against Word file Kim Sharon Distributed latest copies Marked new edits HTML delivery File delivery Submit file to online library for use Kim Set chapters, zipped files, downloaded NOTE: This action log reflects a set procedure for manual conversion, so dates could be added to reflect when work is actually completed for each manual within this project. Listings with dates can be added in for unplanned steps as they are completed.
  • 15. Progress Report 4/17/2014 15How To Write Well (Enough) IDEAL: To create a progress document, incorporate relevant aspects of risk, action, and agreement logs instead of maintaining a separate report  Maintaining the three logs as separate documents may make it easier to record specific entries more quickly rather than wrestling with the somewhat abstract concept of “progress” when writing a report  If necessary, you can further illustrate progress by incorporating an assessment of overall project status and milestone progression in addition to the listings extracted from the risk, action, and agreement logs
  • 16. The “6th Step”: Document Analysis 4/17/2014 16How To Write Well (Enough) IDEAL: Document analysis should support two main goals: 1. A smooth transition from project tasks to operations; and 2. A realistic assessment of how well the project was planned and executed  Look for trends in issues that came up and how closely they correlated to anticipated risks  If issues and risks are not a corresponding set, check the actions/agreements taken to see how they may have headed off certain problems or created unanticipated issues during the project process
  • 17. Document Analysis - cont 4/17/2014 17How To Write Well (Enough)  Confirm how robust the original project charter and plan were, both to see if appropriate team members were included as well as creating doable tasks and milestones based on goals  Goals should have been closely correlated to your milestones in order to enhance the correlation between your project tasks and the desired end result of your project  Did waiting for approvals and prerequisites prevent team members from completing their tasks?  Examine with the eye of an archaeologist (recreating a project process) rather than as a forensic specialist (assessing as a means of assigning blame) to keep morale up!  May also be included in maintenance plans or lessons learned
  • 18. Takeaways 4/17/2014 18How To Write Well (Enough)  Essential documents should include a project charter, a project plan, and action and agreement logs, which may both be combined into progress reports when necessary  Extra time should be spent developing the documentation at the start of your project both to create a clear expectation of the work leading to completion and make content management easier  You may be able to spend only once or twice a week updating your action and agreement logs once your project is set up  However, you may find it more natural to sit down at the end of each day and summarize what has been done on your projects dependent on what is completed each day – it’s up to you!  Logs permit quick entries without wrestling with format
  • 19. Takeaways - cont 4/17/2014 19How To Write Well (Enough)  Simple Word documents and Excel spreadsheets work just fine for logging purposes  Take time to consider what information is most relevant to you and to your team/organization to record when setting up your project documentation  Keeping regular records in a consistent manner that is natural for you will be key to your project management success  Think of creating documentation as an opportunity for you and your team members to market yourselves by highlighting the value your project work brings to your organization!
  • 20. References 4/17/2014 20How To Write Well (Enough)  My email is Mhcmik@aim.com if you have additional questions on this presentation or about how to create documentation  For more information on content management, I recommend taking a look at the website for the Society for Technical Communication at www.stc.org. Much of the content is open for viewing by non-members, and includes seminar recordings as well as interesting articles – check it out!  Thank you for your attention – hopefully I’ve given you some ideas for how to develop more manageable project documentation. Happy writing!