The following article is an extract from the book Microsoft SharePoint 2010 Business Performance Enhancement – Taking the basics to the Business with No-Coding Solutions for SharePoint 2010 End Users, by Peter Ward and Michael McCabe.  Featuring a foreword by Mark Miller (Founder and Editor, EndUserSharePoint.com, Chief Community Officer and SharePoint Evangelist, Global 360, and Founding Member, NothingButSharePoint.com), the book can be purchased directly from the publisher Packt .  A 20% discount will be applied to all books bought directly from the Packt site using the promo code P.Ward (valid until the end of April 2011).

 

Most of you will now be familiar with SharePoint's functionality and where it can be applied in day-to-day activities.  This article outlines what SharePoint is not, what is special about SharePoint and why there is considerable value in using this technology, and the user requirement challenges that a deployment will cause.

 

What's special about SharePoint?

Often, senior level management within an organization has already made a decision to make SharePoint the de facto corporate Web platform, and users have to live with this decision and figure out a way for it to work for them. In many ways, this is what is special about SharePoint: the user base can define SharePoint's destiny within the company by embracing it or not.

SharePoint is a platform for the solution, and is not the solution itself, and this is often a challenge for management to understand. We recommend that some kind of SharePoint business architect should be employed to be the SharePoint owner, and a point of contact for its processes and upcoming collaboration initiatives from the business. This person should be accountable to ensure that the technology is working within the organization, and that it is meeting the business needs it was implemented for. This person does not need to be doing everything from the backups to the Site build-outs, but should have the following credentials:

• Some understanding of SharePoint's capabilities and limits
• Good knowledge of the business and its IT requirements
• Ability to speak to senior management about such requirements, and state if SharePoint is a good fit or not

If this person is the Exchange administrator or junior in the organization, there is a high likelihood that the SharePoint deployment process will not be successful because their role is focused not on the business needs of teams, but rather the technology side of the business. This is why business analyzers scope the requirements of a project.

In America, where job title inflation is rampant, the person's job title can be glorified to Internal Collaboration Director, VP of Communications, or CCO – Corporate Collaboration Officer.

 

What SharePoint is not

As we've already touched on earlier in the book, SharePoint is a product that can be a challenge to define, and the reality is that SharePoint has different meanings to different people. This is why we have described SharePoint as the "Ginsu knife" (an icon of "hard sell" marketing as a knife that can do almost anything) of Web platforms because, depending on its application, individuals will perceive the product differently. While SharePoint can perform a lot of functions, the following descriptions of SharePoint are not a good fit for its true capabilities and prescriptive use, and thinking of it in any of the following ways should be avoided.

 

A generic "best of breed" technology

There is a lot of buzz within the IT world surrounding SharePoint, and it does not help to have a keen person always stating, "SharePoint can solve this" to understand if this is the appropriate technology. If SharePoint is customized enough, it can meet your required business needs. But, this is not the best use of people's time and effort, and in reality, without some customization SharePoint will not provide the benefits of an advanced Customer Relationship Management (CRM) system, or Enterprise Resource Planning (ERP) application. So, before you open up SharePoint in your browser, think about what your specific business problem is and how it can be solved.

If your company is looking for a very sophisticated document management system or a CRM application that is unique to an industry, SharePoint may not be the best tool without customization or a third-party add-on.

Yes, SharePoint does have very good document management functionality, but its functionality is geared towards the majority of users' needs in an organization, rather than one or two individual's specific requirements. This is so there is broader appeal to the technology within an organization.

The whole SharePoint architecture is based on customizable templates such as Sites, Lists, and Libraries. The moment that SharePoint Designer or Visual Studio is required for a project or task, the deployment should be viewed as an actual project, and a project manager will be required for help with development, staging servers, documentation, and perhaps a maintenance plan.

 

A defined end solution with an end point

Because functionality can be performed by an end user, there is often the notion among business users that "this is the Web so anything is possible." This creates the tendency to endlessly refine and make changes to the look and feel of field types and displayed information.

A department does not request that IT change the UI colors for Outlook so it is branded with the corporate colors, or insist that the interface is redesigned so the tool bar is at the bottom of the page and menu links can go three levels deep. This is a common request for a SharePoint site, so managing these expectations is key to delivering projects within specific time frames.

With implementations such as a CRM or ERP system where there is a hard release date, and once the application has gone live, there is a freeze on requested functionality. Released SharePoint functionality in most organizations is constantly tweaked even after the go live phase.

This is not a good approach to an IT project. However, this is a common practice with SharePoint functionality releases and should aim to be minimized as far as possible.

 

An online transaction website

