So, Lead & lagging measures are related to WIG itself. Also, we suggest that increasing lead measures will increase lag measure (it's a hypothesis, we don't know for sure). Let's see examples.
Extra articles:
- Measuring security: https://lethain.com/metrics-for-the-unmeasurable/
- DevOps measurement: Monitoring and observability
WIG: Decrease the number of hours that the development team is impacted by production issues from 20 hours a week to 2 hours a week by 12/31/2016.
Lead measures could include the following areas:
- Time spent interviewing and training the new App Support team
- Better logging and diagnostics in the code
- Identifying key problem code paths and rewriting/refactoring them
- Identify key times during the week or month and the top problems that often occur
- Increased testing and proactive fixing of bugs
The team could decide (in this example) that the highest impact areas are transitioning customer support issues to the App Support team and proactive testing and bug fixing. The lead measures are then set as:
- Number of hours setting up and transitioning work to the App Support Team
- The number of high and critical bugs resolved as the result of team testing outside of production
Some examples of lead measures that could exist for teams I’ve worked on recently might be:
- Increase automation
- Decrease latency
- Share javascript framework knowledge
- Reduce lines of code by a factor of 10
- Simplify the codebase
- Increase usability
- Decrease our build time
Idea: Migrate product from on-premise to cloud software as a service Hypothesis That moving the product will allow for a faster deployment of new functionality, improved reliability, reduced customer TCO and improved revenue streams through moving to a subscription model
Leading indicators:
- Customer interviews and market research to confirm they would value, trust and want SaaS version in the cloud
- Customer commitment to move to the new model
- Customers moving with a reduced feature set
Lagging indicators
- Reduced TCO of customers
- Improved revenue
- Percent of customer base on new service
Idea : New functionality to add revenue Hypothesis: By adding the new functionality, sales will increase by 10% with a profitability of 40%
Leading indicators:
- Customers committing to shift business to your product
- Prototype analysis demonstrates the expected profitability of the product after development costs considered
- Minimum Marketable Release (a subset of functionality) showing the positive movement of indicators
Lagging indicators
- Revenue impact
- Profitability
- Market share
Idea: Reduce call centre casts by improving Customer Experience (CX) Hypothesis: Improving customer experience of the process will result in reduced calls to the call centre, thus allowing a lowering of call centre costs
Leading indicators:
- User research sessions with low fidelity demonstrate better CX results
- Quick win change makes demonstrable improvement
- User journey success measurements compared to existing process
- In-process customer feedback scores
- Fewer call logs directly attributable to pm-identified common CX issue
Lagging indicators:
- Call centre costs removed
Goal: Make sure staff start working on incidents immediately when they occur. Make sure that incidents are assigned to the right people with the right skillset and that this person isn’t already overloaded with other work.
These can translate into the following “leading” indicators:
- Percentage of incidents not worked on for 2 hours
- Percentage of open incidents older then 1 day
- Average backlog of incidents per agent
- Percentage of team availability
- Percentage of incidents reopened more then 3 times