About Nick Gianadda

Hello! I am a Development Manager at Algonquin Studios, I am responsible for managing new and ongoing projects at Algonquin Studios. I have been part of the development team at AS since early 2003 and have been managing software development projects since 2005. I've worked with internationally-recognized clients in a wide range of professions including experience with the Hospitality, Health Care, and Professional Services industries.

The Corporate Dashboard

In this post, I’d like to talk about the good fundamentals of dashboard design. There’s an important item that separate a bad dashboard from a great one. It’s called a “Key Performance Indicator” or KPI. When we discuss KPIs, we are usually talking about something like “Income forecast” or “Employee productivity rates.”

The most important part of the KPI acronym is the “K” for “Key.” Key means it’s supposed to be important but all too often, I’ll hear:

“I want a dashboard with 50+ KPIs that can quickly show me the health of my company at a glance.”

Remember, the “K” stands for “Key.” Do you really need more than 50 indicators to “quickly” show the health of your company or department? Are there really 50 plus things that are “key” to your review? Can you even review 50 of anything “at a glance?” Really?

As an example, let’s take a look at a “Dashboard” with only a few KPIs versus one with lots of KPIs and see which is better suited to give us an “at a glance” view of the status of our company:

While each of these dashboards shows information that’s likely very important to the user and the health of the system, there’s an obvious difference in the amount of information being displayed and each is intended for a different kind of user.

The first is clearly a dashboard from a plane, specifically a B-58, and it has a ton of indicators and gauges. This type of dashboard can certainly be overwhelming to someone who’s not a pilot and hasn’t undertaken the significant training needed for its effective use. Now, this doesn’t mean there are too many KPIs on the dashboard, it just means that the process that the user is attempting to navigate is very complex and requires a high level of expertise. It would not be expected that someone viewing the dashboard would be able to tell the status of the plane in “at a glance.” If you really dug into it, there are probably only a few “Key” indicators on the board and lots of additional indicators that will help the pilot track specific information, look for particular problems, or do their job in emergency situations.

The second dashboard is from a BMW M series. It has two large dials for the Speedometer and the Tachometer and a few indicator lights for important factors like “Door Open” or “Check Engine.” This type of dashboard requires a much lower level of training to understand and interpret and only offers KPIs that tell the user how the car is performing in its primary objective–moving–and if there are any significant problems like a lack of gas or increased oil temperature. And it’s pretty important to realize that your car door is open when you’re driving along at 60 miles per hour! There are hundreds of other metrics that could be useful to different users (i.e. the car technician or the racing enthusiast) but they’re not “Key” performance indicators needed to simply drive the car and they can be retrieved in other ways.

Now, both of these dashboards accomplish their goal of providing all of the information that the user needs at their fingertips. But as I’m sure you could guess, the B-58 dashboard costs a lot more, because it’s more complicated in its design, its build, and its output.

If you’re considering building a dashboard, you must start by defining who your audience will be and what information they’ll need “at their fingertips” to be successful. Most dashboards only need a few metrics/gauges; the bulk of the effort should be spent on important things like that “Oil Temp” light. Define the rules to indicate that there are problems and then allow the dashboard to work for you. 

In an effort to collect some input from the readers, please comment below if your company has a dashboard. How many KPIs do you think are enough?



Nope, I’m not talking about extravagant costumes, black and white face paint, and fire breathing.

I’m here to discuss the old adage “Keep it simple, stupid” and how it applies to software development.

As a Project Manager, I spend a lot of time meeting with clients to review requirements for their software and work with them to turn those requirements into a full system. As I work with my clients to navigate the treacherous waters of system design, we inevitably end up with a “feature” that we all agree is on the borderline of “Necessary” and “Nice to have.” This is especially hard to determine in a business system that users will be working with every day.

This is when things get interesting! Let’s take a look at what questions to ask yourself:

Why do you want this feature?

You can tell a lot about how important this feature really is by the initial reaction of a client when you ask this question. If it takes a few minutes of fumbling to eek out a satisfactory answer, you can most likely scrap the feature.

Is it worth it?

To answer this one, we’ll ask a few follow up questions, too:

  • How often will this feature be used?
  • Is there a manual workaround that can be used instead of this feature?
  • Who will use this feature (and how many of these users are there)?
  • How much work will be created for a user is this feature is left off?

Now do a little quick math and, magically, we can determine if it’s financially worth adding this feature. Here is an example:

Add this monthly report that aggregates data for X, Y and Z. 
  • Feature will be used monthly
  • User can perform this process manually
  • 1 administrative user will use the report
  • If this feature isn’t implemented, the administrative user will need to run 3 reports and aggregate the data themselves. This process will take approx. 20 minutes.

Answer: If building the report adds 8 hours to the system build, it will pay for itself in 2 years.

Does this feature add complexity to other areas of the system?

I’ll let you in on a little secret, the answer to this question is always YES.

No mater how much you want this fancy new feature, it will make your system more complex. We often try to convince ourselves that a feature is so simple that it won’t add complexity, but there are a couple of points that always hold true:

  • This feature will need to be tested after every update.
  • The users of this feature will need training.
  • This feature will need to be documented in the help system (and maintained).
  • This feature will need to be discussed when future changes to the system are designed/implemented.

So, let’s return to our seemingly simple example report and apply these issues to the “complexity” question:

  • Will this report need to be tested? Yes
  • Will the users need training? Yes
  • Will we need to add help documentation? Yes
  • Will this report need to be updated if we make changes to report X, Y or Z? Yes

