I have a big presentation at work today – probably my biggest and most important presentation since I started this new job 6 months ago (wish me luck!). I’m presenting on a budgeting module that I’ve been working on for months! The tool I designed takes budget records and turns them into a highly customizeable budget-to-actuals report in Excel, downloaded from Salesforce and configured with Conga. It’s kind of my pride and joy right now.
Whack a mole
So you can imagine how heartbroken (and stressed out!) I was when I realized that I had made a logical error … and I only discovered it last night during some final testing! I stayed late at work tinkering with the logic until I got it working, but that created a new, harder-to-solve error that I’ve never seen before. Alarm bells were going off in my head!
Today, I returned to my work station with a fresh attitude (an hour and a half before “work” began), hopefully with enough time to reconcile all of these problems before my presentation. Instead of trying to fix the mind-boggling error, I just went back to an earlier version and re-did my logic revisions – figuring that retracing my steps was easier than solving some sort of weird Excel problem. I think that was the right move!
However, fixing the logic problem led to a new kind of error – discrepancies! The system was pulling the data properly, but the numbers weren’t matching up the way I expected. Now, I felt like I was playing data whack-a-mole! First one problem, then another!
Lady and the tramp
The discrepancies had me cross eyed and ready to abandon my laptop, save for the fact that time was of the essence!
In one area of my budgeting spreadsheet, I had a sum of “total payments this year.” In another area, I had “payments this year that were approved this year” and “payments this year that were approved last year” and really they SHOULD add up to the first number. One split the sum by approval date and the other one didn’t. Everything else is the same. At this point, I was pretty sure that my reports and logic were pulling properly, so there must be a reason why the data that SHOULD have appeared wasn’t getting captured the way I expected. The solution? There were TWO grants that were listed as Status=Awarded, however the Awarded Date was not populated! Aha, the offending records!!!
That’s where the Lady and the Tramp metaphor comes in.
As I was solving this problem, I had to chew on the “logic” side of the spaghetti first. Then, I had to chew on the “data” side of the spaghetti. Fixing the logic without the data would mean that some data just wasn’t captured. Sure, I had the right criteria, but the actual records didn’t meet my criteria, even though it was “supposedly” right. However, fixing the data without the logic would have still left us with wrong answers! In the middle was the perfect solution. And I had to iterate between both to get to a happy medium.
I think I fixed the problems that I discovered last night, but I might never be 100% sure that it’s perfect. In fact, I can’t unequivocally declare it perfect without my team using the Budgeting Tool and making meaning of the information and/or finding problems! I think this is true for LOTS of changemaking data attempts, whether that is pulling the perfect phone banking list or cleaning up database records. It’s always, always a work in progress.
It’s kind of terrifying to bring something to my team that COULD have problems that I just haven’t found yet – but if I never share it, it will never be put to use!
For all of us data nerds, quasi-data nerds, accidental data-nerds, aspirational data-nerds, or data-nerds-against-our-will, I see us taking risks and trying our best; not letting “perfect” get in the way of “good.” I see us being brave, and I think our movements are all the better for it. Thank you for what you do!