1. Confront Reality

Understanding where your company is in its maturity of SharePoint can better help you understand the next steps, as well as the challenges your corporate culture will face. Confronting reality is something that can be done at any time during a deployment. Often, it isn’t a greenfield deployment; there is already something in place, and that current solution may or may not be working. Why?

An assessment of your Intranet, collaborative platforms, file sharing platforms and usage scenarios will help you understand where to begin. It’s time to wake up and see that there are better ways to do things, and you may need resources to accomplish this.

You will find that making any changes will affect the balance of empowerment for the business, and give up some control from IT. It may feel unnatural at first. Doing this with the out-of-the-box deployment often is where companies start with SharePoint. They find that giving the business site collections to create projects, workspaces and team sites makes them very happy.

The balance can get out of control when the business is left with a default install. The default install has faults. There are no quotas enabled, and all data goes into one content database that continues to grow until it fills the drive. Auditing is off, versions aren’t enabled and chaos can reign quite easily without some forethought about the answers to these questions. The newbie mistake is to decide to figure out many of these things later. Later comes too late, when the environment is down or, worse, never backed up. Again, it’s something that by default isn’t automatically configured. Backing up the drives isn’t good enough. The data is in databases, and the binaries and development assets are on the disks, while the configuration is spread across the system. This might seem obvious to those running the system for awhile, but unfortunately it is a common mistake.

2. Create a Governance Plan

Before we can create a governance plan, we need to understand what governance is. I’m a fan of the definition from the Burton Group: “Governance uses people, process, technology, and policies to define a service, resolve ambiguity, and mitigate conflict within an organization.” The governance plan does just that—it defines the service, roles, team, technology and the policies.

People – Think virtual teams. The roles for a SharePoint environment can be as simple as a Portal Admin and an IT Infrastructure Admin. This provides some level of delegation and empowerment for the business, while maintaining patch levels and optimizing administrative tasks by someone who has the appropriate skill set. The larger the enterprise, the more these tasks become divided into roles stemming from a development lifecycle. It may be an SDLC (Software Development Lifecycle) or an Operations framework like MOF 4.0, where a framework is laid out with staged deployment involving different roles— the Dev team, the Test team, the Ops team, the Engineering team and the Service Manager, along with the Project Management Office. A support desk, along with communication functions and release management, can provide these teams with simple to highly-structured support, based on the requirements and complexity of the application and organization.

Process – The process for this service most often determines how the site or site collections live and die—it’s about the lifecycle management of the unit of provisioning. Exchange supports mailboxes and SharePoint supports Site Collection as its most scalable unit, but, in some cases, the unit of provisioning actually is a site. The process is the system set up to support the provisioning process. Imagine it as a workflow from creation all the way through to the archive and deletion process. Who can create sites? Who approves them? How are they managed?

A great way to achieve stability and address cultural issues is to include Site Admin training as a prerequisite to owning a site or site collection. In the training session, you could include HR policies on security and risk associated with your information policies. Your SharePoint community will be happy they were told the rules ahead of time.

Technology – The technology is the platform. It’s also what I like to call the “Buzzwords.” In nearly every SharePoint marketing deck, you will find the SharePoint pie. This pie consists of buzzwords from Portals, web content management, records management, BI and others. The SharePoint Platform is plastic, so mold it to support the service you envision.

Policies – Customization policies will keep you out of trouble. Security policies are right up there, as well. You need to establish the rules of the game and learn how to enforce them. A customization policy might define who can use SharePoint designer, or, it might determine how you support custom development assets and how they are evaluated even before reaching your dev boxes.

Service – The service is what you’re building. It’s what helps you be consistent and achieve scale. The service definition will give you, in black and white, what everyone agreed that you would build and support.

3. Get an Exec Sponsor

Without a stakeholder who has a budget, your deployment is doomed from the start. You need the visibility and support of the business. At Microsoft, they are called shadow apps. The key stakeholder might be the director of HR, Marketing or Communications. It isn’t always the CEO, or even a C-level executive. While it is great to be on their radar—and have the awesome visibility that goes with a spot on the radar screen, the day-to-day details are rarely discussed in the board room. The CIO’s vision for information management and the ability to support the growth of the business is critical. The platform the CMO chooses to push the marketing message can either hurt or embrace your service. Vision is a key word.

 4. Create the Dream Team

You don’t need to hire an army. You can find people with the right skill sets right in your corporation. It also is extremely helpful to have the guidance of someone who has performed previous SharePoint deployments. Microsoft’s SharePoint Deployment Planning Services provide the option of working with a skilled partner to get your service scoped. I can’t over-emphasize the importance of training by a skilled SharePoint instructor, especially one who is a SharePoint MVP. There are many out there who have built instruction based on their deployment experience. While Microsoft’s Official curriculum training may help you learn how to install, the insight of the instructor will provide the core lessons.

5. Build Services not Stuff

While a lot of Microsoft applications come with a simple wizard-based install, you would never just install Active Directory or Exchange and then hand over the keys to someone. It’s the same with SharePoint—you need to design a service around it. You need to decide what you’re providing and how you’re providing it. This service-based approach will help you to scale, and set the expectations of the business. It’s an approach that is mandatory to achieve the core requirements of the business and IT. Balance is essential to success, and the only way to achieve it is to scope the service and roll it out in a phased approach as the service delivery team can handle the rate of change.

6. Define Clear Policies and Standards