There’s no doubt about it–every time you want to add a feature, you’re choosing to make the system more complex.

Before you commit to a feature, ask yourself if it’s a system requirement and make sure you really understand, and accept, the increase in time, complexity, and cost that including the feature will entail. If the answer is “yes,” then let’s build it. But if there’s any doubt, remember, it’s never a bad idea to K.I.S.S.

Learning From Your Data – Part 2

In part one of this post I reviewed the details of Data Visualization and how it can help you learn for the data that your systems already collect using a simple example. That bring us to the next point:

What about information that’s more difficult to examine?

In his book The Visual Display of Quantitative Information, Edward Tufte states that the “lack of quantitative skills of professional artists” is what makes creating a truly stunning and convincing data visualization difficult. This is why you don’t often see Data Visualizations as outputs of systems; it’s hard enough to design and create a Data Visualization to illustrate a specific point, let alone one that asks the viewer to draw their own conclusions.

Relationships between the individual data points in your system are everywhere. The simple ones, as we discussed, are easy enough to display. But if you can find ways to show the complex ones, you can make a real difference in a business. As an example, I’ll  reference another Visualization by Lee Byron, available on his site LeeByron.com. This one shows the relationship between words in a poem or limerick:


This Visualization shows the relationships between the phonemes and entire patterns of phonemes.

Byron shows a more complex example using a poem by Shel Silverstein:


These examples probably don’t relate to your business (unless you’re a poet), but they should illustrate how connections between data elements can have a massive effect on your ability to understand how and why something is working.

Where can I find examples?

Here are a few more examples that may show how this sort of Visualization can turn your data into an understandable tool to help you get ahead in your industry:

  • San Francisco – Home Prices
    • Great example of an interactive data visualization. Shows how multiple data visualizations working together can make data even more understandable.
  • Business Statistics 
    • Perfect example of displaying Progress % type KPIs
    • (Note: be sure to try the update button)
  • Cross Filter of Flight delays
    • Interactive example that shows how an data visualization can be used to hone in on the results/data you are looking to find. Think of data mining to determine what set of data fits a specific question that you have.
  • Slope graphs
    • Perfect example of displaying Change % type KPIs
  • Web Server Statistics 
    • Cool example for my industry
    • (Note: you need to use the +new button)
  • Crime in Portland
    • All around good example that shows lots of visualizations that display similar data (i.e. types of crime) by region.

Learning From Your Data – Part 1

Data Visualization is defined as “the study of the visual representation of data, meaning information that has been abstracted in some schematic form, including attributes or variables for the units of information.” But, to boil it down, the term means a graphical representation of data that can make understanding it easier.

I first learned about the concepts behind Data Visualization in the book The Visual Display of Quantitative Information by Edward Tufte. Tufte’s book illustrates (quite literally–there are tons of visual examples) the idea that a picture is worth a thousand words. When I first looked through the work nearly 15 years ago, I was overwhelmed and amazed by how Tufte so easily and simply relayed information using diagrams and I took away from the book a firm grasp on the idea that a graphical representation of data can very clearly articulate a point.

After becoming a software developer I learned about how the theory and practice of Tufte’s concepts can enhance a computer system. David McCandless has a bevy of great visualizations on his site, informationisbeautiful.net. One such visualization, from McCandless and Lee Byron, is a graphic of Facebook post-break-up status messages by month:


As you can see, this simple graph very clearly illustrates some interesting results (February, March, November, and December are tough months for love) even though it displays the inputs of over 10,000 status updates.

So, how does all of this relate to Software Development? 

As a Development Manager at Algonquin Studios, I spend a lot of time meeting with my clients. The objective of these meetings is almost always to determine the final “outputs” of a system. These outputs can include things like reports, ESIs (external system integration), graphs, printable documents, and customer facing data views and can be thought of as the reason we’re building the system in the first place. If we never established the outputs for a given system all of the inputs–usually time-consuming data entry–would be a waste.

The most important outputs for a system are almost always tabular reports that can show information ranging from first quarter financials, a customer list, or employee performance over an extended time period. Basically, these are the types of reports that help run a business and there comes a point in almost any project when I’m asked to create an “Executive Dashboard” using information pulled from these reports. Because these dashboards can contain all types of information, from trends to warnings about productivity, their information can be displayed as general statistics and/or graphics.

So, how can we use the data in a system to dynamically draw a Data Visualization that will let the user draw their own conclusions about information that’s pertinent to the running of their business? Key Performance Indicators.

There are 3 basic types of Key Performance Indicators (KPIs):

  • Raw Numbers
    • Number of new customers
  • Change %
    • Percent increase in sales over last month
  • Progress %
    • Percent of monthly income target

Each of these basic types of KPIs are related to a goal and there are a set of work items that need to occur to move these items forward.

Each of these KPIs will have a few attributes.

  • Frequency
    • How often can this indicator be measured? Daily, weekly, monthly, bi-monthly or anually?
  • Target
    • Especially important for percentage-based KPIs. When have you hit your target?
  • Thresholds
    • When you want to consider this KPI under a lower threshold
    • When you want to consider this KPI in an “Acceptable” state
    • When you want to consider this KPI over an upper reasonable expectation

And all of this information be displayed in graphical form. Simple bar graphs, line graphs and gauges can tackle these Visualizations with effective results.

Check back for my next post in which I’ll continue this look at Data Visualizations with some more complex examples.