SharePoint Implementation Checklist: Aligning People, Technology & Process

By Dux Raymond Sy
SharePoint adoption in the enterprise is growing at a rapid pace, but many organizations are still struggling to achieve the proper mix of “people,” “technology” and “process.” In the midst of just trying to figure out the technology side of SharePoint, many organizations overlook the people and process side of an implementation.
Pushed even further to the backburner are the “business value” considerations of SharePoint.
What is the purpose of implementing SharePoint in the first place?
How will SharePoint improve operations and drive overall business results?

Here’s a 30-point checklist that covers the business, people, technology and process components of a SharePoint implementation. Use this checklist to make sure that you have all of the correct elements in place during the planning phase of your SharePoint implementation which can apply to a brand new rollout, migration or even custom solution development. If you have already implemented SharePoint, you can use this list to uncover possible gaps and identify areas in need of improvement.

30-Point SharePoint Checklist

Business Drivers

• What are the quantifiable top 3-5 objectives of the implementation? This means defining the value and scope for which all other questions will be framed.
• Does the implementation have a sponsor from senior leadership that will champion the objectives mentioned above? Is there enough support at the right level to prevent starts/stops/restarts?
• Will the implementation be funded out of IT or through the departments or divisions receiving the technology? Are there other major stakeholders that can change scope?
• Is there a critical target date that cannot be missed? What resource costs will be involved to reach the target date? 

People

• Who will define and steer the SharePoint platform as a service? How will this implementation impact other stakeholders and sustain the direction/funding for the project?
• How many potential users will be using the system? Estimate by periods over time such as 200 Q1, 800 Q2, 5000 Q4, etc. to help project support resource needs.
• What support model does the company currently use (e.g. help desk, train power users, online knowledge bases, etc.)?
• How much excess capacity/budget is available for adding SharePoint to the current support mix? What is the resource bandwidth availability and required augmentation?
• Do you have IT professionals in Microsoft Windows Server, Web technologies, Microsoft SQL Server, e-mail, network load balancing, etc.? What additional training or augmentation might be needed?
• Do these IT professionals have sufficient bandwidth for the early peak of activity? Will they be able to sustain the system long-term? Do you need to add personnel for the peak of activity?
• Is organizational change a managed process? If so, is there bandwidth for promotion, training, etc., to make the implementation successful in the organization? Are additional contract resources needed to help with the rollout?
• How are IT policies enforced? More time might be needed to align security if enforcement mechanisms aren’t in place.
• Have you done a stakeholder analysis to understand the change effort? How much time will need to be spent to convince opponents of the implementation?

Technology

• Is your organization already running 64bit hardware/software in your data center? What possible hardware/software costs exist?
• Are your environments virtual and/or full hardware based? Will hardware need to be purchased if the farm needs to expand beyond projections?
• Is this implementation planned to offset current file storage? If so, what does current storage size look like in projection against SP storage (e.g. "we plan to move fileserver based storage to SP to take advantage of versioning and document/record management aspects and today we have 2TB of file shares which we want to condense to 1TB through use of this technology")?
• Thinking about the objectives, what would the number of page visits look like after one year? How many times a day would someone access the system and how many files/lists would they interact with? This projects the farm configuration.
• What SharePoint services are being projected to be used in the first year (Excel Services, PerformancePoint, InfoPath, Access Services, etc.)? This might increase the amount of support and training required.
• Is there sufficient storage and server capacity to support this implementation for at least one year (2-3 years would be preferable)?
• Is the Microsoft stack of products currently well used in the environment (Start-up, training, support costs)?
• If Microsoft Office is currently being used on the desktop, what version(s) are supported and will there be a desktop rollout component?
• Will there be non-Microsoft computing platforms used with this implementation (e.g. Mac, iPad, Android devices, non-Microsoft smart phones, etc.)? If so, how knowledgeable are your current development/branding resources in supporting multiple browsers (support, UI development and training costs)?

Process

• If this implementation is to enhance current processes, how stable and defined are those processes (how crisp will workflows or custom code be defined)?
• Has a gap analysis been done to map the processes to the technology to see if customization will be required? What is the potential amount of custom development?
• Is branding important for this implementation (look and feel customization)?
• Will this implementation support custom programming (multiple environments and lifecycle processes)?
• How does this implementation fit into your current data security and disaster recovery processes? Will you need additional offline storage and recovery?
• Will there be external company resources that will need to access this implementation (firewall and additional environments and security considerations)?
• Are there compliance regulations that must be met (SOx, HIPAA, etc.)? This can add additional levels of configuration complexity.
• Are there IT Audit requirements? Will there need to be additional storage for logs to support the detail required?

5 SharePoint 2010 Configuration Mistakes

#1: Using Virtualized Microsoft SQL Server