The assembly line was built on the idea of standardization. “You can have any color car you want, as long as it’s black,” Henry Ford said. While automakers have come a long way since then, standardization is what allowed them to support high demands and keep their costs low. In IT, the commodity service of SharePoint needs to be very similar. The service provides a consistent quota, template, and provisioning and de-provisioning processes. The business users can expect a consistent service, know what they’re getting and adjust their needs around it. You may find off the shelf tools such as the Quest Site Administrator tool (http://www.quest.com/sharepoint) or the codeplex sp configurator tool (http://www.codeplex.com/spconfigurator) can help you set and keep your auditing policy settings consistent. Out of the box there are challenges for turning on settings across large numbers of sites to capture who changed or deleted a document, settings not enabled by default.

This is not to say that a custom application-based service can’t be successful. It can be very successful when similar principals provided as policies are adhered to. Customization policies, for example, may require that all code introduced into the environment be rolled up in a solution package. It may require that third party software have support and maintenance agreements to avoid situations where problematic code has no developer. Within an organization, it may require all code introduced into the SharePoint environment to be supported not by an individual, but by a development team associated with a division or business unit. You don’t want to be stuck supporting an application where the key and only developer just left the company.

7. Invest in a Scalable Information Architecture

The capacity boundaries of lists, site collections, sites and so on may quickly be passed on as things that are only of concern to IT. Think again. Unfortunately, the reality of the scalability of lists is a somewhat common issue. This issue is ultimately escalated to IT, but it could have been prevented by a bit of end user training in the use of folders and custom views.

Web Applications – These are good for memory isolation and department level applications in a multi-tenant environment. You do want to limit the use of these objects as they require a lot of memory.

Site Collections – The most scalable object in SharePoint is the site collection. It is the most common unit in a collaboration environment, and is automatically enforced with my sites. This is the rollup of ownership, permissions and galleries, yet is the smallest unit of quota.

Sites – While site collections obviously are collections of sites, they can contain more diverse sites. They are useful for breaking up content and often are used in delegation of an internet site or Intranet portal. They can be useful for separating one project from another as they each have a separate home page with web parts and lists.

Discovery is an important part of any Intranet SharePoint deployment. Navigation, site directories and cross-site navigation can help make content more consumable. Users definitely will be happier when they can actually find things.

8.  Don’t forget Change Management

Running SharePoint on a single box is a challenge. The biggest mistake a newbie can make is to put all the eggs in that one basket and then forget about it. What happens when someone needs a webpart? A simple rollout can take down the environment due to a memory leak. Even a service pack can put the environment at risk. You must have an environment where these issues can be fleshed out. The more complex the environment, the more like environments are required: development teams need a dev environment and IT teams need a preproduction evaluation environment. What about restores? What about test? With virtual environments, these can quickly be built up and torn down to perform validation, or they might exist as long as work is being done on the development projects. The key here is not only to stage the deployment effect of a software lifecycle, but also to manage change and mitigate risk. IT is working on evaluating Service Pack 2 and the dev team is working on the latest solution. You don’t want them both to go out at the same time, because any issue will result in a finger-pointing and yelling match. No one wins. Stability comes from managing risk.

Change control dictates that changes are rolled out and validated at each stage, and production changes happen during a maintenance window where usage is brought to a minimum and communication is clear about what’s going on. IT is happier, Development is happier and the business reaps the benefits of high availability. The change management process can involve a change management board or a release manager, or, it can be as simple as a SharePoint list tracking changes rolled out and validated by the infrastructure. A note of caution: make sure your key steps to recover a deployment, along with the change management list with the package’s deployment, are not found only in the deployment you’re trying to recover. Various straightforward ways exist to accomplish this beyond a client with offline capabilities.

For example, a development environment is set up, code is introduced by the business units and the policies are established. Tthe code is wrapped in solution packages (.WSP), tested with standard unit tests, including one for memory leaks using SPDisposeCheck. Code introduced goes through a staged deployment process and is stored in TFS with source control and a change process. All this requires more resources, and that’s where the tradeoffs exist. Are you building high value applications on SharePoint or are you designing an out-of-the-box service with the concept of a commodity or utility in mind. The commodity out-of –he-box design may not include just the out-of-the-box code, but also may have features benefitting everyone who went through full scale rigorous performance testing. It’s about tradeoffs.

9.  Adoption is What Counts

You could create the most fabulous, rock solid SharePoint deployment but, if no one uses it, your efforts were wasted. In the section above on confronting reality, we mentioned that you need to understand where the business is, and what other platforms are available. You can’t force feed the business, but you can lead it to the solution through training. They likely will be very happy to be involved in the master page acceptance and will provide feedback on the navigation. While they may not understand the challenges of deciding whether the service should provide sites or site collections, they may be able to tell you which of their requirements can be impacted by that decision.

Adoption doesn’t end after deployment. Care and feeding are required throughout the lifecycle of the environment. SharePoint deployments don’t need to be stagnant. They can evolve along with the skills of the deployment team.

10. Keep it Simple

Overly complex and over-structured deployments can bring a deployment to a halt. In all of this guidance, it may sound like a ton of overhead is required. In reality, it’s more about having insight and using that insight to provide flexibility, and providing clear boundaries so your users can achieve scale and build the solutions they are so interested in using.

SharePoint is a lights-on experience; not everything needs to be enabled from day one. All of the functionality from forms allows workflows, BI dashboards and Excel services to wait as users figure out how to create and manage a list. They can learn how search works, and emphasis can be placed on making it work. Relevance is something that easily can be managed with some focus on what users are looking for, as well as paying attention to keywords and placement on the portal in relation to what they need.

As a CFO and senior business executive would life be better if all your commercial information, everything from files and documents to LOB systems, were all accountable and controllable from one platform or portal?

Imagine definitive decision support, comprehensive implementable governance, anything and everything at your finger tips via a dashboard and ‘best bet’ query.

In recent times, and with its ubiquitous commercial acceptance showing no sign of abating, SharePoint has been moving to take this kind of ‘center stage’ in the information management universe.

But in many cases SharePoint is filling this role by default, due to its momentum within IT and other business areas, without a comprehensive assessment as to its suitability for this pivotal role.

Could SharePoint be a black hole for your business, drawing in information and content without providing an adequate foundation for information management?

Let’s look at the typical benefits SharePoint delivers then consider some of the strategic implications these benefits portend.

Typical SharePoint Benefits
There is no doubt that SharePoint delivers extensive business benefit in the information worker and general office productivity area:

• Document Libraries – Business content such as documents, spreadsheets, graphics, presentations, media files, even emails and their attachments, can be housed and ‘managed’ in SharePoint libraries easily accessible by anyone, anywhere, anytime, via intranet, Extranet or Internet

• Roles & Controls – Library controls, and permissions across SharePoint, enforce author, editor, publisher roles and structured responsibilities along with fail-safe versioning, garbage, archival repository and other content controls

• Search & Surfacing – Search promises that nothing will ever be ‘lost’ again. Anything in your Enterprise in SharePoint, and beyond, can be found or ‘surfaced’

• Security – Security is leveraged from your existing Active Directory investment or other authentication system integrating seamlessly with content roles and controls. Single sign-on can make any LOB system, such as financials, ERP or CRM, directly accessible or integrated with your portal

• Information Management – Metadata can be tailored to your business and assigned to assist with search, categorization, and information processing

• Customisation -SharePoint is extensible with features and functionality that can be exposed and customized, or created for example as Web Parts and seamlessly integrated

Implications
But what are the implications behind these SharePoint benefits and how do they impact your business?

Let’s consider three basic SharePoint issues that span the business technology ‘sophistication’ spectrum from: the basics of content library storage; to custom development; to business intelligence

SharePoint’s Storage Paradigm Shift
While the concept of computer storage might be considered somewhat boring and ‘something for the Techs’, it is important to note that SharePoint involves a massive paradigm shift in this area.

In the past, Fileshares have been the most common method of general storage. But their time has passed and it is now almost universally considered a good idea to have all your content in record management systems, document libraries and workspaces.

But where does all that content actually live once it is in SharePoint in a document library?

Fileshares in Windows, and folders in SharePoint, while functionally similar are very different entities from a storage perspective

Doesn’t SharePoint store content in its own folders and ‘fileshares’, the way it appears on screen?

No. SharePoint stores all its content in a Microsoft SQL Server database.

SQL Server is not a new technology and your business likely already has SQL Server running, but consider the implications of this change:

• Licensing Cost – SQL Server involves its own licensing costs both for the purchase of the software and CALS (client access licenses). This is in addition to the SharePoint costs. By contrast storing and sharing files in folders is essentially ‘free’

• Infrastructure & Performance – SQL Server is a sophisticated platform that necessitates specialised infrastructure including servers, storage devices, and staff, in addition to SharePoint. The cost for the use of this infrastructure may be spread over other applications that are already using SQL, but if your business is looking at putting all its content into SharePoint+SQL then this infrastructure will have to scale both in terms of its size and mission critical support.

• If you require the SharePoint content to be available on an operational basis special attention will need to be given to SQL I/O performance along with addressing problematic performance issues with SharePoint itself, such as the performance penalty when returning more than 2,000 records in a list. Performance limitations might make certain types of enterprise-wide solutions untenable. Capacity planning is essential. Here is a useful link on SharePoint capacity planning.

• Migration – While there are tools that allow the migration of content into SharePoint from earlier versions of SharePoint and other information sources such as Lotus Notes, this is typically not an easy or ‘lossless’ exercise. Looking to the future, will there be tools to migrate your content out of SharePoint+SQL if needed? What about all the feature rich content attributes you might build into your SharePoint information management solution – will you be able to take them with you?

Custom Development Dilemma
SharePoint is a great OOTB, ‘out of the box’, productivity tool. But OOTB functionality is never enough! Customization is always demanded to support specific business processes and applications.

However, while SharePoint has a wealth of inbuilt functionality waiting to be tapped, commensurate with the richness of features there is a high degree of complexity that is largely underrated. Development in SharePoint brings its own challenges:

• Business Coverage- SharePoint covers many different business areas including content management, business intelligence, document and records management, workflow, portals, etc. Ideal SharePoint solutions should leverage as much of the existing platform functionality as possible without reinventing the wheel.

• For best results a developer should have a holistic functional understanding of SharePoint across all its business applications

• Complex Technology – SharePoint is a complex technology in its own right that spans from web front ends to SQL Server database processes. The right approach, expertise and understanding are required to fully leverage it. Good .Net developers are not automatically good SharePoint developers. Experience, lots of experience, is needed to bring about holistic development understanding. Experience also assists in coping with SharePoint’s many ‘undocumented features’.

• Because many SharePoint options can be configured without development, and initial development appears easy, overconfidence is often engendered in in-house developers, and overly ambitious development projects can be undertaken with disastrous results

• Duplicitous Paths -With Microsoft technologies there are often several development paths to achieve a solution and SharePoint is no exception. But despite the seeming logical and extensible nature of a path, a satisfactory result may not be achieved. As this stage of SharePoint’s maturity, many likely development paths often come to a dead-end through no fault of the logic of the developer or their approach, but because of a SharePoint bug, anomaly or undocumented feature.

• SharePoint is only early into SPK release lifecycle and the many CUs (cumulative updates) are a must

• Development Environment – a suitable development environment is required which ideally should replicate Production conditions which may involve topologies of web farms, index servers and SQL clusters, Active Directory and Exchange servers. Few environments provide that level of development platform support, although virtualization is closing the gap. This means that SharePoint development projects do not always travel well to the Production environment, even with Solutions and Packages, delivering unforeseen results

SharePoint Production environment topologies can be complex, and are not often replicated in development, with the result that SharePoint solutions do not always travel well when deployed

Metadata Intelligence
The leveraging of metadata is one of the most underrated areas in SharePoint yet it is invaluable to your business and information management strategy.

For example the implementation of an information management system, incorporating governance and compliance built on SharePoint’s metadata and workflows functionalality, is a logical application for the platform.

Metadata support allows you to attach keywords that can be used to provide meaning about the content that is loaded, assisting in categorization, search and aggregation. It is also a key to ensuring the alignment of content and business processes to your governance, compliance and information management plans, by being linked back to your associated business goals and objectives.

SharePoint OOTB can leverage the Properties page in all Office documents where metadata for author, title, subject, status, keywords, etc., can be entered. In addition SharePoint has a whole metadata infrastructure that allows you to create, customize and manage your own metadata infrastructure.

This SharePoint metadata, called content types, have particular value in that they can also be used to trigger actions and workflows. For example when a document is loaded into a library, special processes can be triggered based on its metadata.

Let’s consider some of the implications of even a basic implementation of SharePoint’s metadata on a large scale. (For ease of discussion I will use the term metadata rather than content type.)

Note the message ‘You MUST fill out any required properties’

• Mandated Metadata – It seems like a good idea to allocate metadata to all your SharePoint content because of the associated benefits. So the next obvious step is to mandate metadata i.e. ensure every piece of content that is loaded into SharePoint must be assigned relevant metadata.

• To add metadata to a single document may only take a minute but scale that out across your business to every staff member and to every piece of content, and a sizeable amount of time will be taken up assigning metadata that will erode overall business productivity

• Dirty Metadata – One way to overcome this ‘mandated metadata productivity hit’ is to make the metadata faster and more intuitive to allocate. This can be done by providing metadata in the form of dynamic lists, as opposed to free text fields.

• But even when presented with an easy or ‘smart’ pick list, staff may not know what metadata value to assign, or be confronted with too many choices. For example combinations of departments, business units, and projects could produce an overwhelming list of options.

• ‘Time poor’ information workers don’t want to stop their task to find out what metadata should be allocated or go through the process to create a new category. This can lead to erroneous values being assigned just to expedite content loading.

• In some cases there may be purposeful erroneous metadata provided, to obscure business activities such as fraud

• Legacy Metadata – Most discussions of SharePoint benefits focus on ‘greenfields’ SharePoint implementations but all businesses have legacy fileshares, content and systems that can be essential to migrate into SharePoint.

• While it is possible to programmatically assign metadata during migration, in reality it is not worthwhile to do so on any scale unless a metadata or similar policy has previously been in place.

• Consider trying to allocate even simple metadata such as author, document title and version if these are not already associated with the content: fileshare locations by nature provide multi-author storage so authors are not differentiated from PAs, etc.; duplicates and drafts with the same or entirely different titles are common confounding categorization and titling; latest date may not reflect a file master version. These are just some of the issues.

This much used image helps demonstrate the typical nature of the information and content in most businesses fileshares. Determining, on any scale, the author, title, keywords of this information is in reality an impossible task.Thus much legacy information comes into SharePoint sans the metadata that could be vital to an understanding of the material, and assist with the information management of the business

• Metadata Meaning -Metadata seeks to give meaning to content beyond that given by a file name.

• How many metadata properties might be needed to adequately indicate the meaning of a document that spans many diverse areas and topics? Free text metadata would allow more comprehensive explanation but we are back to the ‘productivity hit’ issue of the time taken to enter all the metadata.

• Meaning may also differ from different perspectives. How would the allocation of ‘definitive meaning’ to files and content be achieved? How would different perspectives and synonyms be handled where different metadata words and terms are used for similar concepts?

• Consider the issue of trying to assign comprehensive metadata to all the images, video, audio and VoIP content in your business. How much resource would be required? Would the metadata be accurate and definitive using any current methods?

• In terms of scale, how would the process of allocating metadata relating to every email be handled?

• What about metadata relationships between content, such as between documents and documents, images, emails, projects, departments, people, roles? Would this type of meaning and understanding gained provide any useful insight into your business and be of value?

These are issues that may currently seem most poignant to the legal profession and e-Discovery but are increasing in import for all businesses.

Metadata that provides meaning as described above, including that for unstructured content, can provide valuable insight into business operations providing a basis for real business intelligence, way beyond that of the traditional BI with just numbers and charts in a spreadsheet.

Conclusion
SharePoint is a good information management and general office productivity platform. However it has its issues that are best to be aware of and managed, rather than just ‘let loose’ in your business, preventing it from becoming a ‘black hole’.

In the context of the issues discussed above:

The Good is that SharePoint will, in line with the Pareto principle, OOTB meet roughly 80% of your general information management needs and in the process provide a stable scalable platform.

Good also is that assistance with SharePoint development, both in terms of available tools and developer experience, is increasing at a rapid rate. At the time of writing this article, a quick search of www.CodePlex.com returned nearly 700 ‘open source’ projects providing explanation and assistance on SharePoint development. Countless blog articles by SharePoint gurus likewise provide commentary on numerous SharePoint solutions.

The Bad is that if you want SharePoint, then SQL Server and its associated overheads are unavoidable.

Bad also is that with regard to going beyond the metadata basics, there is no solution available within SharePoint that address the issues discussed. However this is not so bad as it seems as there is no solution available within any of the current generation of similar platforms.

How to get more meaning from business information and unstructured content is the next major conundrum facing business managers today. However I believe this type of metadata support and analysis is one of the most exciting challenges, and will be the basis for the next level of real business intelligence and competitive business advantage.

Next generation tools, providing definitive meaning to structured and unstructured information and a full understanding of information relationships, are just starting to enter the mainstream and gain more attention. These tools can work with SharePoint as well as hundreds of other information sources and hold the promise of providing an incredibly comprehensive understanding and powerful information management tool for your business.

I will be looking at this next-generation solution in more detail shortly.

It’s been a long while since I wrote the last part and had to find myself reading through all three parts again to realize how much my SharePoint knowledge has matured since then. This is something familiar to a lot of people in the SharePoint community that are evolving at a rate of knots with the Platform.

You may already be aware that I have started a SharePoint Development Wiki that I am encouraging the entire community to contribute to. You can anonymously add comments to any wiki page content or can sign up for free and instantly create/edit new wiki pages. I will reference various wiki pages in this article and encourage you to add comments or content if you have things you’d like to contribute.

The ‘Leveraging Levels’

This part will try and identify the main levels of leveraging the SharePoint Platform. As discussed in Part 3, there are plenty of different SharePoint People/Roles out there which are broken down into how you interface with SharePoint:

· SharePoint Site Web User Interface

· SharePoint Designer Interface

· InfoPath Designer Interface

· Visual Studio Interface

· SharePoint Central Admin User Interface

· STSADM Interface

· PowerShell Interface (direct to Object Model)

As I highlighted in Part 2, there are plenty of “quick wins”, medium term and long term solutions that can Leverage the SharePoint Platform. You may notice that the “quick wins” can all be implemented using the Web Interface, albeit they are made easier by SharePoint Designer and STSADM in some circumstances (mainly for simplified/wizard development interface and automated deployment respectively).
One thing to point out is although it might make deployment more manageable, it does require significantly more skills and more importantly more liberal access to servers.

Limitations of the ‘Leveraging Levels’

I came across a great quote on Twitter the other day which stated that “he spent all his time coding around the limitations of the SharePoint Platform”. I follow the same train of thought as many others on this one and that is that SharePoint is a Platform that is there to be leveraged. It is the building blocks to create solutions and it is not meant to provide full enterprise solutions out of the box on installation. I think this is where a lot of Organisations perceptions of SharePoint are incorrect, as Organisations do not realise the effort that is required to get a full blown solution operational in SharePoint. Organisations overestimate the Platform out of the box functionality and underestimate its complexities and do not provide the correct level of training to the administrators, developers, power users and end users.

On the SharePointDevWiki.com there is a wiki page that outlines the different Levels that you can Leverage the SharePoint Platform and highlights what can be done and can’t be done. What this highlights is that there is significantly more “leveraging” available when you start getting into Solution Packages (.wsp’s) and the Object Model. Please keep in mind that this is only available in the Visual Studio and PowerShell interface (or with Gary LaPointe’s STSADM extensions and other 3^rd Party Products).

When deciding on which ‘Leveraging Level’ you choose, please take into account the limitations – as this will lead to dead ends in your project where you simply can’t push the Solution any further without changing paths and using another ‘Leveraging Level’. Sometimes dead ends can be mitigated by hacking away at the ‘edges of the Earth’ around the ‘Leveraging Level’ you have chosen for the project, but be aware of the risks of these hacks with regards to upgradeability of the Platform. Another useful wiki page is the Comparisons of Implementation Approaches which highlights the pros and cons of using each ‘Leveraging Level’.

Source: SharePointDevWiki.com – SharePoint Implementation Approach Comparison Chart

SharePoint Development vs SharePoint Customisation

Another interesting area that has been discussed recently is related to the ‘Leveraging Levels’ which dictates what the difference is between Development and Customisation. Mark Miller put it well by saying anything that can be done without touching the SharePoint server, for instance, not modifying the 12 hive, inetpub or GAC is a customization. EndUserSharePoint.com focuses on this approach in their articles.

A lot of organizations do not want to run the risk of going further than customization due to the complexities of configuration management. Be aware of the limitations of going down this route. Another common reasons to do it is because of skill sets, when Organisations bring in external expertise to implement a solution, they often want to take on the support internally. This will obviously mean sticking to the skill set of the internal staff which has its limitations also. This is covered in more detail on the Defining SharePoint Development wiki page.

The People and the ‘Leveraging Levels’

As discussed in Part 3, I have found that the People tend to grow with the layers:

From this table you can see that the skills required for each Person outlined in Part 3 varies significantly. This is just one way of slicing through the implementation approaches and its complexities, so please don’t underestimate the intricacies of the Platform.

The ‘Leveraging Levels’ in more detail

SharePoint Site Web User Interface

Requirements

· Local Access to SharePoint Site via Web Browser

Skills Required

· Understanding of SharePoint Site Collection Architecture

Limitations

· Manual stepsrequired, so in a scenario where you want to add a web part to 50 internal Site home pages, the user is going to have to repeat the steps 50 times, once for each Site within an instance of a Site Collection.

Examples of use

· Creating Sites within an instance of a Site Collection

· Adding Web Parts to pages within a Site that is part of an instance of a Site Collection

· Creating List Templates, Content Types, Site Columns in an instance of a Site Collection

SharePoint Designer Interface

Requirements

· SharePoint Designer Client installed locally

· Local Access to SharePoint Site via Web Browser

Skills Required

· Understanding of SharePoint Site Collection Architecture

· CSS, XHTML, ASP.NET (Page Layouts, Master Pages)

Benefits

· The User Interface is a lot more powerful and easier to operate than the Web User Interface and more options exposed.

Limitations

· Manual steps required, so in a scenario where you want to add a workflow to a List within 50 Sites, the user is going to have to repeat the steps 50 times, once for each List within a Site within an instance of a Site Collection.

Examples of use

· Creating a new Page Layout and Master Page for an instance of a Site Collection

· Creating a Basic Workflow on an instance of a List within a Site that is part of an instance of a Site Collection

InfoPath Designer Interface

Requirements

· InfoPath client installed locally

· Local Access to SharePoint Site via Web Browser

Skills Required

· InfoPath development

· VB Script experience

Benefits

· Lots of functionality that is typically required for Business Forms and extremely fast to prototype forms rather than traditionally writing ASP.NET forms.

Limitations

· Often the forms created require extra functionality that is not available without heavily working around the features of InfoPath.

· Manual steps required, so in a scenario where you want to add the Travel expense form in a List to each of the 30 Department sites, you will need repeat the steps to create the List and deploy the InfoPath form for each Site within an instance of a Site Collection.

Examples of use

· Creating Business Forms e.g. ‘Leave Request Form’

Visual Studio Interface

Requirements

· Requires access to SharePoint Server to install Visual Studio on directly (recommend a Development Virtual Machine)

· Requires WSS SDK and MOSS SDK

· Remote Access to SharePoint Server required (for deployment)

Skills Required

· C#/VB.NET and XML experience

· Understanding of the SharePoint Object Model

· Understanding of the SharePoint Solution Package API

· Optional: CAML, XSLT, CSS, XHTML, Web Services

Benefits

· Repeatability and automation

· Self documenting automated scripts and versions of these scripts. Especially useful in a Solutions Integrator where they may repeat the same steps at each client site.

Limitations

· To do what you can manually do in the Web UI or SharePoint Designer often takes a lot longer to construct in a Solution Package within Visual Studio.

Examples of use

· Advanced Workflow

· Creating Feature Receivers to provisioning elements e.g. in a Site

· Creating Custom Actions to modify user interface of a Site

· Creating List Templates, Content Types, Site Columns programmatically

SharePoint Central Admin User Interface

Requirements

· Local Access to Central Admin Interface via Web Browser

Skills Required

· Understanding of SharePoint Architecture and Topology

· Experience with SQL, Active Directory, Networking , DNS, Firewalls

Examples of use

· Configuring SharePoint Farm

· Configuring Shared Service Providers for Enterprise Search, My Sites, BDC, Excel Services

STSADM Interface

Requirements

· Remote Access to SharePoint Server required

Skills Required

· Same as ‘SharePoint Central Admin User Interface’

· Experience with command prompt and .bat files

· Understanding of STSADM commands available

Benefits

· Repeatability and automation

· Self documenting automated scripts and versions of these scripts. Especially useful in a Solutions Integrator where they may repeat the same steps at each client site.

Examples of use

· Configuring SharePoint Farm

· Configuring Shared Service Providers for Enterprise Search, My Sites, BDC, Excel Services

PowerShell Interface (direct to Object Model)

Requirements

· Remote Access to SharePoint Server required

· PowerShell installed on Server (included in Windows Server 2008)

Skills Required

· Experience with PowerShell scripting

· Understanding of SharePoint Object Model

Benefits

· Repeatability and automation

· Self documenting automated scripts and versions of these scripts. Especially useful in a Solutions Integrator where they may repeat the same steps at each client site.

Examples of use

· Programmatically adding Web Parts to Pages in a Pages Library

· Programmatically adding Files to a Document Library from a File Store Directory with Meta Data into the Columns of the List Item

You can see from the limitations that are listed that it highlights the issues of constructing complexed Sites with forms, lists and workflows as one scenario. It immediately highlights the benefits of using Solution Packages within Visual Studio for repeatability and automation of construction of these sites. One thing to take into consideration which comes up immediately with Organisations with more than one environment (e.g. Dev, Test, Pre-Prod, Prod) is the time it takes to do things manually over having these things automated and repeatable.

In Summary

Hopefully you’ll have an idea of the different leveraging levels in SharePoint Platform now. Next month I will place this content on the wiki page to allow others to contribute to the requirements, skills and examples as I’m sure there are many more. This is just a starting block.

Records created, managed and stored in SharePoint constitute electronic communications that fall under the same compliance rules requiring the retention and availability of communications records organizations must apply to email.  There is not only limited space for storing such unstructured content but there’s also more than a little confusion about exactly what should be stored and for how long. To make matters even more confusing, those same SharePoint records cannot simply be dumped onto backup tapes and sent to a storage facility down the road where they remain untouched to gather dust. Specific records must also be accessible at a moment’s notice in the event of a lawsuit or regulatory investigation.

SharePoint presents IT administrators with the same management and storage issues as email, as well as some new ones.  SharePoint versioning is a useful tool, but it stores a completely new item for each new version created.  So if you create a PowerPoint presentation and a colleague makes just one change to one slide, SharePoint saves that change as an entirely new slide deck.  You can imagine how quickly SharePoint can consume expensive primary storage space.

The number of SharePoint sites within an organization can grow very quickly as sites are often created for even short-term projects.   These sites are usually temporary and are active only for the life of the specific project.

Benefits of Archiving

Implementing an archiving system for SharePoint records enables IT to optimize its storage resources by moving older records off the SharePoint server and expensive primary storage facilities to less expensive options after a project reaches completion or when a document is no longer being modified on a regular basis  SharePoint documents can be archived to preserve storage space, utilizing features such as compression and single-instance-store (SIS) to further reduce costs.   Moving from primary to secondary storage also has the benefit of accelerating SharePoint maintenance such as scanning the database for viruses or backups.

Single instance store eliminates the cost of storing multiple copies of the same document.  For example, if the same document exists in multiple SharePoint document libraries, just one copy will be stored in the archive.  If that same document also exists in the File System archive or email only one copy will be stored.

When an item is archived, it is first compressed and then metadata is added to it.  As a general rule, the item is compressed to half its original size, and the metadata comprises approximately five KB.  When an item is shared, only the metadata is added.  To estimate  the storage savings compression creates, halve the total size of items to be archived, divide by the average number of sharers or collaborators (if any) and add five KB multiplied by the total number of items. The compression ratio may vary considerably, and you must factor in the growth in the number and size of documents.  A more conservative method of estimating storage is to assume that space used by archiving equals the space used by SharePoint in storing items.

Additionally, the SharePoint administrator can set policies to further reduce the number of files stored within SharePoint, such as establishing a rule to automatically delete mp3 or video files from a SharePoint site collection..  Documents can also can be automatically deleted as they become outdated by creating a rule at the site or subsite level to archive and remove documents from SharePoint based on the last modified date (while maintaining an archived copy).

As previously mentioned, SharePoint versioning is a useful tool to preserver every modification to a given document however each change is stored as a separate document.  Archiving solutions can ease this storage burden by providing a way to archive the older versions to cheaper storage while maintaining the current version in SharePoint for easy modification.  Versions can still be accessed by the user via shortcuts or stubs but the actual file will reside within the archive not within SharePoint freeing up valuable space.

End-user Access to Archived items

Shortcuts or “Stubs” are essential in maintaining the end-user experience once items have been archived and removed from SharePoint.  A shortcut or stub links to the original document in the archive and provides seamless access for the end user.  A good archiving solution will also maintain the original icon or a variation of the original icon to minimize the change to the user experience.

End-user search is also essential to provide an easy way to find items in the archive (especially if shortcuts are not in use).  End-users must be able to search on both the metadata and content within the document and should be able to restore items back to SharePoint if they wish to edit the document.

Improving Search and Recovery

An archiving system’s search and retrieval functionalities make finding and recovering specific records for business or discovery purposes much faster, more accurate and far less costly than manually searching through piles of backup tapes.  Backup tapes were not designed to do what archives do. Backups offer safeguards against unexpected data loss and application errors, while archiving is the process of systematically saving copies of unstructured files to reduce primary storage, better management retention and enable the discovery of information on a per item basis.  Backups will always be an important part of an organization’s data protection and disaster recovery strategy, but they are less than efficient when used for archiving purposes. Nevertheless, if tapes are the only source of SharePoint, email, IM and other electronic communications backups, then they are fair game should a lawsuit demand their discovery. And simply saying they’re inaccessible will not hold up in court.

A proactive archiving system reduces the costs associated with the search and collection of electronic data by creating a centralized and indexed archive that can be searched on demand.  With archiving in place, organizations can save on discovery costs by eliminating the fire drills and time required to respond to requests, decreasing the resources needed to carry out legal holds and significantly reducing the cost of manual collection, de-duplication, imaging, password cracking and tape restores.

To summarize, there are multiple benefits to expanding your existing email archive to incorporate SharePoint records, including:

• automating the archiving of older business-critical data on Microsoft SharePoint Portal Server to more cost-effective online stores
• moving documents from SharePoint workspaces to provide maximum storage benefit, including entire workspaces when a project ends
• maximizing online knowledge store and increases information sharing
• enabling SharePoint to remain a constant size and does not suffer from storage “bloat” to facilitate rapid disaster recovery and optimal backup processing
• all data can be stored in one location

Implementing a software-based archiving solution is one way to keep storage costs from spiraling upwards without limiting how employees use SharePoint.  Newer, more frequently accessed content is retained within SharePoint with older, less frequently accessed content being moved to the archive while still remaining available to the end user. This keeps storage growth focused, enables SharePoint Portal Server scalability and keeps backup/restore windows under control without impacting the end user.

The second part of this three-part series will focus on archiving for SharePoint to ensure compliance with laws and regulations requiring the retention and availability of electronic communications records and to facilitate the e-discovery process.  Part three will examine how extending your archiving system to include SharePoint will significantly improve the end-user’s experience with SharePoint.

This the third post of a six part series on Leveraging the SharePoint Platform. In the last post I explained some of the great things that can be implemented. In this post I will introduce the Governance, the People and the Approach that needs to surround SharePoint.

I hope from reading the first two parts you are under no illusions on the scale of the SharePoint Platform. With this post I hope to point to some great resources out there both from Microsoft and the awesome SharePoint Community.

The Governance

Microsoft defines Governance as “the set of policies, roles, responsibilities, and processes that you establish in an enterprise to guide, direct, and control how the organization uses technologies to accomplish business goals.”.

You’ll notice from a lot of the references I use in the post are all 2008, the reason I point this out is because the latest version of SharePoint has been out since November 2006 and it has taken this long for Microoft to raise their game and provide assistance in this area. SharePoint could quite easily become the next SAP behemoth platform that people talk about and never witness being rolled out nto Production (apologies for any SAP lovers out there – I’m sure you say the same thing about SharePoint).

There seem to be a collection of sites dotted among the Microsoft network regarding SharePoint Governance:

• Code Plex
• SharePoint GearUp
• TechNet
• Office.Microsoft.Net
• and more from the entire Internet at diigo.com/user/jthake/

Microsoft have published a great SharePoint Governance Checklist Guide that offers a lot of information around the Platform. They also have provided a template Governance Plan that can be used at the initiation of the project.

There’s plenty of information in the links I’ve listed above and rather than me regurgitate it all here I’ll let you read these at your leisure.

The People

This is an area that is covered by the Plans and Checklists that Microsoft provide, but I don’t believe they are realistic. The problem I have had with most engagements I have been involved with or witnessed around me is that SharePoint is treated in isolation to the rest of the Technologies around it. To emphasise this point further, most environments I have been in even have a separate SQL Server instance just for SharePoint Databases rather than leveraging existing server infrastructure due to the uneasy nature of DBAs not knowing what SharePoint does because Microsoft state that you shouldn’t touch the Database Schema in ANY way.

With this isolation also becomes resource islands and the common pattern is that the person/role who installs SharePoint, also becomes the person who supports it and keeps it operational. Now in a perfect World, and in Microsoft Plans and Checklists, this would be divided up into separate resources and transitions would occur at various phases to make up a ‘Tactical Team’.

As I highlighted in my first part in this series, SharePoint spans multiple Tiers, so immediately, you can see there’s a lot of specialists skills required that span multiple Microsoft Technologies which alone have their own sophisticated exams and certifications. Various bloggers out there have tried to define this:

• Sharee English
• Becky Isserman
• Eric Harlan

(Please add more in the comments of this post)

All of these approaches are valid and some take it from the Roles and Responsibilities approach and others take it from the Technical Background. Sharee’s approach in my mind gives the breakdown I have seen naturally evolve in various SharePoint roll outs I’ve witnessed.

The biggest problem I’ve seen with the isolation and break down of personnel is that SharePoint always takes the blame, because although it is in isolation, there are some shared resources because it shares resources such as the underlying network, Exchange, ISA, Backup and Active Directory. Also, it just isn’t a full time role for each isolated tier such as SQL, ForeFront, SMTP and Windows Server.

What do I mean by “taking the blame”…so a User submits a support call to say the Company Intranet is running slowly  (typically they even know it’s SharePoint and say it’s SharePoint running slowly), this immediately points the blame at SharePoint. Looking at the tiers in the diagram you can see that potentially it might be the underlying architecture that is the issue. This will involve various experts getting involved and working as a team to resolve the issue. So many times I’ve had experts in particular areas going “everything is fine” to later find out that their area was the reason, because other experts have invested hours of time proving to the nth degree it isn’t their technology.

This ‘Tactical Team’ would also include Developers who as Microsoft put it:

“Technically talented people both willing and able to customize, personalize, and use SharePoint in a manner that fulfils the business opportunities as identified by the strategy team. This team is a loosely-knit community of developers with varying degrees of proficiency in software development. Members can range from highly skilled programmers to technically savvy end users in charge of personalizing departmental team sites. Skilled developers will handle large change requests, new features, and program management while ensuring adherence to standards.”

This did make me laugh and also made me feel very self important. I’m going to cut and paste this into my Profile for future reference! In all seriousness, I don’t believe that having ‘Developers’ is breaking this role up enough. As mentioned in my personal blog there is more than one way to skin a cat in SharePoint. Most of the approaches set SharePoint Developers apart from each other, these are (and not limited to):

• Web User Interface Developers – everything is done within the User Interface using OOTB Web Parts, JavaScript and done directly into production environment.
• Site Template Developers – slightly more advanced than above, involving packaging up Site Templates that can be reused.
• SharePoint Designer Developers – everything is done from with SharePoint Designer and migrated using Content Deployment API or similar tools.
• Visual Studio Developers – everything is a Solution with Features and Powershell automated build scripts

There’s been quite a bit of discussion on the best approach to actually ‘skinning the cat’ and Chris O’Brien has put some great points forward on the table.

I also believe that with these customisations there is some relevance to what was discussed in the last two posts around the SharePoint Capabilities. Most of the SharePoint MVPs have a specialist area within the Platform and may understand the other areas principles but never implemented them. With this in mind I think it is wise to understand the risks of putting a fresh SharePoint Developer onto their first Business Data Catalogue or Enterprise Search project. The current SharePoint certifications really don’t go deep enough into each capability and I’d like to see more specialisation in each of these with a core WSS Development exam.

Project Managers and Development Team Leaders should be aware of the strengths of their SharePoint Developers and try and identify the gaps in their team based on the requirements of the Organisation. This is further confused by the lack of resources in general in the SharePoint market and the push from recruitment firms and misleading CVs with unexperienced Developers. Joel Oleson makes some valid points about this issue which also has a HUGE discussion thread. Microsoft are also trying to combat this problem by encouraging existing ASP.NET developers to get onboard, this site is a great resource for people ramping up on SharePoint.

Basically, if you have one thing to take away from this section, please be aware of the multitudes of Developers out there and what type is going to suit your sized rollout whether bringing them in-house or outsourcing.

The Approach

Joel Oleson is one of the greatest SharePoint Community Members out there in my opinion and has some great posts around this whole area. Way back in October 2007 he announced the MOSS Deployment Plan sample.  Before you open it, bear in mind that this has the kitchen sink of tasks in there, but also keep your eyes open as this project plan has a total of 6452 hours split between 10 different resources. Again this break down doesn’t seem to align with the other Microsoft Plans and Checklists which isn’t going to make this very easy to use without some work.

Again, with all the references I’ve linked to, I just want to highlight two main core approaches to rolling out SharePoint into the Organisation. You have the traditional Waterfall model and the Agile model. The  Agile model attracts a more iterative approach, which works well with SharePoint due to the features you get out of the box and the speed in which you can get things up and running compared to a more traditional project where you are building everything from the ground up (I will discuss this more in the next part in this series).

As with any Requirements Gathering exercise, Business Users think they KNOW what they want from a system, but often need pushing to be able to explain EXACTLY what they WANT and also sometimes need to be RECOMMENDED what they NEED. Erik Swenson does a great job of highlighting some possible decisions that need to be made simply on the User Interface, before you even start getting into functionality requirements of a particular sub system.  My fellow Perth blogger Paul Culmsee also offers some advice with a great sense of humour and bitterness on this.

By following an iterative process, where you deliver in small chunks what a Business User asks for produces more responsive and early feedback. This allows the system to evolve as the Business User sees the interface working for them with their data. These prototypes can then be taken away to give them stability and shelf life to go into production.

This iterative approach does not lend itself well to the Waterfall method where there is a more formalised process up front of: gather requirements; documenting these into a Functional Design Document; then handing this to someone to produce a Detailed Design of how it will be implemented by the SharePoint Platform.
Traditionally Business Users don’t actually get to see or interact with anything until well after the Detailed Design is complete and the Implementation is in full swing. From here, it is likely that requirements change and scope creep occurs and then Functional and Detailed Design documents are immediately out of date.
A lot of SharePoint projects are very poorly documented due to the ease of which it is implemented and changed and this is something to highlight early on to the entire team…that Documentation is required! It is important to treat Releases as strict as you would a ASP.NET project for various reasons:

• Developers can look in source control and see what’s in Test/Production at any given time;
• A sense of achieving a goal if you have specific release dates;
• Formalised testing done as part of release process;
• If things are packaged and automated properly, SharePoint Admins can be handed the package to run in Test and then once approved run in Production…rather than Developers getting involved;
• Producing an As Built Document of the release, so that if a new team comes in to support it, they don’t have to go digging through code, environments and e-mails to work out what it is doing;
• All of which encourages a formal transition to support for the release.

I would recommend treating the installation of SharePoint as a completely separate project to any Solution you wish to deliver to the Organisation. The main reason for this is that it often involves very different resources than those involved with creating the Solutions on top of this Platform.

The Waterfall methodology does work well when it comes to the Infrastructure and Setup of the Environments. Many Integrators out there repeatedly do this for new customers who have purchased SharePoint licenses and have formalised approaches for this. I would strongly agree using an Integrator, rather than doing this internally as a self learning exercise, due to the complexities of the setup. It may look like a simple Wizard you run, but there are plenty of minor details that can cause all sorts of havoc later down the track. As mentioned before about the isolation, this is mainly due to the complexities of the platform which runs a risk of having more applications servers running on the environment leading to too many permutations when it comes to fixing a problem.

Scenario

At this point I’d like to raise a scenario which I’m sure most SharePoint Integrators reading this will nod their head repeatedly at.

So Microsoft have finally managed to persuade you to purchase the MOSS 2007 Standard/Enterprise license and the IT Manager has the media in his hands. The various technical whitepapers have been read and hardware has been purchased for a Database server and a Application server.

The Server Admin is sent off to install Windows Server on the two servers. The database server is then handed off to the DBA to install SQL. The thumbs up occurs and the SharePoint Admin installs MOSS on the Application server. The SharePoint Admin gives the thumbs up and they all get together to ensure that everything is being backed up.

A quick company logo is added to the header of the OOTB Blue SharePoint Theme and team sites are created for company divisions: Public Relations, Human Resources, IT and Finance. Division Managers are given full control of their Division Team Site and all members of the Division governed by Active Directory are given Contribute access.

Over the course of 3 months, various ad-hoc projects occur:

• Custom Web Parts have been added to particular Divisions;
• modifications are made to the look and feel using SharePoint Designer;
• InfoPath forms are suddenly replacing Word Documents for Time Sheets and Annual Leave forms with custom SharePoint Designer workflow;
• Columns have been added to certain Division Document Libraries;
• And the list of Business  Users with Power goes on…

6 months later, Users start complaining:

• Users can’t find documents in the search; and
• inconsistencies in how Document Libraries are set up make it hard for Users to know what to do;
• Users don’t know the most appropriate Document Library to use because the person who set them all up has left the organisation;
• Users want extra functionality out of the Web Parts/InfoPath Forms that have been installed, but the person who installed them has left;
• Also, Patches are released for SharePoint that need to be put on and fears around customisations that have been created being lost occur.

So a SharePoint Development Team is brought in-house or outsourced to follow up on these requirements. Immediately the team require a Development environment and the Project Manager wants a Test Environment for testing the updates and deployments before they go into Production. Issues are raised on the best ways to get Deployments from Development to Test to Production and also how to get Content from Production down to Test down to Development to give some realistic working data to test on (more on this coming on my blog).

18 months later, the CIO starts to raise concerns about how all this is being controlled and wants to start rationalising what people can and can’t do (from the list above) without going through a formalised process. This in my opinion is too little too late.

What I am trying to illustrate here is that if you put SharePoint into an Organisation you have to start Governing it straight away and take Roles and Responsibilities seriously. To the point where it is defined in Job Roles throughout the organisation and part of the Handover process when personnel move or leave the Organisation. The OOTB permissions that are giving to an “Owner” of the Division is far too much and should be giving to Owners at the IT Departments discretion.

In Conclusion

At this point, it is also worth mentioned that there is a programme that Microsoft have put together called the SharePoint Deployment Planning Services program. Basically Microsoft will pay its Partners to deliver a qualifying SharePoint deployment plan to their customers through on-site consulting sessions. The clients must have Software Assurance and the length of the session (one, three, five, ten or fifteen) depends on the agreement. So if you have Software Assurance please speak to your Microsoft representative and make the most of this opportunity.

Microsoft have also released this PDF on Risk and Health Assessment for MOSS Server by Microsoft as part of their Premium Support package. This again is probably to combat those environments that just aren’t set up correctly, for example hitting 100% CPU with 5 users or Maxing out on RAM.

The recent success of the Best Practices Conference in the US last month also pays testament on the awareness being raised within the Community. I have also noticed that plenty of training companies out there are also offering specific SharePoint Planning and Governance courses such as Ted Pattison , Set Focus, Mark Schneider (please add more in comments below).

The next part in the series will talk more in detail about the tools out there and how to leverage them.

Until next time,

Jeremy Thake

http://wss.made4the.net/ | http://www.readify.net/

No business is immune from this ‘SharePoint Paradox’. Understanding and avoiding it is an essential part of SharePoint success.

SharePoint Popularity

Did you know that SharePoint 2007 is Microsoft’s most popular product ever, having achieved the $1billion 100 million sales mark faster than any other product in Microsoft history? A position achieved with none of the marketing hype that accompanies the likes of Office or Windows!

The popularity of SharePoint is built on a number of characteristics, including:

• it has a wealth of easy-to-use, web-based collaboration tools and templates that are analogous to Outlook and so receive ready uptake, while providing much more functionality
• it is easily extensible and customizable to fit your business
• only limited IT involvement is needed
• it is a real 80-20 tool, almost 80% of common business tasks can be achieved OOTB (out of the box)
• it integrates seamlessly with Active Directory, and with a bit more effort to your LOB applications, providing immediate secure use enterprise-wide
• it can scale easily

SharePoint truly is a ‘wonder tool’ of the information age.

It can takes less than 30 minutes to install SharePoint, create a website for collaboration, and start enjoying the benefits of collaborative resources such as task lists, calendars, versioned document libraries,  workflows, CMS publishing.

Where’s The Problem?

So where’s the problem?

The paradox is that SharePoint ‘s inherent ease-of-use is its own worst enemy. Rapid, organic, unstructured SharePoint growth leads to business disaster.

This pic shows the APAC SharePoint conference with eight Microsoft team members on stage including Mike Fitzmaurice, Joel Oleson and Angus Logan. SharePoint while initially appearing easy and straight forward is a sophisticated and complex technology requiring a depth of expertise

Consider the following post-installation problem scenarios based of real life experience:

• § SharePoint websites can be setup by a non-IT user in 5 minutes without requiring any pre-qualification or adherence to business mission or information architecture. Hundreds of non-business-aligned, duplicate and redundant sites tend to proliferate. The overhead in rationalizing is substantial
• § Document libraries are created by default and are easy to populate. Nomenclature and meta data standards are not automatically applied, and bad habits associated with existing file shares are often transported into the document libraries. Document search and manageability, precisely the issues meant to be improved, become bigger
• § The SharePoint install is so easy that the subsequent expertise needed to effectively configure and govern SharePoint within the business is often dramatically underestimated until it is too late
• § Once installed, the ongoing management of SharePoint can escape the rigors of IT because of its ready take-up and hand-over to the business

What To Do?

Without effective and specialized governance, SharePoint will only replicate your business’ existing problems at a faster rate and on a larger scale than you thought possible!

You need a governance plan enacted in your business by an appropriately empowered steering committee.

This SharePoint Steering Committee should have enough seniority to ensure two-way business alignment, ie that SharePoint is aligned with the existing business governance plan and associated initiatives like the information architecture; and that the business plan can be updated to incorporate benefits derived from SharePoint.

The ubiquitous and innocuous File Share. To some it may seem strange that just loading hundreds or thousands of documents from their existing file-shares into a SharePoint document library doesn’t solve the problem of not being able to find things!

This sounds pretty straight forward. Just apply a SharePoint governance plan and all will be okay.

There are literally thousands of pages of information available on SharePoint governance. The Microsoft SharePoint Governance Plan and Check Listare a good place to start. An Internet search will return tomes of material on governance with some documents in the realm of 600+ pages in length!

Why Problems?

Why are problems still encountered?

The answer to this is two-fold.

First, with this seeming wealth of governance related material available, none is definitive, and most discusses what governance should do, not how to do it!

For example, we discussed above that SharePoint should be aligned to the business governance plan and information architecture. But how do you do that?

Similarly, the Microsoft Governance Plan identifies that up to 30 roles can be used to effectively govern SharePoint, but which business has the resource to cover all those roles or can encumber existing staff with that level of extra responsibility? Which roles are essential and what actions should they cover?

Second, for most Microsoft Partners, SharePoint is just one product in their already overloaded product set.  Consider the plight of the poor Microsoft Partner with SharePoint 2007, Office 2007, Windows 2008, SQL 2008 and VS2008 all released little more than 12 months apart. Which Partner let alone business has the ability to skill-up on that range of technology? ‘Heroes’ or not!

Fewer organizations have a history with SharePoint beyond the current version, and almost none can take a ‘holistic’ view i.e. discuss a SharePoint solution in the context of the entirety of its features set.

Governance plans talk a lot about ‘What To Do’ but not ‘How To Do It’. You need an extensive history with SharePoint, all its incarnations ie portal, DMS, CMS, BI, horizontal and vertical platform application, experience in its application to various business issues, strengths and weaknesses, to be able to best plan its use in the organization.SharePoint Practice Governance, based on an extensive experience of this kind of ‘best practice’ – a definitive body of knowledge- allows for the proactive rather than reactive planning of the use of SharePoint in your organization. If you don’t use deeply experienced SharePoint resources with access to this Practice Governance you are faced with trying to ‘learn on the job’ and with SharePoint’s tendency towards rapid organic growth, if you don’t get it right from the start problems will overwhelm the resources available to manage SharePoint..

It is only from experiencing SharePoint’s strengths and weaknesses across its diverse range of functionality, from portal, to BI, to DMS, to CMS, forms, from generic horizontal platform to adapted vertical solution, and how it performs across diverse business applications, that you can begin to understand and identify SharePoint best practice and effective governance practices.

SharePoint Practice = Best Practice

In short, you need a lot of ‘SharePoint practice’ to be able to provide ‘SharePoint best practice’.

Most businesses can not afford to implement systems, let alone a widespread platform like SharePoint, on a trial and error basis trying to work out the best way to do things ‘on the job’ (though some Partners often try to get away with having their staff learn that way!)

So in conclusion as you work through your SharePoint implementation and ongoing management, if it isn’t producing the business advantage and results you expect, find a partner who has a SharePoint specialistion.

Draw on their rich best practice to source and develop your governance plan, stop the SharePoint paradox, and get the SharePoint results and business success you want.

In following articles I will explore Practice Governance and the best practice it is based upon in more detail.

Till next time – Julian