Why Documentation Is So Important: Part 1
(Part 1 of a 2-part Blog Series on Documentation)
As a Project Manager here at Vector, a big part of my job on a day-to-day basis is keeping clients up to date, making sure timelines stay on target, and finishing projects on budget. What sometimes gets overlooked, however, is the documentation that needs to happen behind the scenes to make sure your team is actually building the product that the client is asking for. This is imperative to the process, in order to avoid late-in-the-game surprises that come up based on miscommunication or different interpretations that were discussed during meetings or calls.
To avoid these types of issues, you need to be asking the right questions and taking all the right notes, so that you can get everything combined into a requirements document that is easy for both the client and internal design/development teams to follow and understand. There will always be questions that come up during the process of a build, and the more you get out ahead of defining key website features, the fewer problems you run into at a later date that could cause setbacks. One way to do this: transparency.
Usually when there is a clash in expectations, it comes down to a “he said, she said” situation where something might’ve been brought up on a status call very early on in conversations that was never written down or further discussed. This is why it’s important to gather every last detail and piece of functionality that is brought up, and get it into a document that is available to both the client and internal teams.
After every call, especially for larger design and development projects, Project Managers should be sending emails or pointing clients to a space that holds a recap of all call and meeting notes. These notes should include general conversations about the project (timeline, budget, concerns, etc.), any functionality brought up on a call that needs to be discussed further and next steps from both sides so that the next call is productive and everything can stay on track. It’s perfectly OK to take running notes during the call and then clean them up to be more client-friendly and digestible before sending off, but they should be sent out regardless, so that there is something in writing that confirms what was discussed. This level of transparency with the client is important because it means all appropriate details have been communicated and shared with the teams, and there is something to point to if there is ever a change of heart that causes a change to the project scope and / or timeline.
On top of documentation, it’s important to include the design and development teams in the process of reviewing project requirements as early as possible. This is crucial to the process in order to avoid problems down the line. In consulting with members of your team that have the technical expertise and mindset to look at particular features that they’re going to build, questions that Project Managers or other team members wouldn’t normally think of come up. Project Managers should sit down with their internal teams on a weekly basis, as designs are actively being worked on, to not only keep the developers up to date with how the project is progressing, but also to work together and collaborate on ideas with the design team. This promotes further team chemistry and helps gather questions that need to be asked and clarified on status calls with the client. Getting clarification early on for functionality, and sharing it with the client, is important to getting everything confirmed and avoids misunderstandings about project features.
In Why Documentation Is So Important: Part 2, I will explore some examples of clarifying questions to use for best documentation practices.
Originally published on 02.01.17 at www.vectormediagroup.com.