Virtualization isn't bad. But virtualization allows administrators to make mistakes on a much grander scale. Take virtualizing SQL Server. In the context of SharePoint, this process can be especially painful. The main mistake I see when virtualizing SQL Server is overcommitting the host, be it through RAM, CPU, or drive space. Because everything in SharePoint is stored in SQL Server, if SQL Server is slow, SharePoint is slow.
If you can't get a physical SQL Server box, then at the very least ensure that your virtualized SQL Server has a fighting chance. First, make sure that its virtual drives aren't thin provisioned. I/O is one of the areas in which virtualized SQL struggles the most, and thin-provisioned drives exacerbate that problem. Also try to put the SQL Server guests' virtual drives on their own spindles on the host. Doing so should improve I/O by preventing SQL from fighting other guests for time with the drives. Finally, you shouldn't allow the virtualization host to overcommit its RAM. If the host must swap to meet its RAM obligations, then it's slowing down SQL Server.
Brent Ozar has recorded a brilliant video on how best to virtualize SQL.

#2: Using the Farm Configuration Wizard

Using the Farm Configuration Wizard was a pretty common mistake when SharePoint 2010 first came out but thankfully has diminished as our familiarization with SharePoint 2010 has increased.
First, and maybe most heinous, is that all the databases that the wizard creates have nasty globally unique identifiers (GUIDs) at the end of their names. The wizard also creates a content web app, at http://servername, that just doesn't scale well. To add insult to injury, the wizard creates your My Site host on that same web app, at http://servername/my.
Finally, the wizard encourages you to create service applications that you might not actually use. It's tough to resist the siren song of those check boxes, I know.
The Farm Configuration wizard leaves its dirty handprints all over SharePoint, and it can be a challenge to clean up all of them. However, a few places can be easily fixed.
Start with your web apps. Create a web app for My Site and give it a Fully Qualified Domain Name (FQDN), such as mysites.company.com. Create a My Site host at the web app's root. Use the Windows PowerShell cmdlet Move-SPSite to move any My Site to one content database, and then attach that content database to your new web app. You'll also need to adjust your User Profile Service and tell it about your new My Site location.
Next, clean up your service applications. Go through your list of service applications and delete any that you aren't using. You gain no benefit from having a service application that you aren't going to use for another six months. After you've deleted unnecessary service applications, stop the associated service instances (also called services on server) that power them. If possible, remove the GUIDs from the service application database names. The technique for completing these tasks varies among service application; the Microsoft article "Rename or Move Service Application Databases (SharePoint Server 2010)" has directions for all the service applications. Of course, take good backups before doing any of this.

#3: Using One Account for Everything

Security is complicated, and SharePoint doesn't necessarily make it any easier. Using just one account -- maybe even the coveted Domain Administrator account -- is so easy. We've all done it, even though it's a bad idea. When you use an existing account, you open up SharePoint to several security issues. Anyone who knows the account password can do anything in SharePoint, so you can't separate duties. You also lose the ability to audit who made which changes. And if that common account password is compromised or needs to be changed. Even if you use one dedicated account for SharePoint, you leave yourself vulnerable to attack. If that account is compromised via a security exploit, the bad guys will have access to everything in SharePoint.
To fix this mistake, Add the sp_webapps and sp_serviceapps accounts as managed accounts.
You can change the default content access account for the Search service application at the Search Service Application page. Under Central Administration, Security, Configure Service Accounts, you can change the accounts that other processes use as well. (You can even change the Farm Account there. I've done so in test environments but haven't been brave enough to do it in production.) If you're using the User Profile Service, make sure that your new sp_userprofile account has the correct permissions in Active Directory (AD), and recreate your AD connection in the User Profile Service.
You can also use the steps that I describe in "How to create a SharePoint 2010 admin account and stop using sp_farm" to give an account the correct permissions to administrate SharePoint, without needing to use another highly privileged account.

#4: Keeping Default SharePoint Database Settings

When SharePoint creates its multitudes of databases, it makes some bad assumptions. Take the autogrow settings: The database files grow by 1MB at a chunk, almost ensuring that they're going to autogrow with every upload. Not only does this slow down SQL Server (which slows down SharePoint), but it also results in database files that are spread all over your drives in itty-bitty 1MB chunks.
SharePoint also creates most of its databases, notably the Config and Content databases, with the recovery model set to Full. Although this is great if you want to recover data, you must manage the process correctly or those sneaky .ldf files will slowly, methodically fill your hard disk. If you think users get upset when SharePoint is slow because of fragmented databases, you should see how angry they get when SharePoint stops completely because the SQL Server drives are full.
To fix this mistake, set your databases' autogrow settings in such a way that they don't need to grow frequently.
For most farms, I recommend changing the 1MB autogrow to something like 500MB or 1GB. Autogrow should also be a last resort. Someone, either the SharePoint administrator or a dedicated DBA, should pregrow your databases so that autogrow is unnecessary.
Your recovery model setting needs to be consistent with your disaster recovery plans. If you need your transaction logs, make sure you're performing routine log backups to keep those .ldf files in check. If you don't need your transaction logs, then consider switching your databases to the simple recovery model. Doing so will keep your .ldf files from swelling up like a nasty bee sting.

