Who Likes Documentation? - Why It’s Worthwhile to Document Your Projects
As a project manager, what do you think of when you hear the word "documentation?" Unfortunately, the "D word" often conjures up grim visions of dry, meaningless technobabble that gets a quick skim from our project sponsors and team members and ends up collecting dust in three-inch binders on a far corner of our desks. This doesn’t have to be the case. And while there may be an infinite number of things that could be documented for a project, we’ll discuss six basic templates that can stimulate productive conversations among project teams and supplement the project management methodology you already have in place.
The Statement of Work (SOW)
Purpose: The SOW defines all of the core components of the project, confirming where the team expects to be when the project is complete and how to manage the effort along the way to ensure the project is successful. The granularity of the document often parallels the complexity of the project; the more risky and unfamiliar the project, the more detailed the SOW. Some organizations call this document a project charter.
Value for the project manager and project team: You’ll start early to identify and document potential risks, constraints, assumptions, expenses and scope threats. The point is to plan the work before you start working. Roles and responsibilities for each team member and third parties should be clearly outlined. The SOW also serves as a great orientation document for team members who join the project in progress. When the information is on paper, or even in an electronic format, it is harder to avoid or forget (or deny), and the milestones provide a ready-made, chronological outline for the next key project document, the project schedule.
Design suggestions: The questions you naturally ask as a newly assigned project manager translate well to section headings in the SOW. You are essentially drafting the document as you meet with one or more team members to gather information.*
Consider this:
- Require team review and discussion, ideally in a face-to-face meeting, prior to finalizing the SOW. Each team member should have an opportunity to provide edits and ask questions.
- Include a section for formal sign-off if the project is particularly controversial.
- Engage the project sponsor at this point, so he or she is on board early.
- Consider pairing the SOW with a vendor contract as an addendum during contract negotiation.
- Contracts often do not include work assignments, timetables and acceptance points in detail.
The Project Schedule
Purpose: The project schedule is a breakdown of work that must be completed in order to deliver the project milestones you identified in the SOW. You will identify action items that are assignable to named resources and sort them in chronological order based on predecessor relationships and logical workflow.
Value for the project manager and project team: This document maps out the work ahead and clarifies how team members will work together. The schedule serves as a negotiating tool for resource managers to allocate assignments to staff and identify potential staffing deficiencies and conflicts. It increases management awareness of the extent and level of work required for even "small" projects. The schedule also provides status points and conversation topics for meeting agendas.
Design suggestions: Include the following in the project schedule: task number, task description, percent complete, start date, finish date, name of assigned resource(s) and comments/notes (this field can be used to reference related documentation or technical information, status updates and relationships with other tasks).
Consider this:
- To ensure accountability, avoid assigning tasks to departments or job titles. Work with resource managers to identify specific individuals who will do the work.
- The assigned resources should provide the start and finish dates for their tasks whenever possible to help build buy-in. Confirm how they estimated the time frame to determine whether they were being conservative or including cushion time, so that you can level the overall schedule.
- Use a tool that is easy to access and interpret for all team members, both technical and nontechnical. The tool shouldn’t be an obstacle.
The Agendas and Minutes
Purpose: The agenda serves as a pre-meeting outline, while the minutes provide a post-meeting summary. The agenda serves as a reminder for a scheduled meeting and demonstrates that the person leading the meeting is prepared and focused. The minutes equate to an executive summary of the project meeting discussion.
Value for the project manager and project team: These meeting documents provide structure and pacing for the meeting, provide a source of information for team members who are not able to attend a meeting, help identify information that needs to be logged in other project documentation (project schedule updates, issues and lessons learned), provide a record of the meeting history and provide context for past decisions.
Design suggestions: Include the following in the agendas and minutes:
Agendas
- Include logistical information, such as the meeting location, room, time, time zone and telephone or Web information.
- Note team member speaking roles for agenda items (where applicable), so those team members can prepare beforehand. Consider the amount of time needed per topic.
- Send the agenda to participants a day in advance and bring hard copies to the meeting.
- Use the agenda as a valid excuse to politely interrupt off-topic conversations to ensure the meeting ends on time.*
Minutes
- Indicate who attended the meeting.
Consider use of a "parking lot" section of the minutes to note any topics that came up during the meeting that were related to the project but not related to the agenda items.
- Highlight summary points for each agenda item such as decisions, issues, status points and assigned action items.
- Ask a trusted advisor on the team to clarify or proofread the minutes before sending to the team.
- Send the minutes within 48 hours of the meeting, while the information is still relevant.
Save the minutes in a centralized location in the document management system.
- Use the action items in the minutes to create the agenda for the next meeting.*
Consider this:
Minutes should not equate to a complete transcript of the meeting. Keep direct quotes and emotion-based words to a minimum and, instead, use "we" and "the team" whenever possible.
Invite comments or edits to the minutes when you publish them to prevent omissions or misinterpretations.
Check the history log in your document management system to see who is accessing the information, and thank them!
The Issues List
Purpose: The issues list is a central place to log, prioritize and assign project issues.
Value for the project manager and project team: Issues can arise at any time and can become particularly critical during the execution phase of the project. Keeping issues separate from action items (in the project schedule) and project discussions (in the meeting minutes) gives them greater visibility, which is important when drafting the closure document during the post-project review.
Design suggestions: Include the following in the issues list: issue number, date reported, name of person reporting the issue, issue priority, issue type, issue description, issue status, name of resolution owner, description of resolution and date resolved.
Consider this:
The issues list can serve as a good starting point for test scripts and training documentation.
The Closure Document
Purpose: The closure document is an opportunity to confirm the project objectives as defined in the SOW have been met, the tasks defined in the project schedule have been delivered, and all items on the issues list have been resolved. The project manager should acknowledge the team’s accomplishments over the course of the project and index the primary deliverables for future reference in the project closure document. Both team strengths and opportunities to contribute to future projects should be highlighted.
Value for the project manager and project team: Building this document is a great way to spend your last meeting together as a team, reviewing feedback and sharing stories you solicited from the entire team beforehand. For more far-reaching projects, consider sending a survey to stakeholders outside the core project team.
Design suggestions: Include the following in the closure document: project sponsor, project manager, team members, third-parties/vendors/ consultant leads, document management system folder location/name/number, final project budget information (e.g., estimated, actual, total and percent of variance).*
Consider this:
Capture lessons learned during every phase of the project, not just at the end.
Discourage finger-pointing and name-calling.
Closing
Memories can be fleeting. When one project ends, the transition period to the next project can be very brief. Projects do have a tendency to recur in the form of technology upgrades, enhancements and replacements. Memorializing key information as document "artifacts" in a centralized location enables future project teams to benefit from your experience. Creating templates can also serve as a developmental exercise for your project management group. Getting feedback on document templates from team member focus groups is a win-win situation. Staff will be more willing to support a process they co-designed.
* Sample templates discussed in this article can be found at: www.iltanet.org/PDF/PMSampleTemplates.pdf.
About our author :: :: ::
Kristin Linoski, PMP, has over 10 years of project management experience in the financial and legal industries. She was the first project manager hired for Fulbright & Jaworski L.L.P.’s new project management office in Houston in 2005 and now manages the growing department. She has successfully managed system implementations, application upgrades, rebranding initiatives, development projects, professional development series and strategic committees, as well as developed project management training and orientation materials. She can be reached at klinoski@fulbright.com.