Has anyone at your business ever considered whether they were getting the most value from SharePoint? On its surface, this appears to be a ridiculous question. Why would a company implement SharePoint if they haven’t already determined its true benefits and overall value ?

But in my day-to-day conversations with other technical and business people I am amazed at how often they are unable to identify and quantify the real ROI they see in SharePoint. Even more amazing is how many companies have not fully utilized their SharePoint environment to reduce overall business cost and increase productivity.

The technical specifics of SharePoint are important, but in this article, I want to share with you more about what’s typically missing from the business strategy of companies that use SharePoint.

Why Use SharePoint: A Vision…

On a Sunday back in the winter of 2009, I sat in my window seat, eagerly staring out of a 747. I was heading to San Francisco to attend my first-ever conference, VSLive.

At the time, I was working at a major cosmetic company. I was excited to attend the SharePoint classes that I had registered for: It was a relatively new technology stack within the company and I wanted to see for myself what SharePoint could really do for the company.

I was not disappointed. I left San Francisco with such excitement, a feeling that I had thought was long gone from my professional career. I was so eager to get back to the office to discuss this amazing tool with my team…only to be jerked back to the reality of my existence as a director in the Global Information Systems team:

[Executive Director – GIS]: “Sure, I have heard of SharePoint. I don’t see what all the fuss is about… We could do the same web pages within our own web farm. I think you are wasting your time.”

[Business Relationship Manager – GIS]: “It’s just too plain and ugly. I will never be able to sell this to any of my business clients.”

[Senior Developer – GIS]: “What’s the big deal? I don’t see it adding any value. It looks way too complicated to work in. I think Active Server Pages is a much better direction.”

The only person to show even a little bit of interest was the director to whom I reported directly. He didn’t know much about the technologies within SharePoint, but he did know that I was way too excited about this to simply ignore it.

He asked me to set up a short meeting for me to discuss this technology a little further. That meeting led to us engineering a SharePoint proof of concept (POC) for our senior management that would eventually become a core component within the GIS department. It would automate and streamline our new software development lifecycle (SDLC) processes and lead the way to the company embracing many SharePoint advantages, catapulting me to the prominent level of “The SharePoint Guy”. For the next eight years, I would spend much of my time at the company utilizing SharePoint as an amazing low-cost productivity tool. For those who would listen, I would improve many business processes and reduce their costs, but there were still too many sites within the company that were simple team sites with document libraries. I was just one person, swimming upstream to sell SharePoint to not only my business, but to the senior-most levels within the organization.

Does This Sound Familiar?

Over the past nine years, I have observed that the uses of SharePoint at most companies come in one of two basic scenarios.

1. Team Sites with Document Libraries

These sites are generally created from the Team template and contain one or more document libraries which can have very complicated folder structures. There is very little use of content types, metadata tags, or workflows. The sites are fully supported by the business unit, whose members have no formal understanding of SharePoint and have not embraced the “Power User” role. The site was created by the infrastructure or support team who can quickly generate a site from a simple help desk request ticket.

2. Fully Customized Sites with a Large, Complicated Code Base

Usually, these are much larger sites with a much larger audience: Corporate intranets, corporate HR, and corporate IT sites are the usual candidates for this type of SharePoint usage.

These projects usually start out with great direction and expectations. They are sold as a low-cost alternative to many of the high-end, expensive content management systems (CMSes) the business has already investigated. Then as the project moves along, the requirements morph and become more complicated. It needs more custom code, which eventually becomes complex enough that supporting the code becomes an issue.

From here things usually spiral out of control. The development team has given up on the premise of staying with out-of-the-box (OOTB) functionality with a limited code base. Instead, they have a fully customized approach, ranging from fully customized Master Pages to possibly a provider-hosted app (PHA) or—as they now call it—a provider-hosted add-in.