#5: Not Installing a PDF iFilter

Most organizations have a tremendous number of PDF files in their SharePoint farms, and those files represent a wealth of information. End users want to be able to discover that information by using SharePoint Search. Getting users excited about SharePoint Search is a great way to get them excited about SharePoint in general.
Installing a PDF iFilter is fairly easy. Adobe has a free PDF iFilter that you can install. You can find the download link and detailed installation instructions in the Microsoft article "SharePoint 2010 - Configuring Adobe PDF iFilter 9 for 64-bit platforms." You need to install the iFilter only on those SharePoint servers that run the Search Index role, although installing it on the rest of your SharePoint servers doesn't hurt. If you have a large farm and want to reduce the time needed to index your PDF files, you can use the PDF iFilter from Foxit. This product has better performance than the Adobe iFilter but isn't free.

a “solution” means just that—a solution to a problem

After your SharePoint implementation is up and running, users start to discover its capabilities and to demand solutions to business problems. How do you help users solve business problems with In fact, many solutions can be built with no code, using browser-configured functionality of lists, libraries, and content types, along with SharePoint Designer, InfoPath, Access, Excel, and other Office client applications.
From my point of view, There are three “best practices”—that create a trifecta for success.

Self-Help

Much of SharePoint’s powerful functionality is easily accessible to end users through the browser-based UI, SharePoint Designer, InfoPath and Office clients. Just because it’s easily accessible does not, unfortunately, mean that it’s easy to figure out how to build a specific solution—such as a form or a workflow to support a business process.
Even fundamental components—lists, libraries, content types, and metadata (columns)—are not necessarily straightforward to end users, particularly as they are focused on addressing a yet-unsolved business problem with SharePoint.

I am not a fan of the following statement:
“We sent our users to a five-day course on SharePoint.”
I’m a MCT. So for me to say, “Do NOT train users to use SharePoint” may seem surprising.

I do believe that users need various levels of training on SharePoint—at least a fundamental understanding of some of the core components and concepts. But my experience is that it is not effective—or at least not efficient—to teach a new user “everything they need to know” about things like workflows and forms and the inner workings of SharePoint because, simply, it’s too much.
What’s more important, in my opinion, is that users see the potential of SharePoint as a business problem solver, and that they know where to go for help.

When a user needs to create a solution—a form with a workflow for example—they only need to know the steps for doing so with InfoPath and SharePoint Designer for a couple of minutes or an hour. It’s at that moment that you must have resources ready to help the user succeed in helping themselves.
Google and Bing are not the best answer. There’s a tsunami of information much of which is irrelevant to your specific business, poorly written, or inaccurate.

Point users to specific resources, including the Microsoft Office website and to other selected resources that you find accurate, helpful, and relevant.
I also recommend two specific sets of resources as an internal training and knowledge base. Fellow MVP Asif Rehmani’s SharePoint Videos provides hundreds of short video clips that are excellent at providing just-in-time guidance to specific SharePoint tasks, including and importantly SharePoint Designer and InfoPath. Another MVP, Rob Bogue, offers the SharePoint Shepherd resources which tend to be more “text-and-picture” (versus video) based, and which cover many of the core concepts and functionality.

Community

Your users are the best sources of knowledge about how to use SharePoint in your environment, to solve your problems. You are missing out on a golden opportunity if you don’t capture this resource from Day 1.
Create a discussion forum about SharePoint usage. Keep it focused on usage—have a separate forum for technical support. Spotlight your internal evangelists and success stories.
A build a library of solutions. Again I mean this in the broadest sense.
Find a way to collect the knowledge that your users build about using SharePoint in your environment. A wiki and a library where they can drop documentation about “How I built X” is a start. Create a gallery where templates and other solutions can be found.

Escalation

Above all, there needs to be someone—or a team of people—to whom SharePoint usage questions can be addressed.
Someone who really knows how to use SharePoint and the tools listed earlier—or at least someone who is capable of “figuring it out” on demand.
Ideally, this person is highly skilled with no-code development (browser, SPD, InfoPath and Office) and has a knack for business analysis—for eliciting real requirements.
Even more ideally, this person or team can drive the development of self-help resources and community, so that as your SharePoint implementation scales, you do not need to scale the escalation resource, but rather escalation needs start being filled by self-help and community.
Most ideally, the escalation resource ends up putting themselves out of business by effectively integrating their knowledge and experience into evolving self-help and community resources.
At several clients' locations, I’ve worked with the person in this role. Honestly, these people tend to be among the most vibrant and exciting people I work with.
They’re expert, enthusiastic, and deeply aware that SharePoint doesn’t really matter—the business matters. And that focus on business first means that business problems do get solved.

