By Mark Cecchini
Associate Dean of Executive Education
I’m a big fan of explaining (and probably over-explaining, as my students would attest) the value of iterating and versioning your Power BI projects. My thoughts follow the path of the lean coding philosophy. Lean software development advocates (also called Agile) focus on creating a minimum viable product and getting it out to end users as soon as possible. Then, they watch them interact with the product and then start adding bells and whistles later, based on feedback. This is in contrast to the traditional software development process (sometimes called Systems Development Lifecycle or Waterfall), where all expected software attributes are gathered up front by the developers and then they close their doors for several months to a year, and build a complete program. The traditional methods were sufficient when software was simple and the development environment was slow, but as time went by, the ever-increasing pace of technological change, along with the complexity of user requirements, meant these projects became too slow to get out of the gate. Today most companies employ a lean or agile strategy for software development because of the following dynamics:
- The terrain changes quickly, so to get value out of a project, it needs to be developed within 6 months from the time it is initiated.
- KISS (keep it simple stupid): it shouldn’t take a degreed engineer to tell us that its easier to add onto a simple, functional software tool than it is to try to build every possible use case into it directly before getting feedback (look up the failure of Tucker Automobile Corporation for an example of this type of failure).
- The End User can’t be on the sideline: the End User is often derided in IT circles as the know nothing person who makes software development difficult. But we now are starting to understand that software is just plain better when the End User has a say in its design (I feel compelled to say…duhhhhhhhh!!!!). I can see how this got missed though, because the developers of the past THOUGHT they were getting the needs from the End Users before they started coding. The problem with this method is that its hard for the End User to give valuable feedback on a piece of vaporware (a piece of software that hasn’t been created yet). Its much easier to give specific feedback about what works and what doesn’t, when you can see (and touch) the software in action. This minor change in process order has turned out to be very effective in the software development community. And now’s the time when you ask me “why are you talking about software development, I’m not a programmer?”). Ok, my bad. I’ll make the connection next.
Analytics projects are like mini software projects. They have specifications just like software projects. Some are user friendly and some are not, just like software projects. And ultimately, the usefulness of your analytics project is really the only metric that matters. There, that was quick and easy, and hopefully convincing.
Since analytics projects (“Dashboards” from here on) usually starts from scratch, your first pass is necessarily going to be lean. My recommendation is that you take that lean Dashboard and share it with folks and ask for feedback. Start with your peers/subordinates. Once it’s at a point where you feel even the first tinge of pride (remember, its lean, so this should be early in the cycle), share it with a higher-up that cares about the information in your dashboard. It’s crucial here (I’ve been through many Army briefs so I see the risk I’m posing to your well-being) that you explain that this is NOT meant to be a final product. Make it clear that you are looking for feedback on what they would like to see added, subtracted, and where the Dashboard is easy to use and where things could be made simpler. Supervisors are a great source of additional feedback, because they will view your Dashboard from a different vantage point.
After a few iterations, you should have a working product that is useful to your peers and your superiors. But the fun doesn’t end there! Because you let your superiors in on your draft Dashboard versions, they will be halfway up the learning curve on how to use it. My advice is to lock-in (as the teens say) and create one more NEW version of the dashboard (this is where versioning comes in…you KEEP the stable version, duplicate it, and then add the new bells and whistles to the new version) with a few self-service tools such as slicers, drop down menus, callouts giving brief explanations of the data, and buttons to make moving between sheets easy.
Then, the next time your superior officer comes to you to ask for some data you can say “do it yourself, sir!” Ok, maybe not exactly like that. But, you can give them the information they are asking for AND walk them through how you got it. It’s probably only a few simple clicks since these dashboards are making things so much easier for the non-technical user. Once they see how easy it is you can say “next time, do it yourself sir!” Again, I apologize, I’m not sure why I keep going there, I’m liable to get your head torn off (figuratively). Let me try again, “Sir, would you like me to put a link to this on your Desktop so you can use it whenever you want?” There…that’s safer.
I am going to bet that after a short time, this will cut down your trips back and forth to their office, and more importantly, they will become confident that they can get the information they need to lead effectively, all on their own. As Martha Stewart would say “this, is a good thing!”
Comments are closed.