How to Recommend a Tough Decision (And Still Be Loved By Your Client)
Have you ever had an impossible problem to solve for your client?
A problem that nobody seems to understand even though the solution is obvious to you? A problem that has no easy answer. No matter which option is eventually chosen there's going to be a significant price to pay in money, reduced functionality or increased complexity.
Often when working as a Architect/Consultant/Freelancer/Developer you won't be allowed to make the important decisions yourself. The decision might be too big.
You might know what the right answer is. It might even be blindingly obvious to you, since you're the expert. But it's not your money and it's not your project so you have to present the options and let the client decide.
Sometimes there is no easy answer. Sometimes it's a case of choosing between the best of the bad options.
These hard decisions can make or break your relationship with the client. How you present these problems to your client, involve them in the process and take them on a journey to the the best option can make or break your relationship with your client.
Show them why the tough decision is the right option and your client will love you for it.
Writing an Options Paper is one way to walk through the minefield for a problematic decision. An Options Paper consisely describes what the options are and then presents a recomendation. Manager's love them because you've described the problem and provided a solution.
As a software architect myself it seems like every week I get to spend less time coding and more time writing option papers.
This article is going to show you how to structure an Options Paper so that you can guide your client to the right decision and add value to their business.
- avoid pejorative words
- describe the problem subject (not the solution)
Introduce the paper and explain the goal of the paper is. Briefly explain any events that may have led up to this situation.
Define the problem that your paper is going to present a solution for. Outline what the problem is and also describe any fundamental business requirements or technical constraints.
A business requirement is something that the business has defined as a requirement. Defining these up front is good when you have to deal with other departments within the organisation such as Architecture Review Boards, Finance or Legal.
A technical constraint is something that limits the available choices. It might be a limitation in the technology or it might be a design/security standard that must be met. Describing the technical constraints helps explain to the business why this is a hard problem to solve and can't be solved with a wave the magical technology wand.
When describing the problem describe the things that the solution must do and also describe the things that the solution must not do.
Describe each option in sufficient detail for the problem or situation.
Spend time on thinking of a good title or name for the option because it's the handle by which people will interact with it.
Start with the least preferred option and work down to the most preferred. That way you are guiding the reader on a journey to the right decision and when they get to the end of the paper you are not suddenly asking them to remember what you were recommending at the start.
People remember the first and last things in a list, so you want them to remember the first least preferred option as the most obviously wrong choice and the last most preferred option as the most obviously right choice.
To make it obvious have the last section make a stand and recommend the best option.
List pros and cons. For each negative point also include a sentence about how the negative can be mitigated.
Suggest what steps should be taken next and include any timeframes that might be important.
If you liked this approach for writing an option paper I have prepared a very simple text template including headings and starter sentances to use as the basis for your next options paper. You can find it here at blog.the-decision-wall.com .