SharePoint Planning: Focusing on 4 Key Areas

By Christian Buckley (@buckleyplanet) Feb 27, 2012

In the early days of SharePoint, the emphasis from experts and Microsoft's marketing teams was on how easy it was to deploy and begin using the platform. And they were right. Teams found that they could (and still can) quickly set it up and build simple solutions to meet their specific needs. But those that pushed the platform for its simplicity often left out one little detail: planning.

A lesson I learned early in my career: the easier a technology is on the front end, the more complex it is on the back end. This is not necessarily a reflection of how difficult it is to administer or develop for a platform, but speaks more to the complexity of what is underneath the hood.

Roll out something as powerful and dynamic as SharePoint, and you had better have a plan. How will it be used? How will it be scaled? How will it be supported? The key to proper planning for SharePoint is understanding the culture of your organization, and the business application of what you are trying to build.

Create Your Strategy

It is important to understand how teams within your workforce relate to each other, how they work across teams and individually, and how they use technology to move the business forward. It's no small task to go in and ask these questions, and then build a strategy. Most companies skip it. And many of them come to regret that decision later when they run into scalability issues. Remember that every SharePoint deployment begins as a business analyst activity:

1. Understand the users and their roles. Seems simple enough: know who you are talking to, their pains and pressures, and where process and tools can make their lives easier. Understand how much of their day-to-day revolves around activities that should be automated.

2. Map out their key use cases, the critical business processes to be resolved. Within each role, each job description, people have primary tasks to which they are assigned. Sometimes the role doesn't fit the real-life function. Don't make judgment calls — just document the way things are today, how they work, and let the process reveal duplication and inefficiencies.

3. Develop robust use cases, and circulate these models to all key stakeholders for feedback. Nothing communicates ideas better than a visual representation. Allow internal business groups to see how their partner groups envision their own roles, and the interactions with other groups. Allow them to provide feedback, strengthening your future solution.

4. Architect your solution. Take what you have learned, compile your master plan, and build. This is not simply a deployment activity, but an architectural activity. If you were to build a house, you would have an architect develop a plan that takes into account all of your ideas and needs, but organizes them into a sound structure that meets all codes, that takes into account the limitations and tolerances with which you are building, and also considers long-term plans. The same can be said for the architecture of your SharePoint plan.

5. Test, refine, and test again. SharePoint is a great platform for agile development. Build in incremental steps, testing at each step of the way, taking in end user feedback and improving on your original designs. Rinse, repeat.

6. Implement a process for continuous improvement. SharePoint is not a build once, walk away sort of platform. It requires ongoing involvement — both from a governance standpoint to ensure that policies and procedures are being followed and the system optimized, but also for the simple fact that as people begin to use SharePoint and get more productivity out of the platform, their needs mature and the platform must grow to meet these changing needs.