SMART Goals and KPIs
The Value of SMART Goals
The best goals are “SMART” goals. SMART is an acronym that stands for:
- Specific - there are appropriate details for those supporting it
- Measurable - results can be measured in a repeatable and clear manner
- Achievable - the team has the time, experience and resources to reach the goal
- Relevant - the focus aligns with the work a team does AND the purpose of the business
- Time-Bound - there is a set date by which the goal must be reached or accomplished
When a goal meets all the SMART criteria, teams understand what needs to be done. When one or more elements are missing, teams might pursue the wrong goal or misunderstand priority or any number of problems.
SMART goals translate business objectives into work and priority for technical teams. The last chapter of this section will address situations where goals are missing, are vague, or have other issues. What’s helpful at this point is to know this approach so that as new goals are identified, each new goal can be fit into the larger framework..
Sources of Information
Often, business peers will not or cannot sit down and spell out how a business objective translates into goals for the technology teams. This might be for valid reasons, not because the business team is incapable.
For example, in some businesses, the market changes rapidly and the entire organization needs to respond quickly to new developments. Macroeconomic issues (recessions, tariffs, laws or regulations) change or legal interpretations shift.
Additionally, business teams might simply not understand how the technology works or what is relevant to them about the technology the require. A business team might know a new acquisition will bring thousands of new customers, but not how that impacts a data warehouse, ETL jobs, datacenter configurations, etc.
Despite this, there are many ways a technology team can stay in sync with the business. A well-run company will generate a volumes of documents used to coordinate between departments, communicate with executives, and to “keep the lights on”. These can be one source.
Business Goal Artifacts and Information Sources
- Strategic Plans and Presentations
- Executive Interviews
- Status Updates and Analysis
- Product Manager Interviews
- Market Research Documents
There are many more possibilities here. Email updates, project management tools, financial reports, press releases, industry reporting and reviews, internal dashboards or metrics reports, and other assets can also help to build a set of goals for technology teams.
However, before using any of these to build a technology goal or strategy, it is important to validate the information source is useful and credible.
Dashboards often have example data or extremely focused reporting that doesn’t reflect larger objectives. “Validation” is not a specific process, just confirmation that the data being reviewed is useful to setting internal team goals or strategies.
In the end, even with a large set of internal planning documents or reporting, the source needs to be validated by business peers. Even if the business peers don't understand how the technology works, they should (or must!) understand the benefit of knowing key business metrics that can influence technology work, budgeting, or risk.
Key Performance Indicators
Defining KPIs
Key Performance Indicators (KPIs) are quantifiable metrics used to evaluate success or progress towards a goal.
A good KPI supports a business goal, identifies an area for improvement, and provides data that is useful for making good decisions.
KPIs support SMART objectives as the measurable (“M”) in the acronym.
What’s critical is that everybody agrees that the metric is appropriate and reasonable.
A KPI that is contentious or questionable is worse than no KPI. A contentious or vague KPI can cause individual teams to interpret the goal differently and causes risk that they work against each other (even if unintentional).
Choosing KPIs
Selecting KPIs is both art and science.
The art is to find KPI concepts that support the company strategy. A KPI might seem good until it is put into practice and it encourages maladaptive behaviors. The art is in recognizing KPIs that avoid encouraging side-effects as much as possible.
For example, a KPI that rewards “lines of code written” seems like a good productivity measure until developers realize they can write more complicated or less efficient programs to boost their “Lines of Code” stats.
The science is to pick a KPI that can be measured in a way that if two observers look at the same situation, they would come up with the same result.
A metric that is subjective will be a metric that undermines progress. Some may game the system so their metrics always look good. Or, different interpretations of the measure might result in KPIs that swing wildly from good to bad.
Thus, KPI selection needs to ask the question: “Is this KPI relevant to our goal, aligned with our strategy, and consistently measurable?”
Because a KPI is so specific to a company, a time, and a situation it is not easy to suggest a general or initial KPI that everybody should consider. Remember that the thing being measured should show progress towards a shared goal. If the KPI passes this test, it’s a good candidate to be used to help guide the team and measure progress towards success.
Tracking and Reporting KPIs
The science of KPIs sits with the way tracking is organized and status is shared. This might initially sound simple, but as data is gathered and people start to think about it, a simple KPI will often inspire more questions (and, then, more KPIs).
One way to approach the KPI process is as such:
- KPI Purpose: “What is the focus of a KPI or what is the question the KPI answers?” Ensure that this is defined and included in any reporting or discussion to help people use the KPIs more easily.
- Data Collection: “How do we collect the data?” Understand where the KPI data is found. If there are any issues with collection that could change the KPI value when the collection is repeated with the same parameters, reconsider this as a KPI. Data collection should return the same results for the same query.
- Data Analysis: “How do we make sense of this data?” Before you create a graph, consider the data itself. It might need to be cleaned up (formatting, trim decimals, etc) or annotated. It might be input for a larger calculation, so how will the data from multiple sources be joined together into a single view?
- Visualization: “Is there a graph or visual approach that quickly explains what the KPI is showing?” Everybody knows the pie, line, and bar chart. There are more types of charts and there’s an entire science behind the selection of the best visual. In general, keep the visualization clean and ensure the focus of the KPI (and questions it answers) is clearly addressed by the visuals.
- Reporting: “When do people need an update and what do they need to know?” KPIs often have a shelf life. Waiting too long can mean the company loses an opportunity to act quickly to gain a sale or save money. Reporting should also have a focus. A long document full of tables and charts is a reference, not a report. A report should summarize the key observations for KPIs for the most recent period, call out interesting changes or trends, and guide readers to what is important.
- Review & Improvements: “Should the report be updated or changed to reflect new conditions?” Over time, KPIs might become obsolete. The combination of data collected might also change over time, so that analysis and visuals need updates. And, of course, as people look at the data they will realize that there are new KPIs worth measuring or will come up with new questions that the team needs to consider (and answer with new goals and/or KPIs). Tracking and reporting is never really perfect. Almost always, reporting is “good enough” until it isn’t, and then things get changed.
By effectively defining, tracking, and reporting KPIs, organizations can gain valuable insights into their performance, make data-driven decisions, and continuously improve their operations.