SharePoint projects are no sure-fire successes
The communication and collaboration platform changes cooperation within the company in the long term
//
IT & Management Consulting, Microsoft SharePoint, Modern Work
Quite often, SharePoint projects are conceptualised and set up to mirror their technical capabilities. In many companies, the initiative for such projects originates from the technical department which considers SharePoint no different from any other software product and rolls it out. In this, questions regarding the “why” and “what for” are often asked too late. As such, failure over the short or long term is pre-programmed, given that the SharePoint technology is considerably meshing with the internal communication and collaboration processes. That, however, requires the support of all parties involved, from the responsible manager all the way to the user side.
Communication and collaboration function of SharePoint
Both communication and cooperation in companies are important, above all, for the exchange of knowledge. But with increasing frequency Excel lists and other documents are distributed all over the place by e-mail, resulting in a medium to large-sized versioning chaos. Here, the collaboration function of SharePoint provides for perfect solution approaches. Version histories, access hierarchies, and other characteristics are elevating working in a team to a new level.
SharePoint implementations must be planned from the user perspective
In a SharePoint implementation, first, the most important key players of the company have to get together to answer some questions:
- How is SharePoint expected to improve the company?
- Which specialist departments can profit from a SharePoint implementation?
- Which specialist departments will therefore be actively involved in the overall process right from the start?
From experience, it pays off to have the specialist departments explain their needs in the form of a questionnaire. Pain points and opportunities are collected from their respective point of view which, taken together, constitute the correct work foundation for the product.
SharePoint On-Premises or Online?
Whether the future company SharePoint should be operated in-house in the data centre or whether an online version that is based on Office 365 technology would be more suitable should be decided jointly by the technology department and the specialist department. Here, questions regarding operating costs and performance play a role, as do questions regarding data security and data integrity. The following table exemplarily shows which advantages and disadvantages result from the utilisation of SharePoint On-Premises in comparison to SharePoint Online.
|
SharePoint On-Premises
|
| - new SharePoint functions only available with great delay or not at all |
| + expandable via server-side programming since administrative access to the server(s) is possible |
| + infrastructure scalable based on own needs |
| + more granular administration and adjustment options |
| - operating tasks are the company’s responsibility |
| - rigid licensing model (only upwardly scalable), with one-time costs |
| - SharePoint availability depends on in-house data centre architecture |
| - access by external users requires an elaborate authorisation infrastructure |
|
SharePoint Online
|
| + Microsoft focuses development on O365 (Microsoft is pursuing an “Online-First” strategy) |
| + “modern sites” are optimised for mobile access |
| - not expandable via server-side programming since no administrative access to the server(s) is possible |
| - only a client-separated SharePoint environment (shared infrastructure) |
| + lower administrative effort |
| + operation is handled by Microsoft |
| + pay-per-use model (licenses scalable based on demand), but permanent costs, instead |
| + SharePoint availability ensured by MS (99.5 %) |
| + access by external users via a Microsoft account is included in the standard |
Whether or not the costs of a SharePoint On-Premises exceed those of a SharePoint Online depends on the individual case and must be calculated individually for each company. There are, for examples, set licensing costs as opposed to the pay-per-use model. The average initial costs of a SharePoint On-Premises project initially appear to exceed the costs of a SharePoint Online- project. However, it must be taken into consideration that monthly and annual permanent costs per user are incurred for SharePoint Online.
A big advantage of SharePoint On-Premises is that it can be applied to business process and use cases since there is the option to expand it via in-house developments. This works only to a limited extent in SharePoint Online. To pull its customers into its own cloud, Microsoft has tried to design SharePoint Online to be more appealing. This Online-First strategy manifests itself, among other things, in that new functions become available in SharePoint Online significantly sooner (or exclusively).
Furthermore, a lot of companies are afraid to place their data in the hands of a cloud provider and - for those reasons - opt for the On-Premises variant, instead. At this point, however, it must be taken into consideration that this results in not only the company’s in-house data remaining within the company but also the operating tasks and the availability risk. If a company opts for SharePoint Online, the risk is shifted to Microsoft as far as the operation and availability of the SharePoint are concerned.
Most of the time companies have highly and less highly classified documents so that it can be most desirable to combine the best of both worlds. A hybrid configuration allows for linking the in-house SharePoint environment with a SharePoint Online instance. Via the Governance & Compliance Center in Microsoft Azure, it can be assured that document types which are only hesitantly stored in the cloud are made available only on the On-Premises platform. On the other hand, the SharePoint Online can be utilised for traditional Intranet applications for the exchange between employees, for example.
SharePoint authorisation structure and architecture subsequent to extensive proof of concept
In the course of a SharePoint consultation, the question arises, on the one hand, who should be responsible for the authorisation assignment of the SharePoint, and on the other, which SharePoint architecture is suitable for the company. Quite often, the existing Active Directory foundation is relied on for this, since the business structures already are mapped therein, and - among other things, departments have been stored as groups. This ultimately means that the individual departments receive access to their documents and can work on them jointly. A cross-departmental cooperation is not planned for this way, however. At this point, the IT department has both the responsibility for as well as control over the authorisations since it is responsible for the administration of the Active Directory. With this structure, the company is, however, giving up the flexibility of cooperation.
These foundations are potentially unsuitable for the special concerns of a collaboration platform, since the SharePoint is not striving for an encapsulation of structures but rather for opening them up so that a cooperation can also be performed cross-departmentally, e.g. in project teams.
Therefore, the option is, furthermore, available in SharePoint to allow users to assign authorisations themselves. They can then decide for themselves with whom they’ll share their documents and, as such, provide for more flexibility in the cooperation. As such, a marketing employee may, for example, share a document with an employee from engineering and to allow for joint processing. As a result, the IT department is, in turn, giving up control over the authorisation concept. Such a concept, however, makes corporate governance more difficult and harbours the risk of losing overview of the authorisations.
Which SharePoint authorisation assignment a company ultimately opts for, or whether an interlocking of the structures is advisable, depends on the individual requirements. In order to combine the advantages of both worlds with one another, a well-founded consultation is necessary.
The SharePoint architecture must be a fit for the company’s way of working. As such, it should be taken into consideration, among other things, how the structure of web pages is to be design or which tools will be used. Since the SharePoint influences the internal cooperation, the final decisions regarding the architectural foundations should be made only after an extensive prototyping phase in which the developers can develop the suitable foundation step-by-step in constant exchange with the specialist departments. With this recurring “proof of concept”, it is ensured that until the conclusion, the benefits requirements of the specialist departments control the development and not a single arbitrary idea from a technical point of view.
The SharePoint is much more than a file server
A file server provides a central repository for documents in a computer network. In case of a corresponding organisation, this central storage provides for a better overview over existing files. The SharePoint provides usage options that go beyond those of a file server. The option exists, for example, to link a workflow to a document, or to add meta data to documents, in order to manage multiple target group-oriented viewing dimensions. Furthermore, in addition to the concurrent editing of documents (co-authoring), the SharePoint also allows for a version administration.
The idea that the SharePoint could be a good file server alternative since all files can be retrieve online now is one of the widely spread misconceptions. Transitioning the folder structure of file servers unmodified into a meta data structure in SharePoint is overlooking the fundamental differences in these two systems of organisation.
Sensibly, only work documents and those that have been released for cooperation are placed on the SharePoint. For all other data, such as image and video files in raw data format, the traditional file server is the right place. The reason for this is that, among other things, the load times can be very long – depending on the design of the architecture.
A page template for all departments provide the user with certainty
The most important planning task consists of answering the question: Which benefit should the collaboration pages generally bring to each specialist department and how do they therefore need to be structured? If such a generalised specification does not exist, each and every specialist department will set up what it needs. The result then will be correspondingly diverse.
Generalised templates which all specialist department use for orientation when setting up “their” site ease the cooperation across specialist department boundaries. As such, templates for work areas can, for example, in advance contain a notebook a task list, a calendar, three document libraries, and a specific design.
A complex software deserves proper training
Each and every complex software should be brought into day-to-day ue with a commensurate introduction or training. Corresponding to the degree of utilisation and familiarity of the employees, a step-by-step unlocking of the various features and functions also is a good approach that can prevent placing excessive demands on them.
In smaller organisations, in particular, it is a good option to turn “power users” from the planning and implementation phase into experts for day-to-day inquires from the circle of colleagues.
In Summary
The utilisation of a communication and collaboration platform based on SharePoint can change the cooperation within the company with lasting effect. The objective of this brief discussion was to point out that a SharePoint implementation is a complex and strategic topic. Since the SharePoint is influencing the internal communication and cooperation processes to a high degree, the specialist departments should accompany the implementation process right from the start. It is only this way that the change can provide the desired benefit.