Success Metrics
There are two formatting options available. The traditional desired outcome statement is a structure used in the Outcome-Driven Innovation methodology. Since many stakeholders - especially when involved with marketing or UX teams - push back on the awkward nature of desired outcomes statements since people don’t talk like that, the alternative is a natural language structure that gets to the heart of the outcome and tries to avoid tasks and activities where feasible.
This catalog contains 20 potential metrics using each formatting option. You will likely need to reduce this set for a survey. The number of statements that have been generated is arbitrary and can be expanded to accommodate your needs.
Desired Outcome Statements (ODI)
- Minimize the time it takes to identify the root cause of implementation issues, e.g., software bugs, hardware malfunctions, etc.
- Minimize the likelihood of overlooking critical issues during the resolution process, e.g., data loss, system instability, etc.
- Minimize the time it takes to communicate the identified issues to relevant stakeholders, e.g., software developers, hardware suppliers, etc.
- Minimize the time it takes to develop a comprehensive resolution plan, e.g., bug fixes, hardware replacements, etc.
- Minimize the likelihood of resolution plans failing to address the root cause of issues, e.g., temporary fixes, overlooking underlying problems, etc.
- Minimize the time it takes to implement the resolution plan, e.g., software updates, hardware installations, etc.
- Minimize the likelihood of implementation causing additional issues, e.g., system downtime, data corruption, etc.
- Minimize the time it takes to verify the effectiveness of the resolution, e.g., system tests, performance checks, etc.
- Minimize the likelihood of recurrence of the same issues, e.g., unresolved bugs, hardware malfunctions, etc.
- Minimize the time it takes to document the resolution process for future reference, e.g., issue logs, resolution steps, etc.
- Minimize the likelihood of miscommunication during the resolution process, e.g., unclear instructions, missed updates, etc.
- Minimize the time it takes to train team members on the implemented changes, e.g., software usage, hardware maintenance, etc.
- Minimize the likelihood of resolution plans causing delays in the project timeline, e.g., extended downtime, slow implementation, etc.
- Minimize the time it takes to get approval for the resolution plan from relevant authorities, e.g., project managers, clients, etc.
- Minimize the likelihood of resolution plans exceeding the project budget, e.g., expensive hardware replacements, additional manpower, etc.
- Minimize the time it takes to adapt the project plan based on the implemented changes, e.g., timeline adjustments, resource reallocation, etc.
- Minimize the likelihood of resolution plans conflicting with other project components, e.g., software incompatibility, hardware conflicts, etc.
- Minimize the time it takes to communicate the changes to all project stakeholders, e.g., team members, clients, suppliers, etc.
- Minimize the likelihood of resolution plans causing dissatisfaction among stakeholders, e.g., unexpected changes, additional costs, etc.
- Minimize the time it takes to monitor the system post-implementation for any potential issues, e.g., performance checks, system tests, etc.
Customer Success Statements (PJTBD)
- Identify the root cause of implementation issues, e.g., software bugs, hardware malfunctions, etc.
- Avoid overlooking critical issues during the resolution process, e.g., data loss, system instability, etc.
- Communicate the identified issues to relevant stakeholders, e.g., software developers, hardware suppliers, etc.
- Develop a comprehensive resolution plan, e.g., bug fixes, hardware replacements, etc.
- Avoid resolution plans failing to address the root cause of issues, e.g., temporary fixes, overlooking underlying problems, etc.
- Implement the resolution plan, e.g., software updates, hardware installations, etc.
- Avoid implementation causing additional issues, e.g., system downtime, data corruption, etc.
- Verify the effectiveness of the resolution, e.g., system tests, performance checks, etc.
- Avoid recurrence of the same issues, e.g., unresolved bugs, hardware malfunctions, etc.
- Document the resolution process for future reference, e.g., issue logs, resolution steps, etc.
- Avoid miscommunication during the resolution process, e.g., unclear instructions, missed updates, etc.
- Train team members on the implemented changes, e.g., software usage, hardware maintenance, etc.
- Avoid resolution plans causing delays in the project timeline, e.g., extended downtime, slow implementation, etc.
- Get approval for the resolution plan from relevant authorities, e.g., project managers, clients, etc.
- Avoid resolution plans exceeding the project budget, e.g., expensive hardware replacements, additional manpower, etc.
- Adapt the project plan based on the implemented changes, e.g., timeline adjustments, resource reallocation, etc.
- Avoid resolution plans conflicting with other project components, e.g., software incompatibility, hardware conflicts, etc.
- Communicate the changes to all project stakeholders, e.g., team members, clients, suppliers, etc.
- Avoid resolution plans causing dissatisfaction among stakeholders, e.g., unexpected changes, additional costs, etc.
- Monitor the system post-implementation for any potential issues, e.g., performance checks, system tests, etc.
Test Fit Structure
Apply this to Customer Success Statements only. Everything should fit together nicely. Here’s an article where I introduced the concept. Feel free to devise your own version for Desired Outcome Statements as this does not apply to their format directly.
As a(n) [end user] + who is + [Job] you're trying to [success statement] + "faster and more accurately" so that you can successfully [Job Step]