- Read the question! Some students give solutions to problems other than that which is posed. Make sure you read the question carefully. A good habit to get into is first to translate everything given in the question into mathematical form and define any variables you need right at the outset. Also drawing a diagram helps a lot in visualizing the situation, especially helping to elucidate any relevant symmetries.
- Remember to explain your reasoning when doing a mathematical solution. Sometimes it is very difficult to understand what students are trying to do from the maths alone, which makes it difficult to give partial credit if they are trying to the right thing but just make, e.g., a sign error.
- Finish your solution appropriately by stating the answer clearly (and, where relevant, in correct units). Do not let your solution fizzle out – make sure the marker knows you have reached the end and that you have done what was requested. In other words, finish with a flourish!
(Via In The Dark)
For InfoSec we can extrapolate three similar tips for engaging with clients, either our internal ones or with external:
- Read the RFP/RFI! Listen to the customer! Write down, in your own simple words, your understanding of the client’s request. Communicate it back to them to make sure the understanding is as complete as possible.
- When delivering the response/proposal/etc. make sure you “connect the dots” between the client’s request and your solution. Make sure you account for and document assumptions. Explain why the proposal is the way it is.
- Finish your response appropriately by stating the answer clearly. Do not let your solution fizzle out – make sure the marker knows you have reached the end and that you have done what was requested. In other words, finish with a flourish!
Item 1 reminds me of a recent almost bad event at work. A potential client reached out about a RFP. They were looking for a security solution with a specific scope and desired outcome. We had a meeting with the client about their goals and objectives. They were clear and precise.
Skip ahead less than one week and suddenly a few leaders in my organization decided to make our RFP response something completely different. My vocal dissents were vetoed. The proposal proceeded with this alternate option. It was as if the client came to our restaurant to eat dinner and we decided to sell them recipe books instead.
Worse, there was nothing in this new approach that was truly new – every piece was obviously recycled generic sales material.
The client was not amused. When we met again the client shut down all extraneous-to-their-request discussions and materials. Since some of the team had not abandoned answering the RFP directly, we were able to pivot and still make a strong proposal.
Another recent proposal I worked on illustrates doing all three items well. The client clearly stated their goals in conversation but their RFP was mostly untethered to the goals, almost as if two different teams drafted each independently. Subsequent client conversations gave us what we needed to form a more complete understanding of the business needs.
The proposal was large compared to the RFP, but the space was needed to completely connect the dots between the client’s broad & disconnected needs and how we would deliver them for the desired business outcome. The response included all of the Who-What-Where-When-Why-How structures to clearly communicate our solution.
There is no shortage of experts in this field. By and large we all think we are one, so we rush to solution without always listening and understanding. Taking a page out of Richard Feynman’s approach to solving physics problems can help address such failings.