Information can be tagged and selected together, but this is not the right tool for shopping cart transaction user activity with credit card actions without a lot of development customization.

 

A standalone Business Intelligence tool

SharePoint provides the presentation layer for graphs and charts, and with its out of the box functionality, it can connect to a data source that could be an SQL cube or a list. SharePoint will not build or refresh the cube, or design the report.

People will often say, "That's in SharePoint," referring to a graph displaying information from another database. In most cases though, SharePoint acts as a presentation layer to capture a graph from another application. An end user can easily capture Web pages displaying cubes and graphs with the Page Viewer Web Part. For the more advanced user, Business Intelligence Center is more appropriate.

SharePoint will complement the BI functionality that is provided with other tools, rather than provide the functions of these tools itself.

Excel files can be rendered in your browser on a SharePoint page using SharePoint's Excel Services, which is part of SharePoint Server. In this case, the Excel file is the data source, stored in a library that is being published to the SharePoint site.

 

An online Excel book in a list

The Edit in Datasheet functionality of a SharePoint list provides an Excel-like look and feel, which does work for basic information in a cell-like format. This is not a replacement for Excel's cell formulas and flexibility to manipulate data and forecasting models.

 

A public-facing company website

You may be surprised by this particular statement, but if your company is small and with mostly static content, and has not purchased the public connector licenses required, then SharePoint may not be a financially viable Web technology.

When a public facing site is designed on the SharePoint platform, there are a lot more unknown variables such as browser formats, mobile devices, and search engine optimization, which can require a skilled team to maintain. However, with a company intranet environment, browser standards and devices can be enforced by the organization.

Significant customizations are required to make a SharePoint site look like a typical website.

Another challenge with public facing websites is that when pages do not load properly or functionally does not work, the website visitors generally do not notify the company that something is not working, unlike an intranet that has a content owner, or a help desk ticketing process to assist with feedback and troubleshooting.

Furthermore, if your company already has a company website set up with something else, why do a rip and replace of the technology?

Clearly for internal websites, SharePoint is the perfect tool.

 

A turnkey switch on solution

SharePoint is a Web platform that will require manpower and effort to configure, but if there is a business process or something unique to a requirement, it will take some effort to have this functional in SharePoint. As you can see from reading this book, much can be done by the user without development, but this will require both learning SharePoint's functionality and understanding how to make changes to it.

There is a perception by senior management in companies that SharePoint is a turnkey solution, and that once it is installed, benefits can be achieved in minutes. This may have something to do with the sales process, or that technology companies tend to focus on their solutions with SharePoint, rather than the process of implementing them.

 

An application that everyone will use on day one

While an accounting system upgrade will have a go live date where on a defined day all the invoices will be processed in the new system, SharePoint does not generally work like this, partly because people can use existing processes such as e-mail or the phone to perform their current tasks that SharePoint can also do.

So, during and after the go live release, users must still be constantly nurtured and educated to use the application, and will be questioned as to why they are not using it.

The biggest challenge for people in adopting a new system is for them to change their daily habits in going about their work.

 

The SharePoint platform

Because SharePoint is a platform for end user solutions and other third-party SharePoint applications to reside, the costs of ownership can dramatically decrease because installation costs and administration is spread across multiple business functions, and end user training is reduced because users are already using the application. This makes deployment of applications easier because the technology is already installed, and cultural acceptance within the company is in turn made easier because the users are already using the technology for other purposes.

This is why a lot of third-party applications have an interface deliberately designed to look like Microsoft Office because it is easier to learn as people are more familiar with it, making the transition to using the technology go all the more smoothly.

Because there are multiple applications working off the same platform, integration of workflow, security, and file management is easier to manage as there is a single interface for administration, user authentication, and user management. This is a major win in breaking down the information silos of a company.

First impressions of SharePoint and what it can do for a department and the individual are very important. If these are not favorable then enterprise deployments can be difficult.

In the past, IT departments have deployed boutique applications for different business requirements that usually provide short term benefits and additional overhead for both users and the IT department. Because of an extended learning curve, more technologies are needed for support, as are additional licenses.

 

A hosted solution

SharePoint can be installed on premises or purchased as a hosted option from a third-party hosting company. Obviously, with the hosted approach, the IT department can be completely bypassed with a deployment. We recommend that if there is a business need that requires SharePoint, and the IT department is reluctant to deploy it in a desired timeframe, the hosted option should be considered with the IT department's involvement. This way, IT governance, security, and policy can be incorporated into the deployment.

 

User requirement challenges

There are a number of challenges that come with obtaining and implementing user requirements which have an equal impact upon the end users, the IT department, and the SharePoint technology itself. These are outlined in the following sections.

 

