In the last blog post we talked about why organizations don’t have all of their needs met by a single core solution. In this post we’re going to be talking about how organizations acquire point solutions to solve specific problems that the core system won’t solve. Point solutions solve one specific (or a few specific) business needs. They’re generally designed to integrate into the existing core system – with varying levels of success.
Perfectionists and Maximizers
We’ve been taught in IT to only work on a problem if it can be solved completely. We don’t want it to mostly work but to always work. This obsession shows up in developers who are spending their time on edge cases, that almost never happen, and infrastructure specialists who work on load balancing, clustering, and failover, to prevent even the shortest interruption in service. The problem is that the Pareto rule applies here. You can solve 80% of the problem – get 80% of the efficiency improvement – with 20% of the effort.
We’re all familiar with perfectionists. They want to have everything perfect – all the time. They will lament about the smallest detail. However, perfectionists never really expect to achieve perfection, they just have their perfection dial turned up a few more notches than other people do. Perfectionists will spend hours working on a trivial detail that doesn’t matter – but at least they know they’re not going to get to their destination of perfect. Maximizers are a different sort than perfectionists, because maximizers expect that they will reach perfection and they’re disappointed when they don’t reach it. Maximizers are consequently constantly disappointed.
Often the quest for point solutions leads into the category of perfectionism. Instead of finding options that have the greatest value, the solution with the greatest match to the problem is located – even when it’s not the highest value option available.
Money, Money, Money
Let’s face it, it’s all about the money. Whatever problem you have, can be solved with enough time and money. When we’re talking about a point solution, we’re either trying to bring in more money – perhaps through greater sales – or trying to save money through reduced costs. (It’s worth noting that government regulations are sometimes seen as an alternative to these two options, however, when viewed as preventing fines and judgments, they are a way of reducing risk of costs.) So when making the decision for a point solution, money often takes center stage. There are all sorts of financial concerns. How much does the solution cost? How much will it take to implement it? How much will it cost to integrate it into the core system? What are the maintenance costs? How much time and money will it take to train folks to use it?
All too often, decisions about point solutions are based on the purchase costs of the solution, rather than looking at the total costs. One area in particular that doesn’t get much attention is the cost of training. Occasionally there’s a line item in the analysis that includes training – but that number is typically focused on the system administrators, for some 3-5 day training course in a non-exotic location at the point solution provider’s headquarters (I’ve been to a few.) Little thought is given to how much money and time will be required for the users to learn the solution.
The other side of the equation is the amount of money the solution will save – or new opportunities that will be created. However, these numbers typically came from the initial problem or opportunity statement and rarely is there an analysis on how much of that problem or opportunity can be claimed with the proposed solution. So instead of reducing waste by the estimated 60%, the solution can only reduce it by 50% – but no one goes back to update the numbers.
The typical office worker is lost in a sea of applications and web links, they need to remember. There’s a web site for purchase order requests, another completely different system for expense reports, and another for collaboration. They have Word, Excel, PowerPoint, and Outlook – and half a dozen other applications they may need to do their job. As they wander from web site to web site and application to application they must adapt to the changing user experience and to seek out the options that they need.
When Windows was first growing up, as an operating system, every application had its own user interface and as a result, transitioning from application to application was very difficult. Design standards for Windows (and the Mac) provided some commonality between applications but the Microsoft Office suite of products pushed this even further and enjoyed greater sales as a result. Moving from Word to Excel is relatively pain free as the controls and approaches are very similar.
However, what are the similarities between the point solution and the way the users are used to working? How do they navigate to the point solution from the core system and how do they get back to the core system from the point system. We’re simultaneously moving to more complexity and a greater need for consistency as the number of applications and web sites outstrips our ability to know and remember so many different things.
In the previous sections I’ve tipped my hand by stating that most evaluations of point solutions are fundamentally flawed. It is assumed that the results for a set of solutions will be fixed and the evaluation simply becomes a measure of solution features based on the financial impact it will have on the organization or on the way the solution solves the problem.
Further, evaluations rarely evaluate the “use existing tools” option. A pure-play “build it ourselves” option is sometimes included in the evaluation but only as the option of last resort and nearly always with the belief that the option is the most expensive option. However, leveraging the tools that you already have like SharePoint, may allow you to solve most of the problem and at a much lower cost. That’s the subject of our next post.
Robert Bogue, MS MVP Microsoft Office SharePoint Server, MCITP: SharePoint Administrator, MCTS, MCT, MCSE, MCSA:Security, etc., has contributed to more than 100 book projects and numerous other publishing projects. Robert’s latest book is The SharePoint Shepherd’s Guide for End Users. You can find out more about the book at http://www.SharePointShepherd.com. Robert blogs at http://www.thorprojects.com/blog You can reach Robert at Rob.Bogue@thorprojects.com.