When I was young, I started fishing in some local lakes and I used to try and make my own floats out of balsa wood. At first they were useless but after a while I got a little better and had a small box that I kept them in. However making floats was time-consuming, hit and miss, and sometimes an abject failure - they perhaps saved me a little money but they didn't help me achieve my goal of catching more fish. Eventually I simply bought new floats from a shop and got on with the task of catching fish.
For the last decade or so, an entire global industry has matured in developing bespoke solutions and custom application development for SharePoint. Allegedly today the global services industry for SharePoint accounts for approximately $6 billion in partner revenue. To a degree this demonstrates exactly how far the global SharePoint market has grown. One only has to look at the relentless recruitment of 'SharePoint developers' to understand how much custom application work is being undertaken.
So let's stop and ask why. The vast range of services of SharePoint out-of-the-box is unparalleled and if any company simply mastered the basic features, services and functions (and was made aware of them in business scenarios) then they would already have a great and positive deal on their hands. All too quickly however, many partners are quick to sell custom application development, custom user interfaces and custom web parts - why well because that is what the client thinks they want (or has been told that is what is required) and often because SharePoint can indeed facilitate that approach.
The issue however is in terms of business buy-in and user adoption. For many corporations, the early quick wins are fundamental to bedding in SharePoint into business life. An effective user profile and profile search is often of far greater value early in the cycle than a custom procurement system, or a bepoke developed application.
Time is one of the greatest factors. The development cycle of any custom application is longer than a client realises. Today with so many corporate IT environments being led by non-IT-literate teams (often finance-background people) then they themselves have little true understanding of a code-development lifecycle. Indeed we remember a particular IT manager who stated that any code released with bugs is unacceptable! The iterative development and bug-fix cycle is often lost on IT management teams who expect solutions to be delivered bug-free and perfectly, at the lowest cost and first time round. This creates a problem in terms of delivery timescale expectation-management.
More to the point, an early engagement with a SharePoint business client from a development angle entrenches the early view that everything to be delivered in SharePoint is a project, is time consuming, is relatively expensive, requires a maintenance contract, and requires an iterative and frustrating period of bug fixing with a partner or contractor team. None of which needs to be true. And then the question arises as to how a custom application will be developed further or supported in-house, if that is the strategy. It always amazes us at Salem why so many companies embarking on a SharePoint project begin by trying to recruit a SharePoint developer - what are these people developing, and why so early?! We know for sure that some service companies willingly sell SharePoint as a development platform on purpose as it will provide a cash cow for years to come.
Here at Salem we fully understand and appreciate the benefits of customisation. Certainly custom user interfaces that match brand and style guidelines can assist in acceptace and adoption by the business users. However customer user interfaces and custom application development are rather different topics. In all circumstances, however, user interface design should be overlayed on top of the engineered solution, not the other way round. Trying to re-engineer SharePoint technology to meet a visual style is a strategy to spend lots of budget unnecessarily - the form over function dilemma.
Back to the subject in hand. If SharePoint is going to grow and embed in a wide range of organisations then the commoditisation of SharePoint is now essential. What do we mean by this? There are a wide range of services, requirements and business solutions that are common to many (if not most) organisations which should exist as add in services. To a degree we see this being catered for by a few well known web part companies. But there is simply not enough of this happening. Why pay for a partner to develop a contract management system when one can be slotted in that has already been developed. Why develop a clock when a clock already exists? Why develop a news centre when one is already written. Well from a solution delivery company perspective, it increases revenue to develop custom applications.
Imagine then if one can use SharePoint out-of-the-box with a range of add-in business solutions already pre-built. What this means is that the initial adoption cycle is far faster for the end client, business buy-in is enhanced as it demonstrates how quickly business solutions can be achieved. It means that SharePoint is far more likely to be adopted and then entrenched early which in turn allows client budget to be focused on more pressing matters or more challenging services that are unique to that organisation.
Another example is where an intranet is designed from scratch: why we ask? So many organisations across so many business verticals share the same ambitions that the only thing that truly changes is the user interface. The business services being requested are often far too similar to require a greenfield approach every time. Does this mean therefore that there is a requirement for a far faster agile approach to early SharePoint business service release, and in our opinion the answer is yes.
To set the scene to any client, it is extremely important to show how quickly intial valuable business services can be delivered and to progress quickly into a longer SharePoint programme in terms of value proposition. Spending hundreds of thousands of dollars on a custom application as a starting point is not necessarily going to ingratiate the platform into the busienss community. Therefore early prioritization is intrinsic to success.
It is time for the SharePoint partner community to embrace how to deliver effective business soltions fast, early into the lifecycle using a standard range of services. It is certainly time for development companies to commence creating business solutions so that they can be packaged, sold and deployed again and again to a wider range of clients without the need for full development cycle every time. It is time that clients were given a quick sense of achievement with SharePoint rather than frustrating delays and large budgets and UAT iterations that appear to last a lifetime.
For those that argue that every customer is different, well when you have seen as many clients as we have, the one thing that strikes us more than anything else, is actually how similar business requirements are across a wide and diverse range of business verticals. Are clients worried that their competitors are using the same desktop and same version of Word or Excel - of course not. SharePoint is a superb development platform, but develop when necessary, customise when required, but ensure first that in the early months of SharePoint release, there are a wide range of quick-wins that excite the client audiences and demonstrate real value, fast.
I caught some of the best fish ever recently, and it wasn't using a custom-made float.