I can already hear the sighs and see the eye-rolling. “Tony, these are perfectly valid utilization approaches.” “We have both of these and our users love the sites and we have no issues supporting them.” I am in no way claiming that either of these methods are wrong, nor that one is advantageous over the other, but I do believe that both approaches simply miss the opportunity to fully utilize what the SharePoint platform has to offer.

I further believe that these two models result in the business feeling like SharePoint is way too expensive for what they use it for, or that the IT department feeling that they could have simply developed the same functionality through web servers and HTML pages or a canned CMS cloud solution. Either opinion leaves both the business and IT feeling like SharePoint does not appear to the be the right tool for their needs.

Benefits of SharePoint Gone AWOL?

In order for us to better understand where we are, we need to step back and review how we got here.

I am going to take you back to the simple question of “How did you hear about SharePoint?” From my personal experience, and the experience of many other IT leaders whom I have spoken with, SharePoint as a technical platform was introduced to the company from the infrastructure team with the assistance of their Microsoft Enterprise advisors.

Usually, the first SharePoint farm is a sort of test bed that is given to the company as part of their Enterprise Agreement with Microsoft. At this point, most companies engage a business client and deploy their first site collection with a single team site. The business client loves the document libraries and the ability to collaborate and share documents and so starts to use the site as part of their business processes.

This may sound perfectly acceptable to many of you and, in all honesty, can be a viable use case for SharePoint. But once you delve into SharePoint a little deeper you realize that it is so much more than just a platform that the infrastructure team implemented and supports: It’s a robust application space that requires the tight collaboration of the infrastructure, enterprise architecture, and application teams.

I am not an “anti-infrastructure” person or someone who is politically opposed to the infrastructure team, but without the collaboration of the correct partners from the very beginning, you run the risk of not understanding the full scope of the SharePoint platform and therefore are unprepared for the appropriate business strategies and utilization plan. This situation is not unique to the SharePoint platform and points to a much larger issue of proper collaboration and strategy, one that is facing many IT departments.

Your Business Client Is the Key

Too often, many technical organizations have absolutely no business strategy when it comes to SharePoint. They simply have a small process added to their existing ones on how to request and create a SharePoint site. They may not even include any sort of governance around the site creation process, which can lead to a very large volume of site collections and eventually to a support issue.

There may be some basic conversation and education around the use of some of the larger concepts like site collections and Search in SharePoint. But the discussions of strategy can get very complicated. Because of this, many technical organizations simply decide to end their strategy at the site creation process. Instead, let’s start slow and with the basic key SharePoint features.

Who are your business clients? Are they the corporate technical team, your regional marketing team, or maybe the R&D team? As I stated earlier, SharePoint implementation is usually started by the infrastructure team and then it slowly trickles down into the business client population.

In some cases, your business clients will have already heard about SharePoint in a simpler context when they are considering some large-scale, key line-of-business application, which is where the second use of SharePoint usually starts. Without a clear business adoption strategy, it will be a very slow and arduous journey for the technical team to ensure that their SharePoint farm has the right amount of adoption and use.

In my case, most of the SharePoint sites that were already created when I was introduced to SharePoint were simply collaboration sites with large document libraries with very complicated and convoluted folder structures.

Some of the folder names were actually small sentences so that the team could understand exactly what types of documents were in the folder. There were no metadata tags, no content types, just simply documents sitting in folders.

The entire process of collaboration was the sharing of the actual documents. There was a single repository where everyone was able to share documents and that was the extent of the collaboration for the team. That is what the business client saw as the biggest value of SharePoint.

It’s no wonder that, when I started to speak with people at the business, their impression of SharePoint was unenthusiastic at best. Even some of my technical counterparts started to argue that we could save a great deal of cost if we simply purchased file shares to handle the files and the folder structures.

Many of the basic SharePoint features were simply not communicated properly to my business and to some extent even the technical team. They were sold on SharePoint as an amazing CMS tool with great possibilities to strengthen collaboration and innovation, yet the best we could come up with was file share.

