Project metrics aren’t one-size-fits-all.
As a software development project manager, you’ll likely want a detailed look at your team’s output and the specifics of their day-to-day progress. As a CEO, you’d probably prefer a semi-regular summary.
Information overload is no joke. Research has suggested that 25 percent of workers experience ‘significant stress and poor health’ as a result of the masses of information they’re expected to process. That’s bad news for employee wellbeing, but also for your bottom line. Stressed, unhealthy workers are unproductive.
This is avoidable, however. While you can't control the number of spam emails your team receives, you can control the reports they have to deal with. These reports (and the metrics that make them up) can have a significant positive impact on employee wellbeing if they're managed correctly.
Here’s how to use project metrics to get the right information to the right people.
Take some time at the beginning of a new development project to figure out what each stakeholder will need to know. Tricentis identify two main metric categories that can help to whittle things down:
‘Result metrics…are an absolute measure of an activity/process completed.
Predictive metrics…are derivatives, and act as an early warning sign of an unfavorable result.
An IT executive might want to get all of that information, while an investor may only be interested in results-based reporting. Decide on who needs results, and who needs active predictions. What’s their responsibility? Are they monitoring actual output and feeding back to the team, or are they in the team and responsible for proactively mitigating issues?
Once you’ve figured out the salient metrics for each role (and have cut out the unnecessary ones), it comes down to two words: ‘customizable dashboards’. A tailored dashboard gives users a quick, up-to-date look at the numbers they need, all in one place.
If you’re in the 68 percent of developers using JIRA, you’re in luck. The platform’s dashboards are made up of customizable ‘gadgets’, which visualize metrics. Each metric can be filtered according to project or issue type, making it easy to get as granular or as broad as you need to.
When project managing a testing team, for example, you might go with an ‘Average Age Report’, which shows you how long bugs tend to go unresolved. When it comes time to update someone in the C-Suite, however, you’re better off using a ‘Created vs. Resolved Report’, which shows you how many bugs were actually resolved. There are countless gadgets to make use of, meaning there’s a dashboard for every kind of user.
Those dashboards and gadgets are useful, but not all stakeholders will be familiar or comfortable with software development platforms like JIRA. That’s where project management software comes in. More specifically, project management software that integrates with your development platform. Confluence, which integrates with JIRA, is one example.
Instead of spreading information across several communication channels, gathering it in one place is much more useful when it comes to avoiding information-related stress. It especially comes in handy when you’re dealing with ‘non-techy’ users that still require updates on the development process.
Because of the integration between the Atlassian toolset, dashboards and gadgets from JIRA can be easily displayed in Confluence and kept alongside all other communications about the project. That’s not just good from an ease-of-use perspective, it also provides immediately-available context for your metrics.
Project metrics can be a double-edged sword. Tailor your reports to individual users or roles, and they’ll work for you. Inundate everyone with a one-size-fits-all barrage of numbers, and they’ll work against you.
Getting the right information to the right people is an editing process that should happen as soon as a development project begins. Be intentional about your reporting, and you’ll avoid sacrificing the insights and improvements that those metrics are there to provide.