The user

A department has requested that SharePoint assist with a business process and a requirements meeting is set up.

The department and users need to be aware that there is a process/methodology in achieving the end result. This is not a one shot deal, and they are involved in the success of the project.

Prior to the meeting, the department should have the following answers prepared.

 

Current environment

• What is the department trying to achieve?
• What are the pain points of the current environment?
• Is anything going to be approved (as an?) Excel DOC, submitted form PDF?
• How many steps are involved in the process?
• Who is involved in this process? (Submitters, approvers, or content viewers)
• If there is a business process, how should it flow?

 

 SharePoint environment

• What are the critical success factors of using SharePoint?
• How does SharePoint help these critical success factors? (The more factors ticked off the better. If none are ticked then it goes to the back of the queue).
• How does the process start and end, and are there milestones involved?
• When the process goes live, who will be the owner of the process?
• Does SharePoint bring new business functionality to the process?
• What are the strategic objectives of this initiative to the business?

If the preceding points cannot be answered either prior to the meeting or during it, the business process has not been thought out, and the SharePoint solution is more likely to fail.

Often, the users will not be aware of SharePoint's capabilities, so there will be some educational aspects of such an engagement:

• SharePoint is a template technology. Must users work with this?
• The implemented approach will be out of the box with no coding – are there limitations?
• How can SharePoint be better than your existing process?
• What is required from you, the user?
• How much training is required by you?

At the beginning of an initiative, a simple process can become quite complicated, so it is important that complex requirements are identified at the beginning of the requirements gathering process.

 

IT department

Often, an IT department will implement the free version of SharePoint (Foundation) on a spare server, resulting in rumors within the company about a SharePoint deployment. This may have the effect that a tidal wave of requests for SharePoint applications from business units will come in, and this is all deployed on a test deployment.

Fast forward three months: the server has run out of disk space, the IT department is reading the manual to understand how to restore a deleted file, and users are complaining that SharePoint is not living up the hype. Unfortunately, it is all too often that the IT department will then adopt a have-a-go approach to the SharePoint technology.

A SharePoint installation and deployment needs to be carefully thought through with a one- to three-year plan of business usage and infrastructure considerations. This should be reviewed every year to assess the business requirements.

 

Just do it

SharePoint is a versatile platform, but all SharePoint business processes do not need to be deployed on the same server or within the site collection. Often, companies will install SharePoint on a server or server farm, and insist in driving all their initiatives off it, with the attitude that, we have SharePoint deployed, let's do it on the existing SharePoint infrastructure.

A good example of the Just Do It attitude is when a SharePoint application that was originally designed for employees is now being accessed by non-employees, and access levels are being set up as if they were internal users.

 

Good to talk

The IT department must engage with the business and users. This statement is not profound, but with SharePoint deployments, because users have the ability to customize and personalize so much functionality, the user experience, and ultimately the success of the deployment, is not a result of formal training sessions, but rather from users experimenting and making slight adjustments to features such as alert notification, meta tags, and their My Site so that it is personal to them.

We might estimate that 40 percent of the user experience is the personalization of notifications, pages, and the general look and feel, rather than what someone else did in building out the functionality. This is very different to other applications and is the reason why low touch, low value SharePoint deployments are as they are because the users are not aware of the functionalities that are all out of the box.

Recruiting evangelists throughout the organization is the only way to make a big project of any kind work. Usually, any new technology or process that is visibly promoted by only the IT department is difficult to be universally accepted across an organization.

People need to be nurtured, educated, and inspired to use the technology so they see the value.

Another challenge for the IT department is to understand the actual request from the business. Often, there is a request for a team site for a business function, when in reality a document library was all that was required.

 

SharePoint technology

One of the really nice things about the SharePoint technology is that the specifications do not all necessarily have to be required at the beginning of an initiative. Functionality can be added after the release, and even by the users themselves. This is different from traditional IT projects where requirement gathering is documented, but a true understanding by users of the process is incomplete.

With SharePoint deployments there is the ability to engage users with proof of concepts very early on in the process. This allows the users to become more confident with their own SharePoint skill-set and take ownership of projects.

By users taking ownership and personalizing content and design, the endless list of small requirements can be done by the users themselves.

We recommend performing follow-up coaching sessions, and having the more vocal people speak out about the small alterations they have made to a deployment to educate the other team members.

 

Order your copy of Microsoft SharePoint 2010 Business Performance Enhancement – Taking the basics to the Business with No-Coding Solutions for SharePoint 2010 End Users today, and save 20% by using the promo code P. Ward (valid through the end of April 2011).