During one of my first interviews within my business, I found out that the reason for some of the lengthy folder structures was to provide some level of structure for people to find certain files. The business was not even aware of the basic search capabilities of SharePoint, let alone following SharePoint best practices. I needed to find a way to engage my business clients so that they could not only utilize SharePoint in a more efficient manner but to also educate them on some of the real strengths of the platform.

Presenting a Better Business Case

Based on feedback from the above interviews with business clients, I realized that I would need to start all over with education. But based on the already large farm we currently had, how was I going to be able to “start over” when things were already moving forward?

Most of the sites were team collaboration sites with document libraries. So I decided to start with document libraries. I had one of my business clients agree to work with me and my team on restructuring their libraries in a manner that would allow them to minimize the folder structures while increasing the visibility of finding the right file that the user was looking for.

As we dug deeper into the structure of some of the sites, it became evident to me that the folder structures were actually data elements and groupings of the various types of files that the team was collaborating on. So I decided to start with a very basic—yet powerful—feature of SharePoint: Metadata tags.

I have always felt that one of the most powerful ways of educating any client on a technology was to simply develop some sort of POC. The issue with POCs is that they do have a cost impact. You have to be careful not to fully develop an application to only have the business decide it is not what they want.

In my case, the cost was minimal, but the value was potentially huge. I decided to take multiple document libraries, each of which had 20 or more separate folders, and recreate it as one document library with metadata and content types. Rather than try to explain content types, it was easier to showcase how using a content type could not only add to the data structure but also allow them to properly govern the additional metadata associated with a file.

The Snowball Effect

Many of the files contained important, highly useful information. The business decided to group the files using a very complicated folder structure. For example, they had a folder for each of their 15 brands, and within those folders, they had subfolders for marketing, finance, and other key categories; within those subfolders they had yet more subfolders.

This had allowed them to more easily find a particular file, or files, rather than having to open and view individual files. But because of this complicated folder structure, they now needed a business process to ensure every file was placed in the right folder. As they found out, the new business process was simply too difficult to manage, and many files ended up in the wrong place.

This allowed me to incorporate and explain the use of metadata to the business. I broke down the file structure into a few key content types, which we then used to include key data elements, along with important data validation. It was this simple approach of content types, metadata, and data validation that was the first major success in my journey to present to my business a better business case for SharePoint.

Now that I had the business’ attention, I decided to have a simple walkthrough of the document library with the key stakeholders. I showcased to them the true value of metadata and content types by filtering and sorting their data.

To my amazement, they were simply awed by some of the basic SharePoint features that they never even knew existed. I then decided to include a custom filter page to really show them what could be done with some simple page creation, web parts, and filtering.

I was very careful not to fully customize any of these pages. I wanted to only use OOTB web parts. That way they would have a better understanding of the basic SharePoint features before I moved forward to more complicated scenarios. The custom page was a huge success and we hadn’t even discussed the extended capabilities the search engine would provide for them. I wanted to hold off on the search engine until after I had better adoption of SharePoint basics.

SharePoint Workflows: The Key

In my humble opinion, SharePoint workflows have been the single most important factor in my ability to educate my business clients and ensure the adoption and use of SharePoint within my organization. Workflows were the first feature that caught my attention at that first VSLive I mentioned, and they were a major contributor to my first full SharePoint POC which incorporated our SDLC processes.

When it comes to SharePoint, the initial conversations that I have with my business clients are usually around their business processes. Business processes are key to using SharePoint to increase productivity and reduce costs, something any business client is eager to discuss.

As I’ve said to many senior IT executives, I can practically guarantee the use and adoption of SharePoint simply through business processes. Every business unit has processes, and most of these processes have checkpoints or points of approval, and this is where workflows come in handy, whether it be through the sending of an approval email or the creation of an approval task.

Once I have convinced a business client of how workflows can improve their processes and reduce their costs, I then educate them on how they can use those same approval tasks to then create service-level agreements (SLAs) or key performance indicators (KPIs).

