If you’re in a leadership position, you probably understand that good documentation is really important for any project success. You might have worked with a few Gantt charts, work breakdown structures, burn rates, and budget forecasts. However, if you’re working on an analytic project an entirely different set of documentation is needed. In this article, we’ll go through the reasons why good analytic documentation is critical for your team’s success.
Why Your Analysts Are Probably Ignoring Analytic Documentation
I have heard from more than a few executives that they expect their analytic teams to document their projects. These same executives, however, rarely provide any expectations or parameters about the type of documentation they expect.
Instead, they argue that the analysts should have been trained how to create documentation. And in the worst cases, leaders who lack an analytic background claim ignorance on the documentation the analysts need.
Well, if your analysts are relatively young, you can bet they haven’t been taught how to document a project. Analytic documentation just isn’t something that they are taught. Instead, schools are too busy trying to teach the fundamentals of statistics, programming, and research methods.
On the job, young analysts are frequently gung-ho to flex their analytic muscles. Routinely, they jump immediately into writing code, sometimes even before they have a solid analytic plan in place.
What’s more is that analysts will also often make numerous decisions on the fly during development. Yet rarely do they write down what those decisions are, or the rationale behinds their choices.
It’s not that they aren’t professional, but it takes some time for analysts to learn the value of developing good documentation.
Consequences of Poor Analytic Documentation
Right now, you might be asking, “But really, what is the big deal?” I’m glad you asked.
Have your analysts ever misplaced a data file or piece of programming code?
Has the team ever experienced miscommunications resulting in significant portions of projects that were completely wrong?
As a leader, you might not have direct experience with these challenges. Instead, you are most likely to experience the effects of poor documentation when you are asking questions.
Does it take your analysts a long time to respond to basic questions?
Has a client or higher-up ever waited longer than necessary for details that seemingly should be well-known to the analysts? (yeah…embarrassing at best, and damaging to your credibility at worst)
These are all symptoms that your analysts are not maintaining robust analytics documentation.
Benefits of Proper Analytic Documentation
If your analysts develop and maintain robust analytic documentation, you’ll know pretty quickly.
The first thing you’ll find is that everyone on the team is staying on the same page. Whether analysts, support staff, project management, or others, they’ll know what needs to be done, and who is responsible.
The second thing you’ll notice is that the entire project begins running more efficiently. Tasks that previously took analysts days to complete may only require hours. The increased efficiency is a function of staff knowing what they need and where to find it.
A third thing you’ll find it that analysts are more likely to answer your questions quickly, clearly, and confidently. They have a clearer understanding of the overall form and function of the project.
Finally, robust analytic documentation is worth its weight in gold if you ever need to review an old project. Typically, within about six (6) months, a busy analyst will begin to forget what they did on a project. If you are a leader reviewing a project you didn’t work on, proper documentation will save you serious headaches.
There are other smaller benefits great analytic documentation provides…like easily finding old code you want to reuse. But the big four are better communication, improved efficiency, greater clarity, and quick reviews at a later date.
What Kind of Analytic Documentation Do You Need?
At this point, the logical question you are asking is probably, “What analytic documentation do I need?”
The answer to this question is debatable and might vary from one organization to another. However, there are a few key documents that are definite must-haves for your team’s success.
Project Process Document (PPD)
The PPD is the nerve center of your project. You must reference every other document used to manage and execute the project in this document. It is your source of truth. The PPD is also used to plan and track the development of the final project deliverables.
Analytic Plan
This is the document your analysts should create first when they begin working on a project. No programming should be done until the analysts have thought through what needs to be done. The analytic plan outlines the input data analysts will use, the methods required, and the outputs needed.
Technical Specifications for Measures
The analysts should compile a list of any metrics that need to be calculated from the data. The technical specifications must include any transformations and algorithms used to calculate the metrics.
Timelines
Analytic projects are like non-analytic projects in this respect. Your analysts need to have timelines compiled to define periods of planning, development, testing, refining, performing analytic validation, and finalizing the results. And each of these phases needs to dovetail with the rest of the overall project development.
Start-Up and Close-Out Checklists
To turn analytic documentation into a scalable system and consistent habit for your team, they need checklists. You don’t want analysts to have to recall everything they need from memory. When you create a start-up checklist, include all the items that analysts might need to consider. If some items are only used occasionally, that’s okay. You want the analysts to think first and dismiss later rather than forgetting to even consider them. When you create a project close-out checklist, include everything needed for analysts to get the final deliverable(s) and analytic documentation prepared for archiving.
Your analysts should develop their analytic documentation with the expectation that someone else will need to use it. They need to create documents that are sufficiently detailed that another analyst could feasibly execute the plan.
Similarly, they should consider that someone may need to review and understand the project after they leave the organization. Robust analytic documentation will accomplish both of these tasks well.
Conclusion
If you think your analysts are creating robust analytic documentation, you might be surprised. If they are, congrats!!! You’ve got a great group and should be proud of the leadership they’ve been given.
Check with your team and find out what they are doing about creating analytic documentation. Then review the challenges they have encountered in planning and executing your projects.
If they are not creating the analytic documentation described in this article, propose they implement a system for capturing that information.
And, if you don’t want to have to start from scratch (and who would?), check out the F1 Analytics Analytic Documentation Pack (ADP). The ADP will give you robust, pre-made templates for all critical analytic documentation, and more! << Click Here >> to get this done-for-you solution today!
