I came across an article written by a guy called Victor Cheng. He developed an acronym for sales people to use in a job interview. However, I thought a variation could be used as a mnemonic for testers and developers on describing how a problem was solved in a product development setting. Essentially software solves problems for people. Hence this acronym takes the perspective of explaining a project in terms of addressing the critical issues and the steps you or your test/development or product team took to resolve them. It can be used to explain a project to a stakeholder or in a job interview. The acronym stands for
Audience
Problem
Anticipated Consequence
Role
Action
Decision-Making-Rationale
End-Result
Reflection.
AUDIENCE.
Your communication always needs to be pitched to the level of your audience. Are you speaking to the technical manager only, or also to HR? Even if the person is technical, does he know the acronyms or specific domain knowledge that you worked in? Translate specialised knowledge into terms and explanations that the layman can understand.
PROBLEM.
What is the problem, critical issue, main concern or priority you or your organization, or project is facing?
If you are a developer, what is the underlying problem such that you needed to develop a solution for it, or needs to be considered to drive your strategy. If you are a tester, give the situation, product and stakeholder requirements what the main priorities that your testing needs to address?
Anytime you explain a career experience, extra-curricular activity, academic experience, work report, or presentation frame the experience as the underlying problem people are trying to solve. The audience is interested in knowing if you make intelligent decisions because you understand the bigger picture, or if you are simply doing what you've done before because that's what you've always done. Do you understand really the problem and its ramifications?
ANTICIPATED CONSEQUENCE.
What consequence did you or your organization face if this problem continued without resolution? You need to demonstrate that you understand the impact of why these problems or issues matter. It tells recruiters or your team lead that you know understand how to prioritise your work around risk or what matters most to stakeholders.
ROLE.
What was your role in resolving this problem? People are trying to evaluate the truthfulness of the situation, i.e. what portion of the project were you exposed to, what is your perspective. What did you actually do? Clarify what you were actually responsible for as a part of the team and what others did. Don’t say continually ‘we’ as if to imply you were responsible for every aspect of the work.
ACTION.
What action did you take? What did you do? Be specific. Don’t waffle.
Say, for example “I did three things: a) I did X; b) I did Y; c) I did Z.”
DECISION-MAKING RATIONALE.
Explain why you decided to take the action that you did. What other options did you consider? Why didn’t you choose the other options? Why, this specific decision?
What quantitative data/information did you consider?
What qualitative data/information did you consider?
What was your decision-making rationale include analytical factors (“I considered X, and determined Y was the better choice for Z reasons”) It is also important to consider interpersonal factors in your rationale. “Option A was the best logical option, but it was also a tough sell, given the culture of the organization. Option B was 80% as good as Option A but had no cultural resistance. Given the political environment, I chose Option B.”
END-RESULT.
After you took the action that you did, what happened? What was the outcome? Be specific — when possible, cite a quantitatively measurable outcome.
REFLECTION.
Did things go as planned? What worked, what didn’t work? What did you learn from the situation? What would you do differently?
Comments