If you caught my “Implementing SharePoint” session at DevConnections last month, you know I’m all about the SharePoint journey. The truth is, I spent the better part of the past year learning from our clients to get a full understanding of their struggles with SharePoint, and unfortunately there were many.
I asked about how they were using SharePoint, for what purpose, in what areas of the business, and more. Frankly, those were the easy questions. The difficult questions came later when I asked about adoption rates, expectation setting, and whether they had deployed SharePoint as an enterprise solution.
SharePoint Now and Then
What I found was a true lack of understanding of SharePoint’s capabilities and, moreover, the opportunity that was presented initially. When SharePoint was first released in 2003, the world was a very different place and so were our work environments.
For one thing, document management was essentially the only functionality that companies were interested in performing through SharePoint; and even then it was typically to replace a legacy system. People were not connected to the office in the same way we are today, the demands of organisations were simpler, and the proliferation of cellphones, what we now call smart phones, didn’t exist. The BYOD conversation was null, and reporting was simpler than what we expect today—so, too, were our expectations of a system.
What I was trying to establish in my questioning was a pattern in deployments of SharePoint, regardless of the version or initial purpose that drove the organization to buy it in the first place. I was surprised by some of the things that I heard.
For example, many people reported that they basically “fell into” SharePoint. It was not in the strategic plan or roadmap, nor their IT strategy, or even on their corporate radar. What I heard was that at some point they learned they had licenses to a portal which would give them document management and some simple workflows. Oh, and it was free because of their enterprise agreement with Microsoft. Seems simple enough, doesn’t it?
Another frightening pattern that I noted was around adoption. Most of these companies disclosed that they had virtually no on-going adoption, which, unfortunately, was aligned with the fact that they had put little effort into adoption during the implementation.
I asked about their current adoption and usage of SharePoint, was the system perceived to be critical by the organization? Was it performing important business tasks, alleviating system and employee stress through workflow and automation? Pause….“Not really.”
Today, this is a terrible path to take and I caution everyone reading this to move as far away from that route (if you can even call it a route) as possible.
It’s important to define the strategic need for the business in order to start with your proverbial right foot forward. A company can’t even begin to define its implementation until it has done the groundwork to create a foundation that will purposefully house SharePoint.
The 2013 product was essentially released as Microsoft heeded the lessons it had learned from previous versions. The reality is that SharePoint is an enterprise system that should be implemented as such; given the necessary time and corporate commitments required to succeed.
During the Dev Connections presentation, I asked for a show of hands for the number of people who had ever taken a road trip without a map. There was one hand that went up in the room – there is always at least one, but rarely two. I get a lot of smiles and people who give me a look of “Why the heck would I ever do that?” It seems crazy to leave your house with nothing but a full tank of gas, no maps or purpose.
From that perspective, it’s interesting when you overlay SharePoint into the conversation. Why do companies spend their money on a system only to hand it over to IT or a business unit and let them make a silo, or better yet, a collective mess?
Although I digressed slightly with my rant above, let’s talk about how to address the implementation steps you will want to take. Our focus on how it “should” be done began with aligning to a journey that makes sense for your organization, remembering that a 50,000-person organization and a 50-person organization will make different moves to align. For one thing, the path for the larger organization is longer, therefore additional time will need to be spent getting executives on board, working with stakeholders, defining requirements, and creating solutions that matter.
1. Define your organizational goals. Begin by working with your executive team to define the enterprise goals and how they will identify SharePoint as a corporate objective that needs to be done right the first time. Focus your efforts on identifying the core competencies that make your organization what it is today. What makes the company tick, what drives it to be strong, better, and faster to market than your closest competitor?
2. Empower employees. Do the work required to identify the steps to empower your business units to manage more of their own collaboration and content tools, while freeing IT resources that were previously tied to administrative, maintenance, and customization tasks. Do you remember the last time you spent a day trying to modify the template for a status report? Well, stop that, and focus on the critical information in your organization.
Qualifying your critical content is a step in the right direction. Your ability to ease the efforts required to find structured and unstructured content inside the organization as well as externally will support your long-term growth, as it alleviates the extensive time spent on search every day. Remember, it is estimated that 35 percent of an information worker’s day is spent locating the information he or she needs to do their job.
3. Implement functionality that makes sense. Finally in the competency conversation, look to identify and improve process efficiencies and workflows that will drive collaboration across the enterprise. With your executives now involved, it is time to implement a standard set of functionality across the enterprise, which I’ll call a portal.
The functionality you build does not have to necessarily be rich and solve your toughest organizational issues. Instead, it can be a lightweight process or workflow that makes sense to automate. By “makes sense” I mean one that is popularly used and will drive immediate value to the users and organization.
A vacation request process is a good example place to begin since it will create functionality that everyone in the organization can use. Remember that it is difficult to both substantiate the need for SharePoint and the need to automate a specific process, so be careful.
Leave adoption breadcrumbs in your implementation. We have all been part of a systems project that was put in place with lackluster results, and we need to both identify and sustain the steps that will ensure this doesn’t happen here. These components aren’t complicated, but they are critical to aligning your journey with a purposeful series of checks and balances. One of the most simple and often-missed pieces of the adoption puzzle are those having to do with communication.
Do you remember in high school when the teacher walked in and announced a pop quiz? Aside from the obvious surprise, were you prepared to answer the questions? Deploying SharePoint with a similar lack of end-user preparation will result in exactly the same reaction by your end users, the people you want to be a part of your implementation and get excited about the deployment. The questions of “what, how, and why?” will echo in your hallways for months, likely bringing others into the collective mix of disgruntled employees who want a better system.
Fortunately, communication on a SharePoint project is easier than you might think. For one thing, you already have a built-in system of communication, the portal itself.
I’ve seen many different strategies for how to communicate to your teams. One company set up alerts on their project site so that end users were notified when a new document was placed online. Another customized the login page as a type of status report so that anyone who logged in could get an automatic update on the latest happenings.
Both of these are great strategies, but you can also go with something as simple as a five-minute update in a bi-weekly staff meeting. Whatever method you choose, it is critical to update people often; with a SharePoint implementation sometimes taking years to complete, staying in touch with your users cannot be underestimated.
The Dreaded Project Schedule
Let’s discuss the project schedule. While I’m not necessarily a big fan of these myself, I understand their place and time on the project and the role they play. My biggest problem with plans is that they are essentially a collection of static data that rarely gets updated, save for an increase in your percent complete every now and then. My apologies in advance if this isn’t how you have setup and used your project plan; but if you have done it effectively, you are in the minority.
As I have never personally understood the difference between being 60 percent or 65 percent complete, focus your project plans on the data you’re compiling to classify your tasks, making each one meaningful as you track and manage your project. Regardless of how you plan your work and work your plan, be sure to distribute it (in whatever format appropriate) as often as possible. This is another inclusionary method which speaks to adoption and longterm buy-in of SharePoint.
It’s important to know and support your core competencies as an organization. Be sure to start your tasks by asking the tough questions of the business stakeholders--they are the ones who know what they need, and communication with them throughout the project is critical. You need to put the spotlight on creating expectations that match the output delivered by SharePoint. I hope you can be empowered to create meaningful strategies and adopt functionality that will drive your business forward. Please feel free to reach out with your comments and thoughts.