Adoption Vs Best Practices

The Proof of the Pudding is in the eating

Any platform is only good if it is used and delivers results. One of the key steps to ensuring good adoption of a platform is to engage users and keep their interest going. Bad implementations loose users and so do long implementation cycles.

While you should always follow Best Practices, what would you do if there is an immediate business need for a feature but the Best Practices don’t meet the time and budget constraints?

When you have users waiting for a system and you don’t have the time and money to do it right, at times it may be in the interest of the long term goals to implement “Something that Works” though it may not be the “Best Practice”. Something that Works would keep the users engaged and provide them many of the benefits they need. This would drive adoption and provide the expected ROI. The returns from the system can then be invested in doing it the way it should be.

“Best Practice”, a phrase I hear quite often in my world. Customers ask me if something is a best practice, I have heard developers say they have implemented the best practice and there are some others that  say a particular implementation is not as per Best Practices.

Over the years I have noticed there are 2 kinds of items that are usually clubbed under the banner of Best Practices –

1. The practices that usually come out of product design/ limitations or Anti Patterns. These are like the Law – Not following these can cause serious damage. For example, in the SharePoint world, the likes of disposing unmanaged objects.

2. The practices which are the recommended way based on various factors including the experiences other customers. These are actually Guidelines or Recommendations. Not following them on most occasions of course is costly, usually through maintenance overheads, scalability issues or performance bottlenecks. But then there are rare occasions where they may not be the most suitable for the situation.

Most decisions in the business our world are based on a Risk-Reward profile. As long as there are clear benefits and in some cases, a plan to fix it, I would advise taking the option that is the fastest to get you off the ground and provide returns, even if it means not following some of the Recommendations. This is akin to managing debt in the Agile development world to keep the right velocity. You would avoid debt but most often you have it and it is ok.

Keep away from fire but not if you are lighting a candle in the dark!

As one of the experts rightly put it when answering my question on the topic at a #SUGUK meet in London – “You should always evaluate the risk and decide if it is worth taking the risk”.