It’s the first thing most project teams complain about. Project documentation. Nobody likes to do it, and it often is incomplete. The problem with this mode of thinking is that it follows the path of “a little work on the front end saves a whole lot of work on the back end.” In my experience, outside the contract, the design document happens to be one of the best tools in the project manager’s tool belt.
There are many documents associated with a project: the charter to kick things off, various registers to record events such as risks, and even sign off documents, but one of the most important documents for a project is the design document.
These go by many names: “The Detailed Design Document,” ‘The Preliminary Design Document,” or “Functional Design Document.” Each of these by definition varies slightly from the others, but the role in the project is the same.
The design document will demonstrate the high or low-level design of the project result. (I’m using result here to indicate the “product” that is the result of the project be it software, hardware, or a process.) This document, typically used for high-level design, will evolve to include low-level design details. It describes the architectural strategies of the system.
Now that we have the definition of this document out of the way, how can it help you, the project manager?
Focus, focus, focus – the document gives you the ability to keep all project members on task. As the project matures, this document will keep the team on task, and within scope. From a project scheduling standpoint, it is your best defense against creep. It’s best to establish early on in the project to all parties that this document is the project roadmap.
Validation – as you move through milestones, this document can be used as part of the overall project validation effort. If the document is written correctly, there will be specific, measurable components that can be verified by an independent team member.
Dispute resolution – when change is requested, and it will, this document will be the referee to determine if it is in scope, or out of scope. It will foster a better working relationship within the team.
Setting expectations – throughout the entire length of the project and into closure, this document will let all stakeholders know what their role is, what needs to be completed, and when it needs to be done.
Scheduling – when properly written, the design documents will help predict both the schedule and sequence of events. This will help you, as the project manager, take proactive measures to tackle challenges when they occur.
So now, when project documentation complaints arise, you have the ability to explain the logic and benefits to at least one of them, the design document. Over the next few blogs, I will be exploring other project documents and their role in the project manager’s tool belt. If you have any questions or comments, feel free to email me – jchamberlain@ktlsolutions.com.
[avatar user=”jchamberlain” size=”thumbnail” align=”left” /]JEFF L. CHAMBERLAIN, PMP | Project Manager
Jeff comes to KTL Solutions with an extensive background in healthcare IT, technical consulting, and telecommunications. He has been a project manager for almost 20 years, holding certifications from the Project Management Institute as a Project Management Professional, from the Management and Strategy Institute as a Six Sigma Lean Professional, and he holds a Scrum Master Certification from the Scrum Alliance. He has managed both hardware and software implementations for both the government and private sectors, in industries such as healthcare, insurance, telecommunications, staff augmentation, supply chain and shipping.
Jeff has provided training for clients globally, working in Europe, Russia, North and South America on various topics from system optimization to wireless theory and design. He possesses a Bachelor’s Degree in Technical Writing from the University of Baltimore.
