«    »

The Difficulty of Making Good Recommendations

Recently I have been doing an architectural assessment of an application for an organization I have not worked with before. As I have been writing up my findings, I have noticed that the portion of my analysis causing the most difficulty for me is in coming up with recommendations. Why is this?

In this context the word "recommendation" can be defined as "to advise as to the best course or choice". The process of analysis to arrive at a recommendation can be decomposed into the following three steps:

  1. Observation: This first step involves learning about the application, the business need it fills, and the broader organization. A variety of methods need to be used to gather all the required information such as interviewing members of I.T. and business, examining documentation, and reviewing application code.
  2. Gap Analysis: Once the current state is known, this step involves comparing it with the ideal state. Every deviation from the norm or from the optimal is a potential opportunity for improvement.
  3. Evaluation: Each identified improvement is then evaluated. First a cost-benefit analysis must be done to determine whether it is even worthwhile to action the improvement. Second, a prioritization must be done to determine which are the highest priority and value to proceed with first. This very last part is what identifies "the best course or choice", which is the actual recommendation.

It is the Evaluation step that has been causing me the difficulty, especially the cost-benefit analysis of each improvement idea. Why would this be? Upon initial reflection it seems like the benefits side is easy to determine: it is often clear what non-functional characteristics or process would improve for a given idea. But evaluating the impact of this improvement is harder. For example, consider an improvement to the maintainability of a portion of the code base. What impact will this have? This depends in large part on how much that code base will need to change in the future. What business drivers might lead to change? How is this portion of code used by or interacting with the reminder of the application. Performing this analysis requires deep and broad knowledge about the application and the organization. And as I stated at the start, I am new to the organization and application.

Therefore fundamentally my difficulty with coming up with recommendations is a function of lack of contextual knowledge. Ironically this can be an asset during the Observation and Gap Analysis steps, since I am examining what is in place with a fresh pair of eyes. So is it worthwhile for me to perform the Evaluation step? There is the temptation to avoid the difficult thinking and just present various suggestions for improvement. While there is value in each of the first two steps on their own, the final step of making recommendations completes the value stream, and thus I believe is the most valuable. It turns a list of observations or improvement ideas into a prioritized, actionable list. I often see this as a major challenge for teams doing continuous improvement: lots of talk about the current state and ideas to improve, but no clear identification and actioning of the top priorities.

If you find this article helpful, please make a donation.

«    »