Search: Help | My Account 
ProjectConnections Print View
ProjectConnections Print View
.applemenu{margin: 5px 0;padding: 0;width: 170px; /*width of menu*/border: 1px solid #9A9A9A;}.applemenu div.silverheader a{background: black url(http://www.projectconnections.com/images/leftnav-orangegradient.gif) repeat-x center left;font: bold 8pt Tahoma, "Lucida Grande", "Trebuchet MS", Helvetica, sans-serif;color: black;display: block;position: relative; /*To help in the anchoring of the ".statusicon" icon image*/width: auto;padding: 6px 0;padding-left: 8px;text-decoration: none;}.applemenu div.silverheader a:visited, .applemenu div.silverheader a:active{color: white;}.applemenu div.selected a, .applemenu div.silverheader a:hover{background-image: url(http://www.projectconnections.com/images/leftnav-yellowgradientover.gif);color: black;}.applemenu div.submenu{ /*DIV that contains each sub menu*/text-align: left;background: white;padding: 5px;margin-left: 3px;/*height: 300px; /*Height that applies to all sub menu DIVs. A good idea when headers are toggled via "mouseover" instead of "click"*/}ul.submenuList {padding: 0; margin: 0 0 0 9px; *margin-left: 14px; font: normal 8pt Arial;}.subMenuTitle {font-family: arial,tahoma,verdana,sans-serif; font-size: 9pt; color: #2b2b2b; background-color: #fff;}
Key Resource AreasPMBOK® Guide IndexKnowledge AreaProcess GroupRole Fast TrackNew Project ManagerBusiness AnalystProject Management Office or Organization LeaderBurning QuestionsProject TeamObjectives, Scope, Requirements & WBSProject Planning & Trade-offsScheduling, Estimating & BudgetingRisk & Issue ManagementQuality Assurance, Control & ManagementExecution, Tracking & ControlChange Control & Configuration ManagementCommunicating; status, reporting, meetings & moreCommitment, Approval & CelebrationRelease, Delivery & Lessons LearnedPersonal EffectivenessDocumentationPeople Skills & LeadershipLeadershipTeam BuildingVirtual Teams & Vendor/Partner ManagementConflict and Issue Management Communicating: Status, Meetings, Reports & DocumentationAgile Project ManagementAgile TechniquesAgile Articles, Papers & PresentationsImplementing AgileAgile MethodsAgile Blog Posts from Project PractitionersProject Phase ResourcesConcept & SelectionInitiation & PlanningExecution & ApprovalDelivery & CloseoutAll Templates & ResourcesTemplate BundlesView AllMeeting Management & Running Effective MeetingsProject Closeout and "Lessons Learned"Project Kickoff BundleProject Planning and SchedulingProject Planning and TrackingProject SelectionProject Status ReportsProject Test PlansSoftware Requirements Capture and ManagementHow-To CoursesView allAgile Development: Core MethodsAgile Methodologies: Overview of ScrumAssessing Project RisksCommunicating Up the Chain to Resolve Big IssuesDeciding How to Respond to RisksGetting the Right Project Team, the First TimeGetting Started with New PM TechniquesIdentifying Project RisksLeadership from Every Seat at the Project TableOverview of Agile DevelopmentPlanning the Project When Things Are UncertainThe Project Plan, and the Process to Get ThereRecognizing and Dealing With a Lack of Urgency for Meeting DeadlinesRewarding, Recognizing, & Energizing Your Team MembersSpeaking Up! Influence Skills for Getting What You NeedStaying In Touch and Staying In SyncStopping the Endless Requirements GatheringTracking and Managing Virtual TeamsWhich Project Leadership Hat Should I Wear This Week?WebinarsView allBusiness-Driven Project FocusFirst Five Traits of Risk Management ExcellenceSecond Five Traits of Risk Management ExcellenceCritical Influence Skills for Project ManagersLittle ITIL®, Big ResultsPass It On: Delegation Skills for LeadersProject Leadership & Change Management: What Really CountsProject Planning from an Agile PerspectiveTrying Out Agile One Project at a TimeNewsletterCurrent NewsletterNewsletter ArchiveGot a Question?Drop us an email, or call us toll free:888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.
Learn more about ProjectConnections and who writes our content.Want to learn more? Take a site tour.
Site Help Newsletter
PM Articles > Kent McDonald > The Benefits and Costs of Documentation
The Benefits and Costs of Documentationby Kent McDonald
I have been working in a project environment for over 15 years, first as an application engineer and program manager for an automotive parts manufacturer, then as a business analyst, project manager, or program manager in a variety of information technology projects. What is the common denominator in all these projects? Documentation. My role on most of those projects could easily appear to be all about producing documentation. On top of that, I love writing, one of the reasons I write this column. So you would think I would be a huge advocate for producing documents on projects.
I am not.
Don't get me wrong, project documentation has benefits, when done correctly. Project documentation also has costs which are often exacerbated by the amount of documentation teams choose to produce, the way in which they produce it, and the way they use it. At its core, project documentation exists to aid communication and to serve as institutional memory. Many project teams run into problems when they start believing that documentation is intended to be the main form of communication, the primary storehouse of knowledge about the project, and a means of tracking progress in the project.
Piling these different expectations on project documentation leads teams to produce more documents than they really need, produce them in inefficient ways, and place way more importance on their completion that is warranted. When teams keep the proper perspective about documentation, they tend to experience many more of the benefits and fewer of the costs involved with project documentation. I would describe the proper perspective as that expressed by Ron Jeffries several years ago on an agile discussion group:
There are two types of documentation:Documentation requested by stakeholdersDocumentation the team needs to be effectiveLet's take a closer look at both of these types of documentation and some appropriate ways to handle each one of them.
Documentation Requested by StakeholdersThe documentation that your stakeholders explicitly request is part of the solution that the team is trying to deliver. This kind of documentation includes user guides, support documentation, and operating instructions, among others. A good way for handling this type of document is to treat them as if they were a feature. When a stakeholder requests a particular document those requests get sequenced along with everything else so that stakeholders can decide whether new functionality is more important to them than the documentation. If you find that the documentation is important, determine why they are asking for it and what they hope to accomplish with it. Watching the stakeholders do their work can be a good way to understand why the documentation might be needed.
Armed with that knowledge you can craft the document specifically to meet that purpose. Don't try to use design documentation, which was intended for conveying a design, as a way to convey information to those trying to maintain the system. The design documentation may not accurately reflect the system's final state. Plus, that document was structured to convey design information, not to provide a quick guide to how the system was actually built.
When you know what documents are needed and their purpose, determine the best time to create those documents. In some cases, it makes sense to work on the document as you build the system (help documentation, for example). In other cases it makes sense to create the documentation after the system is built. Either way, write the document specifically for the intended purpose.
It also is usually a good idea to craft these documents at a system level, rather than a project level. Most of the consumers of the documentation do not care which project implemented a certain set of features in a product or system, they care more about the system as a whole. Since they are looking for information in this context, producing documents with this same perspective instantly makes it more useful. If information about a system is split into multiple documents depending on which project implemented the system, users may never know where to look to find the documentation they need. The other benefit of this approach is that you don’t have to create a new document for every project that touches a system; you can just make the relevant updates to existing system documentation.
Documentation the Team Needs to be EffectiveThe other type of document is those things that the team needs to do their job effectively. The vast majority of the documents project teams create fit into this category, but if you really take the wording to heart (those things the team NEEDS to do their job effectively) many of those documents actually go away. When the team relies more on face-to-face discussions on an as needed basis, they find that the documents now primarily aid communication and serve as institutional memory.
These documents no longer act as the sole means of communication, or as the only vehicle by which knowledge is transferred from one person on the team to the other. Looking at what they have to do, the team finds that they have been creating many of their documents because it was what they have always done, or because it was mandated by their process. Once the team identifies which documents they actually find helpful, they can focus on creating those, and using them in helpful ways, and abandon the documents that don't add any value.
So the benefits of documentation come into play when it satisfies a need that a stakeholder has or it helps the team become more effective. Documents add cost when they are not requested by a stakeholder, or if they get in the way of the team effectively meeting their objectives.
Posted at 02:30 PM | PermalinkComments Not all comments are posted. Posted comments are subject to editing for clarity and length.
/* COMMENTS: START */.comments { width: 100%; padding: 8px; border: 1px solid #666; -moz-box-sizing: border-box; }.comment { width: 100%; border-top: 1px solid black; border-top-width: 90%; *padding-top: 5px;}.comments-header { font: bold 12pt Arial, Helvetica, sans-serif; color: #000066; background-color: #fff; padding: 0px 5px 0px 5px; position: relative; left: 15px; top: -18px; margin: 0px; height: auto; border: none; -moz-box-sizing: border-box; display: inline; }.comments-open-header { font: bold 11pt Arial, Helvetica, sans-serif; color: #000066; }.comment-footer { width: 18%; float: left; padding-right: 2%; padding-left: 0px; }.comment-content { width: 80%; float: right; margin: 0; }.comment-form-name { text-align: right; width: 18%; float: left; padding-right: 2%; }.comment-form-field { width: 80%; float: right; margin: 0; }/* COMMENTS: END */ Post a comment Name:
Email Address:
(Not displayed with comment.)
Comments:
Comments are moderated, and will not appear on this weblog
until the administrator has approved them.
©Copyright 2000-2012 Emprend, Inc. All Rights Reserved.
About us Site Map View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy
RSS Feed 
No comments:
Post a Comment