1.

ASSUMING SHAREPOINT WILL SOLVE THE PROBLEMS OF THE SHARED DRIVE
Many organizations falsely assume that just by migrating the folders and assets from the common Shared
Drive into SharePoint they will achieve document and knowledge management. 500 GBs of mismanaged
and poorly categorized files on a network drive is still 500 GBs of mismanaged and poorly categorized files inSharePoint; except now with a more expensive hosting and management cost.
SharePoint’s vast array of document utilities and solutions only prove their business value when they
participate in a managed technocracy of sites, libraries, security and configurations that support theorganization’s business rules and knowledge management (KM) schema. Ultimately, organizations will bedisappointed in SharePoint if they rush to migrate into SharePoint without establishing a KM schema andcontent migration path for users. Six key migration best practices include:a.

Working with experts who have experience architecting large SharePoint portals and are familiar
with how to create a technocracy within an organization.

b. Appointing departmental cybrarians responsible for re‐mastering content in advance of amigration.
c.

Establishing bipartisan collaboration between the portal architects and the content owners tocreate a portal taxonomy that supports the new document management standards.

d. Establishing new classification and labeling standards both in documents and in portal libraries.

2.

e.

Batch processing all content to remove all forbidden characters in file names that impede a smoothmigration.

f.

Providing both virtual training and transition support as users take ownership of their content inthe new portal.

FAILURE TO ESTABLISH THE OPERATIONAL PREMISE OF THE PORTALSharePoint technologies support hundreds of different scenarios ranging from collaboration, to businessprocess applications, to content management. MOSS 2007 has so many new features that it is entirely
possible that the platform could be fulfilling a multitude of functions such records management, document
conversions, and translation management simultaneously. From an implementation standpoint there arelots of questions that if not addressed, can severely limit the business value of creating a SharePoint portal
and cripple a portal from the beginning. Is SharePoint going to be an Intranet, Extranet, or Self‐service site
platform? Is this solution designed to provide collaboration, content management, workflow, or businessprocess solutions? What are the trust boundaries and security protocols employed horizontally andvertically in the site collection?
Creating a SharePoint site is easy, however creating a sustainable portal that factors in the organization’s
needs is an engineering discipline. Unclear objectives can severely stunt the growth of the portal to neverreaching a point where it could achieve Integrated Managed Services (IMS). Ultimately, working withexperienced architects and establishing the operational premise and zones of the portal provides a solutionthat meets the organization’s need from the onset rather than through a discovery process in a production
environment.

3.

FAILURE TO CONDUCT CAPACITY PLANNING AND SYSTEM ARCHITECTURE
Organizations that fail to conduct capacity planning create the risk that their SharePoint solution could beoverwhelmed, deliver poor performance, or might ultimately fail. While WSS 3.0 can run on a single laptop
with a desktop engine, an enterprise deployment of MOSS 2007 can easily employ a half‐dozen servers eachwith a dedicated role in the farm. With dozens of hardware, software and configuration variables, what type561.999.8888

www.softwarefx.com

800.392.4278

of infrastructure is required to deploy the solution and meet the storage, use, and collaboration needs of theorganization?
The goal is not to create an environment that is capable of handling the largest of missions at incrediblecost. Rather, it is to intelligently design an environment that meets the scenario of use based on past,present, and anticipated future needs of the organization. As the scope and mandate of a SharePoint
platform increase, so can the demands on the environment in which it runs. Thankfully with its modular
components, SharePoint products and technologies allow a SharePoint deployment to scale‐up and scale‐out as needed to support changing needs.
The bottom line is that spending a few hours in conducing capacity planning at the beginning stage of a
SharePoint initiative can mitigate risk and ensure that the solution will deliver expected results. Thisapproach ensures that the platform provides a stable solution and that there is a proactive approach to its
design rather than a reactive one when it fails.

4.

ALLOWING INDIVIDUAL TEAM SITES OR PROJECTS TO DEFINE, CONTROL, OR
INFLUENCE PORTAL TAXONOMY
SharePoint technologies are exciting and accessible to all users, not just technologists. That level ofopenness is purposeful and fosters the support and participation of every class of user. However, many
SharePoint implementations have a consultant, department, project team, or individual feel that theyshould define the shape and design of the portal. Due to the conditional display of SharePoint sites, contentand tool bars, a user many not have a full understanding of the master plan, taxonomy, or trust boundaries
within a large SharePoint Portal. Their influence or request to steward architecture can create a problem forthe planned design of the platform.
SharePoint engineering is a specialized discipline and like a regular website, a website done by committee
will never be done. Successful SharePoint deployments thrive based on the healthy interaction of definedgroups of qualified individuals by the following constructs:

5.

•IMPLEMENTATION TEAM: Technical team of SharePoint engineers/service providers who are themaster architects of the platform and steward its future governance and development.

