Being a business analyst, I think it is fair to say, is not the most creative profession out there. We do have opportunities to write clear requirements, create interesting PowerPoint presentations from time to time, and choose an ingenious font color scheme to make status reports exciting and readable. But most of our time is spent figuring out what the problems of our stakeholders are and documenting the business needs to solve those problems, leaving it up to the developers to come up with creative ways to implement the requirements we’ve created.

But fear not, right-brained business analyst! We can, and we should, use our natural creativity to create amazing requirements. To explain how I came to this conclusion, let me first provide you with some context. I recently lent a hand to a bright but inexperienced coworker on a project he was working on. The goal of the project was to create a tool that would calculate the return on capital of a loan, a task that was currently being using a series of complex Excel formulas. His task was to analyze the formulas in the spreadsheets, determine how the calculations were being done today, and present the information to our client so that they could understand what was going on. Now, if you’ve read a few other blog posts that I or any of my colleagues have written, you know how enthusiastically we trumpet the benefits of visual models to organize information and elicit requirements. ArgonDigital has spent a lot of time thinking about visualization and, over the course of several years, has developed a toolbox of more than twenty models that we use from the very first day on a project to the final testing and deployment of the final product. However, there wasn’t a model in the toolbox that suited his needs. What were we to do?

Well, we put our heads together, brainstormed some possible ideas, and eventually created a new visual model we dubbed the calculation tree to describe the series of calculations that were documented in the spreadsheet. He showed it to his project stakeholders and they loved it. He started with the simple two-variable calculation that generated the final return on capital, broke down each of the variables into its component parts, broke THOSE variables down into their component parts, and so on until he got to the numbers that the actual loan officers inputted into the formula. This let him show the inputs to the formula, how those inputs were transformed, and eventually how they fed into the final value that everyone cared about. It let our stakeholders consume the information at any level of detail they wished. They could focus on individual parts of the calculation to provide feedback on which parts we needed to keep, which we needed to modify, and which parts the new system didn’t need.

Here’s an example of one of the calculation trees we created for the project to give you a better idea of what it looks like. Just FYI, this is not the complete model we created for the project and any references to our client have been removed.

As I see it, there are two main lessons to this story. First, using visual models to present complex information is almost always a good idea. The reasons for this are plentiful, and I encourage anyone interested in learning more about them to continue reading this blog. Second—and this is the main point of this blog post—we can and should be creative in how we approach the presentation of information. If the set of models that you normally use doesn’t seem useful to address your current problem, don’t be afraid to create your own! Many of the models we currently use at ArgonDigital were created the same way and have become mainstays in ArgonDigital’s visualization toolbox. Furthermore, even though your project may seem unique to you now, it’s likely that other business analysts will face a similar situation on one of their own projects. Let other business analysts know about your situation and how you addressed it. Your creativity can, and should be, an asset to our entire community!