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 confirm the successful integration of all solutions, e.g., software compatibility, hardware synchronization, etc.
- Minimize the time it takes to verify the performance of the integrated system, e.g., speed, reliability, etc.
- Minimize the time it takes to ensure all system components are functioning as expected, e.g., software modules, hardware components, etc.
- Minimize the likelihood of system failures post-integration, e.g., software crashes, hardware malfunctions, etc.
- Minimize the time it takes to validate the system meets the project requirements, e.g., functionality, performance, etc.
- Minimize the time it takes to confirm the system's compliance with industry standards, e.g., security protocols, data privacy regulations, etc.
- Minimize the time it takes to document the integration process and outcomes, e.g., technical specifications, performance metrics, etc.
- Minimize the likelihood of unresolved issues at the end of the integration project, e.g., software bugs, hardware issues, etc.
- Minimize the time it takes to communicate the project completion to all stakeholders, e.g., project sponsors, team members, etc.
- Minimize the time it takes to prepare the system for handover to the client or operations team, e.g., user manuals, training materials, etc.
- Minimize the likelihood of miscommunication about the project outcomes, e.g., project scope, deliverables, etc.
- Minimize the time it takes to gather feedback from the project team and stakeholders, e.g., lessons learned, improvement suggestions, etc.
- Minimize the time it takes to conduct a final project review, e.g., project objectives, deliverables, etc.
- Minimize the likelihood of project closure delays, e.g., pending tasks, unresolved issues, etc.
- Minimize the time it takes to archive all project documents and data, e.g., project plan, technical specifications, etc.
- Minimize the likelihood of post-project disputes, e.g., contractual disagreements, payment issues, etc.
- Minimize the time it takes to finalize all project financials, e.g., invoices, expenses, etc.
- Minimize the likelihood of non-compliance with contractual obligations, e.g., warranty terms, support agreements, etc.
- Minimize the time it takes to disseminate project learnings within the organization, e.g., best practices, improvement areas, etc.
- Minimize the likelihood of rework or adjustments after project closure, e.g., system tweaks, additional training, etc.
Customer Success Statements (PJTBD)
- Confirm the successful integration of all solutions, e.g., software compatibility, hardware synchronization, etc.
- Verify the performance of the integrated system, e.g., speed, reliability, etc.
- Ensure all system components are functioning as expected, e.g., software modules, hardware components, etc.
- Avoid system failures post-integration, e.g., software crashes, hardware malfunctions, etc.
- Validate the system meets the project requirements, e.g., functionality, performance, etc.
- Confirm the system's compliance with industry standards, e.g., security protocols, data privacy regulations, etc.
- Document the integration process and outcomes, e.g., technical specifications, performance metrics, etc.
- Avoid unresolved issues at the end of the integration project, e.g., software bugs, hardware issues, etc.
- Communicate the project completion to all stakeholders, e.g., project sponsors, team members, etc.
- Prepare the system for handover to the client or operations team, e.g., user manuals, training materials, etc.
- Avoid miscommunication about the project outcomes, e.g., project scope, deliverables, etc.
- Gather feedback from the project team and stakeholders, e.g., lessons learned, improvement suggestions, etc.
- Conduct a final project review, e.g., project objectives, deliverables, etc.
- Avoid project closure delays, e.g., pending tasks, unresolved issues, etc.
- Archive all project documents and data, e.g., project plan, technical specifications, etc.
- Avoid post-project disputes, e.g., contractual disagreements, payment issues, etc.
- Finalize all project financials, e.g., invoices, expenses, etc.
- Avoid non-compliance with contractual obligations, e.g., warranty terms, support agreements, etc.
- Disseminate project learnings within the organization, e.g., best practices, improvement areas, etc.
- Avoid rework or adjustments after project closure, e.g., system tweaks, additional training, 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]