Get It Done, or Get It Documented?
Recently I have posted articles on here talking about various dilemmas in the wonderful world of data analytics (worker bee vs. unicorn and automation vs. customization). Usually, I conclude with something on the order of “You gotta have both.” Well, hang tight because this is gonna be another one of those articles. Hey, not my fault that this profession is full of conundrums needing to be grappled with!
LinkedIn CEO Jeff Weiner has a rather nifty Venn diagram of the three qualities that make a person enjoyable to work with. The second circle is NSFW but let’s just say I have a graphic of it at the top of this article.
If you are a data science professional, then you probably saw the title of this post and nodded in agreement — “Yup, this is something that I have to deal with on a fairly regular basis.” The scenario typically goes something like this:
Project Manager: Did you finish the analytics request BFD348 that I assigned to you in Jira/Rally/ServiceNow over two weeks ago?
Data Analyst: Yes, I completed the deliverable and sent it to the requester about a week after it was assigned to me. The requester was happy with what I gave her.
PM: But there are many open tasks for BFD348 still outstanding. For example, I don’t see that you did the tertiary code review meeting with Master Code Review Person, let alone the initial and secondary ones. Also, you have not filled out and uploaded to SharePoint/Asana/Slack your Excel documentation workbook with the multiple tabs.
DA: (thinks silently to himself “Dude PLEASE, if I had to do all that then no way I would have gotten the deliverable to the customer by the due date.”) You are right, I haven’t completed those tasks. I will go do them now. When is the deadline to finish the incomplete milestones?
PM: Yesterday.
DA: All right, thanks for letting me know. (shuffles off in disgust, muttering obscenities under his breath)
I’m with Jeff on this one — it is more important to get s* done and please the stakeholders than to have all the proper documentation entered into your company’s project tracking system and Collibra. Of course, you need to have those things in place; it’s best practice. But the following are good counterarguments to the standard justifications having to do with ensuring business continuity:
“Need to have full documentation on the project in case Paulina gets hit by a bus.”
Here’s the thing: getting hit by a bus is something over which Paulina has a great deal of control. She can ensure that she always looks both ways when crossing the street, always finish crossing in time before the flashing green hand turns red, not jaywalk, etc. It is much easier and less time consuming for Paulina to avoid getting hit by a bus than it is to “fill out [insert PM name here]’s stupid spreadsheet.” [The preceding is an almost verbatim quote from a real data scientist (NOT ME). The complete statement was “It took me only an hour to write the code but half a day to fill out his/her stupid spreadsheet.”]
“Need to provide full transparency in order to leave a complete audit trail and make it easier for others to understand.”
This is actually a totally legit argument that I fully agree with. It keeps you in good standing with your company’s compliance and data governance departments.
Here’s another aspect about this one that I really like: by creating a step by step Word doc complete with screenshots walking through how you did the data analytics project (over the years I have seen this called such names as “Desk Level Procedures,” “Job Aid,” and “Standard Operating Procedures”), then it forces you to come clean about the amount of work and skill level it took you. “Wow Paulina, I see from your SOP that this project really doesn’t look too complicated, tbh. So why did it take you so long to turn it around?” Ouch. I mean, what a douchebag thing for someone to say, but still, Ouch.
That being said, it’s understandable to want to keep one’s cards close to one’s chest. Why should I reveal all my secrets? I’m the one who came up with this methodology, hand-typed all the formulas and code, created the stored procedures, etc. Which leads me to my final point:
“Yes, this is an ad hoc, one time, proof of concept type of request. But you still have to document it because it could be something that we’ll want to revisit at some point.”
This is another way of saying that in case the stakeholders like the proof of concept deliverable, then the project needs to be fully fleshed out to include exactly how it would be implemented.
If the customer of the original request was intending to have a change in workflow and operations all along, then I agree that it would be worth going through the process of full documentation. However, if this is just some theoretical “nice-to-have” then I’m sorry, but please don’t waste the data analyst’s precious time. You are asking them to give up THEIR intellectual property, the product of THEIR hard work, and hours and hours out of THEIR workweek (maybe even nights and weekends). Ask yourself if that is a really a fair thing to demand of someone.
Bottom line: The less time you have to spend on documentation, the more time you have to GET STUFF DONE.
