In a previous article, "Stop focusing on prompt engineering" I drew your attention the the importance of formulating a problem statement.
Articulating problem statements is critical for your team to understand, with a high degree of specificity, the issues or causes of problems in your organization, but this is only a first step.
Using methods like root cause analysis - in this case for nonprofits - (RCA) - helpful for identifying the underlying causes of problems so that appropriate solutions can be found - needs to begin with a clearly defined problem statement. Not just varying opinions but factual statements on the specificity of the incident and its impact.
Here's an example of a well-formulated problem statement and a 10-step guide for implementing in your organization:
Example:
"Since the software update on July 15th, our online donation platform has reported a 50% increase in transaction processing time, causing a 2-minute processing delay for our online donors during peak hours. The delay cause them to either abandon the donation or to double click the DONATE button, causing a duplicate charge."
Be Specific: Avoid vague descriptions. Instead of saying "The system is slow," you might say, "The application's response time increased from 2 seconds to 10 seconds after the last update."
Quantify the Problem: Whenever possible, use numbers or data to describe the problem. This helps in setting a baseline and measuring improvements later.
State the Actual vs. Expected Outcome: Clearly differentiate between what is happening and what you expect to happen. For example, "After the software update our campaign led to a processing an average of 50 donations per hour, but it should be processing over 100 donations per hour, on average."
Include the Timeframe: Specify when the problem started and if it's ongoing. "The server began experiencing downtime on June 1st and has been intermittently unavailable since."
Identify the Location or Scope: Where is the problem occurring? Is it in one department, across multiple locations, or perhaps in a specific piece of equipment?
Describe the Impact: How is this problem affecting operations, donors, or other relevant stakeholders? "Due to the system delay, donations have been reduced by 50%."
Avoid Blame: The problem statement should be neutral and not assign blame. The goal is to understand the problem, not to point fingers.
Keep it Concise: While you want to be specific, it's also important to be concise. Avoid unnecessary jargon or overly technical terms unless they're essential to understanding the problem.
Refrain from Jumping to Solutions: The problem statement should focus on the issue, not potential solutions or causes. Those come later in the RCA process.
Review and Refine: Once you've drafted the problem statement, review it with stakeholders to ensure it's accurate and comprehensive. They might offer insights or details you hadn't considered.
Stewart Severino
留言