Having been in IT for many years and managing projects for the majority of the time, I find it is very typical for systems and technology resources to want to avoid or skip doing documentation of any sort. However, over the years, the importance of documentation became very apparent. Collecting information and being able to refer to it can be critical for change management, audit information requests, scope agreement or changes, schedule information, risk and issue management, budgeting, and more. Documentation is not only useful but necessary for an organized and successful project. The importance of recording the history of why something was done or not done is required on many levels.
Imagine not having any documentation detailing the scope and objectives for a project; six months after the project starts someone asks why the project is doing what it is…you have no documentation, no emails, and no signatures – now try to justify why you’re doing it. Another example is if the client asks for more scope..in this case, why not? The scope is not defined or approved, so they could ask for many things and claim it is in scope.
I have been in the situation where although everyone remembered the discussion regarding a decision, the fact that is wasn’t documented and had some form of sign-off meant the conversation may as well have never happened. Documentation need not be complicated or difficult to produce, it should simply describe what has been agreed upon or done. It is the history of the project, decision, or in some cases what is to come whether it be a project plan, or an operational hand-off document for the operations staff when the project is completed.
I will address some of the more common forms of project documentation below and describe the importance of each and why they need to be done. Other project documents will be addressed in future posts.
DOCUMENT SIGNATURES AND APPROVALS
The signature of an approving authority on a document records the approval for future reference. If the signature of an approving body isn’t on the document, it is not approved, rendering it meaningless if something in the document is later challenged or contradicted. Approval can come by way of email or actual signature. If approval comes via email it should be attached to the document so that the approval can be easily referred to later.
MEETING DOCUMENTS
Any information discussed at meetings needs to be recorded. I cannot over-stress the importance of this. The accuracy of the information collected is also key and should be reviewed and agreed by the meeting attendees. Documentation used for meetings can vary but should contain at a minimum an agenda, actions, and decisions. Additional items to be recorded could be presentations, spreadsheets, diagrams, and other forms of meeting documentation. All of these should be collected as they could have formed a basis for a decision.
The meeting agenda should be sent before the meeting, of course. The minutes should be sent as soon as possible after the meeting, usually within 24 hours, so the meeting discussions and decisions are fresh in everyone’s mind in case they have comments to add or need to change any of the information gathered.
PROJECT CHARTERS
Over the years, I have seen project charters take many forms, from one page to large multi-page documents. The size of the charter will vary depending on the size of the project. The charter typically contains important information such as scope, goals and objectives, financial information, out of scope items, risks, issues, and other pertinent project information.
Creating the charter and getting sign-off is imperative. Many times the project gets questioned as to scope or other items typically stored in the charter. I have been in a situation where there was no charter or a charter with no sign-off. When asked what the scope of the project is I gave my version of the undocumented unapproved scope. In such a case where items such as scope were in question, without a charter it’s difficult for a PM to argue that something is in or out of scope.
CHANGE ORDERS
The Change Order document is a critical component that requires approval and sign-off to proceed. If there is a change requested that affects scope, budget, schedule, quality, resources, or other major components of the project, a change order should be created. It should list what the change is and the effect of the change on the project. It is important to get approval and sign-off signifying the approval of the change. Without approval, the change should not be acted on. The approval gives the project the go-ahead to proceed with the change.
I have been surfing online more than 2 hours today, yet I never
found any interesting article like yours. It is pretty worth enough
for me. In my opinion, if all site owners and bloggers made good content as you did, the web will be a lot more useful than ever before.
Thank you Amy. If there are specific topics you’d like to read about let us know and we will try to incorporate them into our blogs.