When an organization is evaluating a product(s), we often listen to some of the terms like “FIT analysis” or “product FIT rating”. Many organizations preferring to do “FIT analysis” of the product than a “risk analysis”. Let’s understand the difference between these two before getting deeper into the topics.
An architecture risk analysis is a process of understanding the product features, analyze the technical components and evaluate the risk based on the certain criteria. So end of the day, architecture team will be sharing a risk analysis document having pros/cons of bringing a product into the organization, risk(s) in the technology stack along with mitigating plans and the overall feedback. There are certain methods & metrics followed by a team to come to a conclusion. For example if there is a risk rating of a product is 3.2 of 5, that means we are more than 60% safe to buy the product (technically) and 40% to mitigate the risk. Even though it is a good rating from overall product analysis, is it okay to say buy the product knowing 40% of risk? I am not saying that there will NOT be any risk (no product is 100% proof) but how much are we ready to take the risk. Sometimes, the word RISK itself is giving some level of negative thought about the overall process.
In order to avoid such thought process, many organizations prefer to understand the FIT analysis of the product. A product FIT analysis is a process of comparing overall product features with the organizational business & technology standards/needs and share a rating based on certain methodology and metrics. Even though we are following the same process for risk rating, the view is different.
The main purpose of the getting a new product into the organization is to fulfill some of the execution challenges business/IT facing today. The new product features can help the teams in resolving the major issues. It is the responsibility of the architecture team to understand those advanced product features making sure that they are in alignment with architecture vision. For example, if an architecture vision is towards API implementation, the new product should support API integrations out of box or with little bit of customization.
There are many methodologies followed by organizations to evaluate a product. It depends on the type of the business and kind of the product we are bringing into the organization. There is no one to one mapping between the products vs. process but we can follow some best practices outlined by industry experts and customize it for organization need. This can help the team to come up with qualitative analysis of the product.
By this time we know that there are set of key areas to look at. Now drill down into each of these areas by asking few questions. These questions can be generic or specific to organizational need. As I mentioned before if architecture vision to go for API implementation, there should be a specific question in integration area with high priority. These priorities can be defined based on the type of product we are bringing into the organization. If we are using BPM product, more emphasize on process/rules than infrastructure level questions. So the output of this process will give us a quantitative analysis of the product.
When an organization is looking to buy a product, it is always a best practice to evaluate few products in the market and finalize the top 2-3 products for a deeper dive analysis. When we follow the same methodology for qualitative and quantitative process, we end up with 2-3 FIT analysis documents. Now architecture team needs to compile the data based on the key technical areas and come up with a comparison matrix. This matrix should highlight the key strengths and drawbacks of each focused area in one view. For example product A is built on cutting edge technology stack and offering features that are not a right FIT for organizational needs, we will rate it high for industry standard and low for organizational requirements.
Executives are the key stakeholders and decision makers who needs to understand the overall process in a nutshell. So at a high level, create a summary view of this process with pros and cons of each product. This summary should be a consolidation of the comparison matrix and it should be in simple words. These executives are the drivers for the organization vision; we need to emphasize more on the product features that can come close to the goals.
This is the tough part of the all. While comparing multiple products sometimes it is obvious that one product can have higher rating than others. At this scenario it is easy for decision makers to propose the right FT based on the quantitative analysis and executives would really see the value based on the methodology being followed. But many times it so happens that the ratings are very close and most of them are meeting architecture vision. It is a tough call for the architects to propose the right solution. Also we have to keep in mind that a FIT rate difference of 0.1 is not necessarily better product (in few focused areas) than others but it’s a right product for the organization.
This is more of an appendix or reference guide for sharing the matrix. Depends on the methodology, organizations follow a 3 scale (High, Medium & Low) or 5 scale (Very High…Very Low) or 10 scale (usually number based) matrix. The higher you go the more complex in the evaluation process and more transparent of product features.
This is a standard process that most of the organizations are likely to follow. The steps may vary based on the evaluation methodology. At Princeton Blue, we help customers to choose the right BPM product by conducting FIT analysis by following a structured methodology. Feel free to engage with us on Facebook, LinkedIn, Twitter & Google+ to get updates about BPM and related technologies.