7 SharePoint Predictions For 2012

Dan Holme, AvePoint's Chief SharePoint Evangelist, posted the following hot post.

1. The Forecast: Cloudy

With the introduction and success of Office 365, 2012 will see more businesses looking to take advantage of the cloud. As additional functionality is introduced to the online platform to bring features up to par with on-premise SharePoint 2010 environments, collaborative workloads such as team sites and extranets are likely to be migrated into the cloud, allowing anytime, anywhere access to business data. Businesses are likely to take a ‘best of both worlds’ approach by buying into hybrid solutions and plugging the gaps between on premise and cloud with the help of third-party software.
One feature that could be added to Office 365 in the near future is the introduction of an ‘app store’ for SharePoint solutions. In addition, the cloud is also likely to be used more and more as a replacement for temporary infrastructure, becoming a replacement for SharePoint development, testing and proof of concept due to its scalability and flexibility.

2. Tighter, Stricter, Stronger

Governance will be an important trend in 2012, as the amount of data that businesses are required to store continues to grow. In fact, a study released by research firm IDC, Extracting Value from Chaos, states that the world’s data is doubling every two years. This is making it increasingly difficult to find documents and manage site sprawl.
The increase in data will drive businesses to implement governance across their SharePoint deployments in order to better manage the content while at the same time ensuring that the data is not accessed by unauthorised personnel. As such, 2012 will see businesses develop governance plans that include input from both a business and IT perspective, imposing stricter rules on access and data management.

3. Consumerisation of IT

Consumerisation was huge in 2011 and is primed to continue in 2012. A wide variety of computing devices, tools and platforms have permeated the enterprise, and SharePoint has addressed this consumerisation trend by supporting various browsers, operating systems and devices. However, as it stands, mobile support is very limited and focused only on the Microsoft mobile environment. Analyst firm Forrester Research expects third-party software to make SharePoint more accessible for other prevalent operating systems in the near future.

4. Moving onwards and upwards

Businesses that are currently using earlier versions of SharePoint today are likely to focus their attention on upgrading or migrating to SharePoint 2010. New features and functionalities supported by the 2010 platform including, social and enhanced enterprise search functions, are appealing to SharePoint users due to the opportunity for fast return of investment.

5. Mind the gap

According to Forrester Research, lack of IT skills is an issue for businesses that have deployed SharePoint. The broad scope of technologies that Microsoft has built into SharePoint creates a complex technical environment. As businesses increasingly acknowledge the need to provide support for continuous improvement, adoption and engagement, training and education will be a priority for SharePoint users. Until administrators are adequately trained to manage this evolving platform, the ability to fully optimise SharePoint is limited. This year, third-party vendors will look to address this skills gap and reduce the complexity of SharePoint through automation.

6. Taking Control of Data

In 2012, businesses will be looking to concentrate and consolidate content in their SharePoint deployments. Storage optimisation solutions for SharePoint will be the drivers behind this consolidation effort. One such solution is SharePoint’s Remote BLOB Storage (RBS) APIs. However, RBS coding can be complex and time consuming, so expect to see third-party vendors plug this gap through storage optimisation software solutions and solutions that are built directly into the storage hardware.
Alongside this, organisations are starting to apply ECM methodologies, such as taxonomy and document holds in SharePoint. This will encourage businesses to focus even more on governance and planning.

7. A little birdie told me….

Social networks are one of the big trends of 2012. Businesses that deployed SharePoint as a collaboration and file share tool are now looking for the next step. Microsoft has been touted as the ‘Facebook for the enterprise’ and is a leader in the 2011 Gartner Magic Quadrant for Social Software in the Workplace. Businesses will want to take advantage of SharePoint’s new found social capabilities, as well as out-of-the-box enhancements. Expect to see more social features and functions to be added throughout 2012 by both Microsoft and third-party vendors.
2012 is set to be a year when businesses will change and develop the ways in which they use and interact with SharePoint. There will be a greater emphasis on governance and planning, and businesses will also look to unlock SharePoint’s full potential through its cloud, mobile and social features. Where SharePoint doesn’t improve natively, third party vendors will offer a solution to help companies maximise the value of this collaboration platform.
2012 will no doubt be another strong year for SharePoint, and this summer Microsoft will release the public beta of the next version of SharePoint, currently code named “SharePoint 15,” and many pundits expect Microsoft to make a big announcement at SharePoint Conference 2012 in Las Vegas – watch this space!