•STAKEHOLDERS: The Stakeholders team is usually comprised of the organization’s SharePoint project
lead, key principles, and possibly beta‐users. This group is responsible for contracting the solution,
managing requirements, and overseeing it into fruition.

•BETA‐USERS: Power users who are the future owners of an application, or serve a role in user training
acceptance. This group plays an active role is testing new sites and applications to ensure they meettheir requirements and intended scenario of use.

•END USERS: Intended users of the site or application that receive access upon the solution being
approved by the Stakeholders and Beta‐Users teams.

LACK OF END USER ACCEPTANCE, TRAINING, AND SUPPORT
Installing SharePoint does not create collaboration. Technology only accounts for 25% of a successful
collaboration model and a SharePoint Portal is only as strong as the mandate and focus of its use andadoption. Regardless of how well it may be designed, how many amazing business applications there are,and how much organizational information is stored, SharePoint is ultimately dependent on users to find,access and use it.
Many SharePoint deployments focus too much on reaching innovative new heights from their beginning561.999.8888

www.softwarefx.com

800.392.4278

rather than establishing a base platform. The truth is that if a user hasn’t learned how to find organizational
information, taken ownership of their departmental site, or understands how to upload a document they are
not going to participate in an enterprise application, workflow, or line‐of‐business process scenarios. Until
users establish residency into the SharePoint environment, they are not citizens that can drive or participate
in business processes.
To facilitate user acceptance it is necessary to provide end user training. Unfortunately the substantial cost,time, and physical absence of attending on‐site classes is not feasible for equipping the entire organization
with a common skill set to collaborate together and use the tools and utilities of SharePoint sites. By
providing a Virtual Training Center (VTC) SharePoint users get immediate training on skills important totheir role and are not dependant on a physical class or training budget to learn how to use SharePoint.
Information workers can obtain training specific to their role/function in the organization and organizations
that use virtual training accelerate the rate at which their staff become active citizens in the SharePointenvironment.

6.

NOT ESTABLISHING A DISASTER RECOVERY PLAN
The moment there’s a single document or application in the SharePoint site is the moment yourorganization has dependence on it. Often times the excitement to build a powerful SharePoint portal
consumes the implementation team and a critical component is overlooked. Without a plan in place torestore the solution in the event of a loss, one is gambling with the operations of the organization. Thebottom line is that small investments into disaster recovery and continuity planning in the onset of a
SharePoint deployment can mitigate large future risks and costs if there is an event or loss.
Disaster Recovery (DR) refers to the practice of proactively preparing for a total loss of the hardware, stores,and databases that run the solution by establishing a backup and recovery solution from the onset of theportal. This plan could be as simple as making nightly backups of the databases, or as complex as having
offsite storage of backups and ghosted images made of every server in the SharePoint farm.
Business Continuity Planning (BCP) refers to the architecture of establishing a redundant array ofinfrastructure to provide failover support for various components of the solution. The question to ask is in
the event of a major loss, how many seconds, minutes, hours or days could the organization go without theSharePoint site being available again? Small things can help provide BCP for an organization, but costs rise
exponentially with each added layer of redundancy. Depending on the organization’s needs, a backup
domain controller, or even a full load‐balanced farm could provide a seamless experience in the event of theunforeseen.

7.

FAILURE TO ESTABLISH APPROPRIATE SLA’S, STAFFING, OR MAINTENANCERESOURCESIn addition to development services, SharePoint technologies require governance, support andmaintenance. Regardless of whether one is using WSS 3.0 or MOSS 2007, the size of the farm, or the size ofthe portal, there are three core categories which require staffing for management, maintenance andsupport:
Hardware:
Software:Portal:Servers, network, and DNS
SharePoint technologies installed on all front‐end web servers
The SharePoint portal which is the organization’s website

Managing one, let alone all three aspects of a SharePoint portal require staff that has expertise, past
performance, and time available to provide support. Most organizations have IT staff to support routine
hardware and software support, however do they have the ability to take on a set of responsibilities that
require 2.5 Full Time Employees (FTEs)? Tasking network operations to equip the organization with a561.999.8888

www.softwarefx.com

800.392.4278

SharePoint solution may get SharePoint installed, but it does not represent a sustainable solution because
the individual/department already has a full workload, or that they have no previous experience managing
and developing SharePoint technologies.
Microsoft has documented the minimum staffing recommendations in the MOSS 2007 Administrator’sCompanion (page 55). Depending on the size and scope of the SharePoint portal one may need between 2‐
20 FTEs to support the solution. Organizations lacking the resources or expertise to manage SharePoint
technologies usually go with a hosted solution, or have a vendor whose core competency is SharePoint
provide management, maintenance, and development services to one if not all aspects of the portal.

561.999.8888

www.softwarefx.com

800.392.4278