Blogs

One of the most-asked SharePoint questions has absolutely nothing to do with technology: How do we get started? Whether I am presenting on managed metadata and taxonomy, social computing, governance, or migration planning, someone in the audience inevitably asks this question. It happened again this weekend while presenting my session 'How SharePoint 2010 Stacks up to Your End User Social Media Requirements' at the 3rd annual SharePoint Saturday Los Angeles event. I shared vignettes into a SharePoint environment where search is optimized, where taxonomy management and proactive governance take center ring, and  where end users have been trained on how to use the platform and how to request changes.

And for all those who don't use SharePoint, but possibly a competing knowledge management or collaboration platform, these same issues apply.

I shared my 'best practices' for how social should work within the enterprise, and hands popped up with questions. The first question asked: how do we get started? Of course, I watched as the other hands automatically slid down, as the first question seemed to capture the gist of their queries. I call it the unanswerable question not because it can't be answered, but because the answer needs to be personalized for your company and your deployment. By breaking my advice down to something consumable by the entire room, it may have come out sounding like a bunch of project management platitudes, but the fact remains that these pearls of wisdom really are the key to getting things rolling with your SharePoint planning. I don't care what you're trying to do -- deploying SharePoint for the first time, migrating to the latest platform and re-architecting your farm as you move, or planning to "turn on" all of the social features -- these things should be taken into consideration:

• Make the process transparent and continuous. Always start your projects by outlining exactly how you plan to manage them. If you give people a voice, they are more likely to participate. As they see their feedback being taken seriously, see changes happening to the project based on their input, a funny thing happens -- they provide more feedback, they provide better feedback, and they become advocates for both the project and the process. Think of the best project manager you've ever worked with, and I'll bet they were completely transparent with their communication and documentation. In my experience, the number one reason why projects fail is due to a general lack of transparency.
   
• Understand the business gaps to be resolved.SharePoint is not the end state, but a way of helping you achieve that end state. Work with your team, your business units, and your stakeholders to understand the business needs that are driving your SharePoint projects. What processes can be sped up, what costs reduced, what redundant systems shut down by using SharePoint? Have a specific, targeted list outlined.
   
• Use metrics and feedback to prioritize, cut through personal agendas.The next steps is to prioritize those business requirements, and understand where the highest value and quickest returns will be realized. Agree on the measurements, thereby removing the politics from the prioritization process. Be able to defend your decisions through data wherever possible (usage analytics, time and expense reductions, etc) to keep these decisions as neutral as possible.
   
• Come together with users and management on the solutions.Once you have your business issues prioritized, figure out how you will resolve them. Have the end state in mind for each, know what can be accomplished out of the box, with more advanced configuration, and THEN look at customization. Having clearly defined solutions (what we're going to build) will help inform your planning activities, possibly causing you to re-prioritize. That's perfectly normal. If you're transparent about the changes to plan, how one priority might conflict with another, or where you can accomplish more, and in a shorter time, with a change in your priorities, people are more willing to accept that change.
   
• Ensure a cultural fit.You have a good communication plan, you've identified the business gaps, you have them prioritized, and you've gotten buy in from your key end users and executive stakeholders. You can build it, but should you? Outside of your project team, is the rest of the organization ready for this new platform? What I mean by this: how much of a departure is the new solution from the way people work today? It's something to consider. It might be the best technical solution to your problem, but if the change is too dramatic from the way people work today, they may not readily adopt. Consider this as your 'environmental impact' study before you move forward, and adjust your planning as needed to ensure that what you build out takes end user adoption into consideration.

What I've just outlined is nothing new to any experienced project management team. This is the same approach for any technology or business problem. Understand first, define it clearly and comprehensively, and set up strong feedback loops so that the process is transparent to all involved. It's the secret to project management success boiled down to a handful of steps.

Of course, not every organization is the same, and not every SharePoint deployment looks alike. I often illustrate this point in presentations with a picture of a carton of milk, telling people that there is no such thing as a homogenous deployment. You cannot expect to install the basic functionality, and then walk away. You might be fine for a few days or a few weeks, but once people begin to understand what you can do with something as powerful as SharePoint -- and the need to more closely align the platform with the nuances of your business -- the vanilla version of SharePoint just won't cut it. You can plan on your end users getting smarter as they get more productive. So plan accordingly.