How great would it be for a business unit to understand just how long it takes for a document to be reviewed and approved? They could then take that information and adopt a strategy to improve the overall process. That would then allow them to create KPIs to monitor and govern the process.

To show senior management’s commitment to the improvement of their processes, they could even include the improvements as part of their bonus objective programs. This is usually the home run that convinces a business client of the true value they can achieve through the adoption and use of SharePoint.

The Future

When I first heard of Office 365 and SharePoint Online, I understood the value of a hosted SharePoint environment, but again I struggled with how to convince my business clients that this new direction was the best for their future. I was excited to hear about PHAs but was also cautious about the potential cost this could have from an application support perspective.

My company had started down the direction of third-party development vendors with an outsourcing model, which can easily lead to vendors creating complicated business applications with a big residual cost for maintenance and enhancements.

Like with every hosted model we need to prepare ourselves for change. As humans, we really do not like change, and as technical support teams, we are often fearful of change and how it will affect our team’s ability to move forward.

When I first heard of Microsoft’s decision to deprecate InfoPath, and then the introduction of Flow as a workflow engine, my reaction was, “Here we go again!” Microsoft was going to make another business decision that would make it more difficult for me to “sell” their newest SharePoint direction. As I started to review what Flow had to offer, I was disappointed in what I saw.

But Microsoft had their future vision, and I just simply did not get it—until I started to see some of Flow’s capabilities with regards to integration points. Flow integrates with many of today’s existing applications, but it also allows a company to create its own integration points. This has made it a major player in my business discussions around improved business processes through integration with various line-of-business applications.

Mobility

This has become a standard topic of conversation that I, as a technical executive, have with many of my business clients. It’s okay to discuss responsive web design and how to maximize it to improve on their mobile web presence. We can also discuss how SharePoint is utilizing responsive web pages to create a better SharePoint experience on mobile devices. Microsoft has even developed a mobile SharePoint application. But usually, the discussion heads in the direction of having a standalone mobile application.

As soon as I hear the words “standalone mobile application,” I hear the cha-ching of a cash register: Many mobile applications have a high cost footprint along with a specialized support model. My answer from the SharePoint world is PowerApps.

Like I’ve done in the past, I immediately begin to develop a mobile PowerApps POC application. It utilizes existing SharePoint lists and libraries as the back-end data source for my application. PowerApps is what I call a configuration-based development platform: It allows for very quick development of mobile applications.

A user can simply select the PowerApps option in SharePoint to create their own PowerApps mobile application. It even automatically creates many of the screens to add and edit new items into a list or library. It has also been tested with all of the current leaders in the mobile device space. It has its own IDE, along with a very simple configuration-based language that can be easily adapted to by a technical developer or even a tech-savvy power user.

Once again I have a great tool/feature of SharePoint which I can use to improve the adoption and use of the SharePoint platform. Incorporate this new tool with SharePoint and Flow, along with push notifications and the ability to use inherently mobile features like location services and phone calls, and PowerApps has become my new favorite point of conversation to discuss with my business clients around the adoption and utilization of SharePoint.

In fact, my POC was not only received by my business eagerly but because of my use of mobile features like location services and GPS navigation, I was asked to present my POC application to the PowerApps engineering as an example of what could be done with the tool.

From VSLive to SharePoint Solutions

As I was sitting there in my window seat heading to San Fransisco, I could never have imagined how that simple trip would have such a major impact on my technical career. SharePoint is a truly innovative and collaborative tool, and Microsoft continues to deliver on their vision and direction with SharePoint.

Like any of the thousands of SaaS or PaaS solutions available to us today, we must ensure that we truly understand how to best utilize these solutions. Continuing to improve our overall business processes and satisfy our business clients, SharePoint has become a key tool in my arsenal. I look forward to the future and what SharePoint will have to offer for me and my business.