The question of build or buy is not new, but few technologies complicate the argument as much as SharePoint. That’s not a negative statement — just a fact of life for a platform that provides so much out of the box as far as end user capability and administrative control, and yet for most organizations requires some degree of customization or third-party tool oversight to adequately manage what has been deployed.
Every deployment begins in a similar fashion:
You deploy your SharePoint environment, and in short order have provided access to all of your end users. Over the next several weeks, they are active on the platform, adding content, modifying lists and views, experimenting with some of the new features, and slowly building our their team and project sites, maybe even expanding their MySites.
But 6 months later, most of the sites are looking pretty much the same as they did a week or two after deployment. What happened? Why did the enthusiasm die down?
The way I like to explain it to people is that SharePoint out-of-the-box is like providing vanilla ice cream. Everyone loves a scoop of vanilla. But serving vanilla day after day? People’s tastes mature, and they suddenly want Extreme Caramel Moosetracks with chocolate-covered almonds. Or a huge scoop of Cherry Garcia with hot fudge and chopped peanuts.
What End Users Want
SharePoint out-of-the-box is very powerful, but as organizations begin to understand the base functionality and start wanting to expand the platform to better match business processes — and look for ways to improve productivity and increase the speed and agility of business — they struggle with getting SharePoint to achieve what they envision. Much of what they want to do is beyond their skillset. They may find themselves taking multiple steps in SharePoint to do things that were simple back in the days of using email and the file share. They may be spending more time trying to navigate SharePoint than doing their actual jobs.
Human nature is to adopt the tools and processes that fit the way they do business, rather than change the way they do business to meet the tools and processes, like water following the path of least resistance. And so the shiny new SharePoint sites collect dust, and people settle back into their old habits.
Your end users want to add dashboards and metrics, capturing and reporting on transactional and manual data points, and then automating some kind of reporting. They want to automate some of the complex business process workflows in their organizations, add forms, and otherwise simplify the SharePoint interface so that they can get more business done. They want to consume and produce data from a number of devices, and for it all to end up in the same place, consumable by everyone else, and interacting with their new workflows and forms and automation. And they want their environment to look nice, using or extending the corporate brand. People don’t want to work amid clutter, whether in the real-world or digital world.
Translating Requirements
Understanding all of that, there are some powerful and enticing options out there. There are amazing examples of SharePoint sites built by consulting firms or by skilled internal teams that are able to provide everything outlined above — and make it aesthetically pleasing, to boot. And there is a massive SharePoint partner ecosystem out there with tools, templates, and guidance on doing some or all of what you want — and part of their appeal is the idea that it will take less effort to deploy what partners have built rather than build yourself.
Which brings up the question — is it better to build or to buy your SharePoint solutions?
Like everything else within the SharePoint realm, it depends. Specifically, it depends on your business requirements and whether something off the shelf can meet those requirements, or whether the business need is strong enough, unique enough, to justify building something yourself. Remember that your business requirement is not to “deploy SharePoint.” That’s just a means to an end — a tool to satisfy your business requirements. You can have the most successful deployment, and yet if end users don’t use the system, you’ve failed.
Build or Buy Considerations
How do you answer this question? Where should you focus? What questions should you ask to help you decide whether it makes sense to build out SharePoint yourself, or buy that expertise? There are some things you should consider to help answer that question:
1. Are your able to map your business requirements to specific features or solutions?
As you better understand what your teams are trying to accomplish, identify the features in SharePoint that would address their requirements. Do your best to map features to requirements first, and then look to external solutions that may answer your requirements.
2. Do you understand the out-of-the-box functionality in SharePoint?
As you start to identify gaps — limitations in what SharePoint can do to meet the requirements, find out if SharePoint can be configured (without development). If not, understand what it would take to customize SharePoint. You also need to understand what it will take to administer and support the solution you build (a consideration many forget). As you begin to scope the time, effort and cost of customizing, also look at the cost to purchase or license the third-party solutions, as well as their ongoing costs (licensing, support, administration, and support).
3. Can it / should it be managed in the cloud, or will it be on prem?
Increasingly, businesses are looking at the cloud as a way of driving down overall costs, and much like the government instituting higher and higher gas mileage requirements to the auto industry as a way to force them to think more about efficiency, some organizations are requiring their IT teams to include cloud into their plans — whether or not the technology exists to match what is available on prem today. Understand these corporate governance guidelines, and bake them into your requirements planning.
4. Do you have the right skills in-house?
Most organizations have no intention of becoming an ISV, and so they may not have the advanced SharePoint skills necessary to build, administer, and support long-term the customizations they require to meet their business needs. The cost of hiring and retaining certain skills may be a key factor in your decision on whether to build or buy.
5. Are you prepared to support it long-term?
You might save on buying a third-party tool by not needing more expensive technical resources on staff, but what will the vendor cost in the long-term? And will you need to employ consulting resources from time to time to support your environment, eating into any cost savings from buying versus building? Understand the tradeoffs, and plan not just for today’s requirements, but also for how the platform will grow.
Universal Guidelines
Of course, there is no “best practice” for when to build or to buy. But there are some universal guidelines for scoping out the business need for buying a tool versus attempting to extend or customize, which can be summarized into two categories: technical and cultural.
On the technical front, you need to understand the scope of what is to be delivered. At the root of every decision is to understand your business objectives — without a clear (and shared) understanding of the requirements, you cannot make an informed decision on how to proceed. Once your team agrees on what needs to be accomplished, be clear on the SharePoint gaps — what can SharePoint do out of the box? Sometimes this takes thorough investigation, searching through the online forums and expert blogs. Whether you build or buy, be realistic about the skills you have in-house — whether to develop the solution or to administer/support what you purchase.
On the cultural front, it is essential to know your end user expectations. I’ve not met many end users who prefer to constantly get lost in the user interface of their business systems, so build with the end user experience in mind. Develop solutions that deliver on your business objectives while taking into consideration the way that your end users need to work. What you gain in features and scalability by purchasing you may lose by introducing complexity. Adoption is key.
Whatever your path forward, test repeatedly with the help of your key stakeholders. Run through the use cases you (hopefully) developed with their input, creating process and performance baselines. And finally, quantify success through measurement — show that your technical solution meets or exceeds the business goals.
