Designing Models and Reports for your Future Self: Part 1
IMPROVING HANDOVER & SUPPORT
…by adopting a helpful mindset & habits.
🔮 PART 1: THE MANTRA: ‘DO FAVOURS FOR YOUR FUTURE SELF’ 👈
📝 PART 2: MODEL HANDOVER CHECKLIST
📝 PART 3: REPORT HANDOVER CHECKLIST
CREATING SUSTAINABLE DATA SOLUTIONS
Writing 20 p. of docs won’t guarantee seamless handover.
Will they really read that?
Chances are that you will not be working on the same models and reports, forever. The solutions you make today will be passed on to someone else tomorrow. They will have to maintain it, support it, and change it. To do that, they need a handover of the solution - knowledge transfer from the original author.
This handover is a challenge if the person was not involved in the original solution. Without the right solution hygiene - documentation, organization or consistency - time will be wasted trying to understand what was made and how it works. This is costs time and resources, and will lead to mistakes. In a previous series, we looked at being on the receiving end - how to approach data models & reports you didn’t make. But what if we are the ones passing down the solution? What are some simple steps that we can take during development to drive better handover & support?
In this article, we look at how to improve handover of both data models & reports. First, we look at the mindset and habits during development that create a sustainable data solution.
TAKING OFF THE DEVELOPER BLINDFOLD
What does someone need to understand what you made?
When working on a dataset or a report, you’re focused on the development, itself. You’re creating everything in it, so you know how it works - how to change it, how to manage it. But imagine you didn’t. Try to distance yourself for a minute and imagine receiving this model or report for the first time, without all this developer knowledge:
Would this be easy to use or understand?
What would you need to understand it - the DAX, the visuals, the queries… ? What would make this easier?
What would you need to change & maintain it?
Looking with this fresh perspective, you might get a feeling — this is… hard to understand.
You may notice inconsistencies, missing organization, or places where extra documentation is needed. This is a good thing; the changed perspective creates a voice to remind you to take off your blindfold. It helps you reflect on how it will be understood by someone else. The point is to bring more self-awareness to design & development decisions you are making as you make them, and the effort required for a naïve mind to understand, fix or change it in the future.
This isn’t just for the benefit of some unknown stranger. It’s very likely that the person who will need these things is yourself. Will you still remember the logic of that complex DAX measure in 6 months? What about that Macgyvered visual, or the Vega in that Deneb chart?
Will Future You still understand what you’ve made, today?
GETTING TO KNOW YOUR FUTURE SELF
There are three versions of you:
Past You, who has done & decided things
Present You, who is doing things now based on the decisions of past you, yesterday
Future You, who will do things based on the decisions of present you, today
One of the more helpful mentalities you can adopt is to ‘Do favors for your Future Self’:
Today, Present You might be developing a model or a report that tomorrow Future You will maintain or change. So Present You can do Future You some favors by making that as low-effort and time-efficient as possible. That might cost Present You some time, but it may save more time in the long-run; Future You will be glad it was done. On the other hand, Present You could save some some time now to meet a deadline, by skipping solution clean-up or documentation activities. This might make Future You pretty upset if they have to waste hours pouring over code, objects and files to understand how you did something.
This is simply an esoteric way of empathizing with the future caretaker of your present creation. It’s easiest to empathize with yourself, so imagining what ‘Future You’ needs to succeed is a good start. By keeping ‘Future You’ in mind, you will be more likely to see the value of organizing or documenting something. It will incentivize focusing on helpful clean-up and documentation tasks, rather than generic, blanket documentation that checks a box, but that no one will read. To give one example, just because you comment your DAX or M code doesn’t mean it’s helpful come time to read or change it. In fact, unhelpful or excessive comments can even make this worse, and may be indicative of problems in the code, itself. But if you consider which comments where could be helpful & why you’re including them, their value will increase. Imagining yourself as the future reader is a mental trigger to write more helpful comments.
As you create your solution, ask yourself, what would make this easier for Future Me to understand what I did, and how to change or fix it? How can I make this easier? Together with the right documentation & hygiene habits, strengthening this voice will improve the quality of what you make.
TRANSLATING TO ACTION: FROM MINDSET TO HABITS
Being mindful of future people who will inherit your solution - including yourself - is just a first step. We need to translate this to action by doing the pro-handover activities as we make the solution. Traditionally, these activities - like ‘clean-up’ and documentation - are saved for the end of development. From a planning point-of-view this might make sense. But uncoupling these two streams of activities risks creating incomplete, less relevant documentation, as details are forgotten and priorities change over time. Inconsistencies and disorganization may also remain for the same reason, as the solution creators move on to other tasks or the next project. We all know how important documentation and hygienic solutions are, but we also know we’ll procrastinate — “we can always do that later”. Too often, later never comes.
Creating the habit of doing documentation, clean-up other pro-handover activities as we develop benefits us in the long-run. After we wrote that complex DAX measure, we can immediately format it, add some comments, and document the business logic. Even for knowledge transfer - if we already know who will inherit the solution, why not involve them already during development with recurring 15-minute syncs? Instead of getting all the information in a single knowledge dump, they’ll get the story piece-by-piece in more digestible bites.
Building this habit is hard, but it will ultimately improve the quality of what we make. More importantly, it will help these solutions remain quality for longer, as they are easier to understand & support.
UNDERSTANDABILITY IS QUALITY
Being perceptive of the effort required by others to understand the things you make is a skill. Training that skill is important, because it will always be relevant. This is true even outside of technical solutions, for things like PowerPoint presentations, designs, notes…
“It’s essential that others can use and understand the things you make with minimal effort and time investment; that’s part of what makes a quality solution.”
If someone doesn’t understand what you’ve made, chances are they will support and use it incorrectly, or not at all. In essence, the change management required for a good handover is not so different from what’s required to drive adoption of a report among users. Why should they use your Power BI report instead of their Excel Worksheets if it’s too much time & effort for them to understand? But if effort is invested in creating something easily understood, it is more likely to be easily used.
TO CONCLUDE
Creating a sustainable data solution requires a helpful mindset and good habits that produce something easy to understand & maintain. Doing this will create a more ‘hygienic’ solution, saving both you & colleagues time & headaches in the tomorrows ahead.
In Parts 2 and 3 of this series, we look at some tips for improving handover of models (Part 2) and reports (Part 3) with a handover readiness checklist for each.
