Has your company truly maximized the value of SharePoint? It seems like a silly question – why implement a system without understanding its benefits? However, my conversations with tech and business professionals reveal a surprising trend: Many struggle to pinpoint and measure SharePoint’s actual ROI. Even more surprising is the number of organizations underutilizing SharePoint’s potential to cut costs and boost productivity.
While SharePoint’s technical aspects are crucial, this article focuses on what’s often overlooked: the business strategy behind its implementation.
A Vision for SharePoint…
Back in 2009, I was flying to San Francisco for my first VSLive conference. Working at a cosmetics giant, I was eager to explore SharePoint’s potential, especially as it was a relatively new addition to our tech stack.
The conference was incredibly inspiring. I returned energized, eager to share my newfound knowledge about this remarkable tool. However, my enthusiasm was quickly met with resistance from my colleagues in the Global Information Systems team:
[Executive Director – GIS]: “SharePoint? Doesn’t seem special… We can easily create web pages internally. You’re wasting your time.”
[Business Relationship Manager – GIS]: “It’s too basic and unappealing. My clients would never go for it.”
[Senior Developer – GIS]: “What’s the fuss? Seems complex for no real value. Active Server Pages is a far superior option.”
Only my direct supervisor showed a glimmer of interest. While unfamiliar with SharePoint, he recognized my enthusiasm and proposed a meeting to delve deeper. This meeting led to a SharePoint proof of concept (POC) for senior management, which eventually became central to our GIS department. It automated and streamlined our software development lifecycle (SDLC) processes, showcasing SharePoint’s numerous advantages. This success story catapulted me to the coveted title of “The SharePoint Guy”. For the next eight years, I championed SharePoint as a cost-effective productivity tool, streamlining processes and reducing costs wherever possible. However, many within the company remained unconvinced, viewing it as merely a platform for team sites and document libraries. Despite my efforts, selling SharePoint to the entire organization, including senior leadership, felt like an uphill battle.
A Familiar Tale?
In my nine years of experience, I’ve observed two primary ways companies utilize SharePoint:
1. Team Sites for Document Management
These sites, typically created using the Team template, contain one or more document libraries with potentially complex folder structures. Content types, metadata tags, and workflows are minimally utilized. While fully supported by the business unit, members lack formal SharePoint training and haven’t embraced the “Power User” role. Site creation is often handled by the infrastructure or support team based on simple help desk requests.
2. Heavily Customized Sites with Complex Code
These are usually larger sites aimed at a wider audience, such as corporate intranets, HR, and IT.
Initially presented as a cost-effective alternative to expensive content management systems (CMSes), these projects often encounter scope creep. As requirements escalate, so does the need for custom code, eventually reaching a level where support becomes a concern.
This often leads to a deviation from out-of-the-box (OOTB) functionality, resulting in a heavily customized approach. This can range from personalized Master Pages to provider-hosted apps (PHAs) or, as they’re now known, provider-hosted add-in.
I can already sense skepticism – “These are perfectly valid approaches, Tony!” or “Our users are happy with both methods.” While I’m not suggesting these methods are incorrect or inadequate, I believe they fail to fully leverage SharePoint’s potential.
Moreover, these models often lead to a perception of SharePoint being overpriced for its limited use, or IT believing they could have replicated the functionality through web servers, HTML, or a pre-built CMS cloud solution. This leaves both business and IT questioning SharePoint’s suitability for their needs.
Where Did the Benefits Go?
To understand the present, we need to revisit the past. How did you first encounter SharePoint? In my experience, and that of many IT leaders I’ve spoken to, SharePoint’s introduction often comes from the infrastructure team, guided by their Microsoft Enterprise advisors.
Typically, the first SharePoint farm is a test environment provided as part of the company’s Enterprise Agreement with Microsoft. A business client is engaged, and their first site collection, usually a simple team site, is deployed. The client appreciates the document collaboration and sharing capabilities and incorporates the site into their workflows.
While seemingly acceptable, this approach often overlooks the bigger picture. SharePoint is more than just an infrastructure-supported platform; it’s a powerful application environment demanding close collaboration between infrastructure, enterprise architecture, and application teams.
Without this collaborative approach from the outset, companies risk misunderstanding SharePoint’s full potential, leading to inadequate business strategies and utilization plans. This highlights a broader issue plaguing many IT departments: a lack of proper collaboration and strategy.
Your Business Client Holds the Key
Many technical organizations lack a clear business strategy for SharePoint, relying on a simple site request and creation process. This often excludes any governance, potentially leading to an unmanageable volume of site collections and support challenges.
While basic training on key concepts like site collections and Search in SharePoint might be provided, strategic discussions often become complex. To avoid this, many technical organizations limit their strategy to the site creation process. Instead, a gradual approach focusing on core SharePoint features is recommended.
Who are your target users? Are they the internal technical team, regional marketing, or perhaps R&D? As mentioned earlier, SharePoint implementation often originates from the infrastructure team and gradually filters down to the actual users.
Sometimes, business users might have a limited understanding of SharePoint, primarily in the context of large-scale business applications, which is where the second use case usually emerges. Without a well-defined business adoption strategy, achieving widespread and meaningful SharePoint utilization becomes a slow and challenging process for the technical team.
In my experience, most existing SharePoint sites were basic collaboration spaces with document libraries organized into intricate folder structures.
Some folder names were practically sentences to clarify the document types they contained. Metadata tags and content types were nonexistent, just files within folders. Collaboration was limited to sharing these documents within a single repository. This was the extent of SharePoint’s perceived value.
Unsurprisingly, my interactions with business users revealed a lackluster perception of SharePoint. Even some technical colleagues argued that purchasing file shares would be a more cost-effective solution.
Many fundamental SharePoint features were poorly communicated, not just to the business users, but also to some within the technical team. Sold as a revolutionary CMS platform for enhanced collaboration and innovation, its usage was often reduced to basic file sharing.
During initial interviews with business users, I discovered that the elaborate folder structures were an attempt to organize and locate specific files. They were completely unaware of SharePoint’s basic search functionality, let alone best practices. I needed a way to engage users, educate them about SharePoint’s strengths, and demonstrate its efficient utilization.
Building a Stronger Business Case
Based on user feedback, it was clear that I needed to reintroduce SharePoint from scratch, focusing on education. But with an already extensive SharePoint farm in place, how could I hit the reset button?
Since most sites were team collaboration spaces centered around document libraries, that’s where I decided to start. Working with a willing business client, my team and I aimed to restructure their libraries. The goal was to minimize folder dependencies while enhancing file discoverability.
As we analyzed their sites, it became evident that the folder structures represented data elements and groupings of various file types used collaboratively. This led me to leverage a simple yet powerful SharePoint feature: Metadata tags.
I’ve always found that practical demonstrations are the most effective way to teach technology. The challenge with POCs, however, is the cost implication. Developing a full-fledged application that the business might ultimately reject is not ideal.
In this case, the cost was minimal, but the potential value was enormous. We decided to consolidate multiple document libraries, each with over 20 folders, into a single library using metadata and content types. Instead of explaining content types theoretically, we showcased their ability to enhance data structure and govern file metadata.
The Ripple Effect
These files contained valuable information, originally organized into a complex folder system. For instance, a separate folder existed for each of their 15 brands, each with subfolders for marketing, finance, and other categories, which were further subdivided.
While this facilitated file searching, it necessitated a complex business process to ensure accurate file placement. This proved unsustainable, leading to misplaced files.
This presented an opportunity to introduce the concept of metadata. We streamlined the file structure using key content types, incorporating crucial data elements and validation rules. This simple approach, leveraging content types, metadata, and data validation, became the turning point in demonstrating SharePoint’s business value.
With the business’ attention, I conducted a walkthrough of the restructured document library with key stakeholders, showcasing the power of metadata and content types through filtering and sorting.
Their positive response to these basic, yet often overlooked, SharePoint features was astounding. We then created a custom filter page using OOTB web parts to demonstrate further possibilities.
The goal was to avoid heavy customization and focus on core SharePoint functionality before exploring more complex scenarios. The custom page proved to be another success. We hadn’t even touched upon the advanced search capabilities, which I reserved for later stages once basic SharePoint adoption improved.
Unlocking Potential with SharePoint Workflows
In my opinion, SharePoint workflows have been instrumental in educating business users and driving SharePoint adoption within our organization. It was workflows that first captured my attention at that initial VSLive conference, and they formed the backbone of my first full SharePoint POC, which streamlined our SDLC processes.
When engaging with business clients, my initial focus is on their existing processes. These processes are key to leveraging SharePoint for increased productivity and cost savings, topics any business leader is eager to discuss.
I’ve often told senior IT executives that I can practically guarantee SharePoint adoption by focusing on business process optimization. Every business unit relies on processes, and most involve checkpoints or approvals – this is where workflows shine, whether through automated approval emails or task creation.
Once clients grasp how workflows can enhance their processes and reduce costs, I introduce the concept of using approval tasks to establish service-level agreements (SLAs) or key performance indicators (KPIs).
Imagine the insights gained from understanding document review and approval times. This data empowers businesses to optimize processes, create KPIs for monitoring and governance, and even incorporate process improvements into performance bonus programs. This tangible connection between SharePoint and tangible benefits often convinces even the most skeptical business leaders.
Looking Ahead
When Office 365 and SharePoint Online emerged, I understood the value of a hosted SharePoint environment. However, convincing business clients of this new direction was another hurdle. While excited about PHAs, I remained wary of potential cost implications related to application support.
My company had adopted a third-party development vendor model, often leading to complex business applications with significant maintenance and enhancement costs.
As with any hosted model, change is inevitable. We humans are often change-averse, and technical support teams are no exception, fearing the impact on their workflows.
Microsoft’s decision to deprecate InfoPath and the subsequent introduction of Flow as a workflow engine initially triggered a “Here we go again!” response. I struggled to grasp Microsoft’s vision until I explored Flow’s integration capabilities.
Flow seamlessly integrates with various existing applications while also allowing custom integrations. This has made it a central talking point in my discussions around business process optimization through integration with various line-of-business applications.
Embracing Mobility
Mobility has become a standard topic in my discussions with business clients. We discuss responsive web design and how SharePoint leverages it for an improved mobile experience. Microsoft’s dedicated mobile SharePoint app is also highlighted. However, the conversation often steers towards standalone mobile applications.
As soon as I hear “standalone mobile app,” alarm bells start ringing. Such applications often come with high development and support costs. My answer from the SharePoint world is PowerApps.
True to my approach, I immediately develop a PowerApps POC mobile application, leveraging existing SharePoint lists and libraries as the backend data source. PowerApps, as I call it, is a configuration-based development platform enabling rapid mobile application development.
Users can easily create their own PowerApps mobile apps directly within SharePoint. It even auto-generates screens for adding and editing list or library items. Thoroughly tested with leading mobile devices, PowerApps boasts its own IDE and a simple configuration-based language easily mastered by developers and tech-savvy power users alike.
This presents another opportunity to champion SharePoint adoption. Combining PowerApps with SharePoint and Flow, along with push notifications and mobile-native features like location services and phone calls, has made it a favorite topic in my discussions with business clients.
My PowerApps POC garnered significant interest, not just internally, but also from Microsoft’s PowerApps engineering team, who invited me to present it as an example of the platform’s capabilities.
From VSLive to Real-World Solutions
Back then, on that flight to San Francisco, I couldn’t have envisioned the profound impact that trip would have on my career. SharePoint is a truly innovative and collaborative platform, and Microsoft continues to deliver on its vision.
Like any SaaS or PaaS solution, maximizing its value requires a thorough understanding of its capabilities. By continuously improving business processes and exceeding client expectations, SharePoint has become an invaluable asset. I am excited for the future and the possibilities SharePoint holds for both myself and the business world.