Category Archives: SharePoint

Office 365 collaboration – somewhere between easy and hard

The Microsoft Story around Collaboration Has Never Been a Straightforward One, with Different Styles of Collaboration from Email, through Skype and into SharePoint Each Being Supported by Their Own Microsoft Technical Team; at Times It’s definitely felt like the different teams compete rather than collaborate (and the irony is not lost on us).

With the emergence and massive growth of Office 365 the tale now has some additional subplots  in the form of OneDrive for Business, Office 365 Groups, Microsoft Teams and the still relevant  SharePoint Online. It’s not easy to unpick these different offerings and decide which to use where, especially as they share a lot of the underlying technology as each other.

Here are my summarised thoughts:

  1. OneDrive For Business
    • Think of this as effectively a file server in the cloud, but note that the assumption is that each person has their own area. With most Office 365 plans you get  1 TB of storage per person, which is a serious amount traditional  storage for your organisation. However it’s not the same as using a file server; best practice is to create a set of high-level folders within each person’s OneDrive: Personal, Team, Everyone In The Organisation, and External content. Share access of the last three appropriately. It is possible to have an admin or super user who can set their account up to provide something equivalent to departmental shares. It probably only takes a couple of days effort to implement this for a small organisation and that includes training and structuring the folders.
  2. Microsoft Teams
    • This is  both a browser-based and desktop application, which uses the Office 365 services on the backend. It’s described as conversation-centric collaboration (https://products.office.com/en-GB/Microsoft Teams/group-chat-software ); the front-end uses the chat capabilities of Skype for Business to provide the conversation element, though does have the ability to share files etc. and  includes OneNote  (you can also add other apps). The ability to configure it according to different needs is limited and there is no concept of an organisational hierarchy. It’s great for near real-time collaboration, discussion with team documents, but not so great for creating an organisational file store. Set up effort is also just a few days.
  3. Office 365 Groups
    • These are recently updated and provide email-centric collaboration, though with both simple file sharing and a full SharePoint site on the backend for each team or group (the language is starting to get difficult now, I’ll use uppercase when I’m in the product and lowercase when I don’t). ThUser experiences a bit of a mess  in that  the interface varies according to where you try to access Groups from – Outlook, Yammer, OneDrive for Business and SharePoint all provide access but the UI is different in each case). As with Microsoft Teams, there is no organisational hierarchy. Office 365 Groups are good for team collaboration and ongoing projects; also because the file store is actually in SharePoint, it does allow customisation so that libraries can have additional metadata and the full power of SharePoint; you can also create additional libraries within each Group;  however these are only  visible when you step into the SharePoint view of the Group,  not in this simplified view in Outlook etc. Our suggestion to make this really work for bigger organisations is to combine it with Cloud2’s Connect product, which will provide the hierarchy and a powerful entry portal. Individual Groups are very easy to set up, but there  is always some effort required to train users, determine best practice and extend some of the Group sites to meet organisational needs.
  4. SharePoint intranet
    • SharePoint is a huge application, highly suited for enterprise needs and with a massive range of capability to support collaboration, content management, communication, business processes and people. However this comes with complexity and the need to configure everything before it is effective (which is why Microsoft have introduced the previous three items). It will pretty much do everything that an organisation needs but a typical SharePoint Project in the corporate world takes upwards of 100 days of services. Even with digital workspace accelerators,  such as Hadron, the effort is still around 30 days, though these tend to incorporate other parts of the O365 stack such as Yammer and Skype for business. Where SharePoint really shines is for organisations with complex process needs , a requirement to govern some types of content and where the organisation itself is sophisticated with  a large amount of structure and enterprise level business needs.

 

    Clearly this isn’t a one size fits all situation and is unlikely at any one of the above will answer all the collaboration and content needs of an organisation. The right thing to do is to mix and match the technologies in the Office 365 suite in a way that suits your organisation, your strategy and budget. Whatever you do, research the tools and think hard before jumping in.

2 Comments

Filed under Intranet, Microsoft, SharePoint, UI and UX

Teams vs. Groups – Microsoft moves their vision forward a few more steps

Office 365 continues to develop, and it seems like something changes more or less every fortnight. This isn’t a bad thing, as long as Microsoft continue to make reasonable business decisions about the features and functionality; though the pace of change continues to present some challenges for partners and users alike.

One of the most recent announcements is the release of Microsoft Teams, an apparently new component in Office 365. Actually, not quite so new as this looks an awful lot like the immediate successor to Groups.

Groups was always a little odd; it started out as exactly that, pretty much a permissions group on to which Microsoft then tagged some collaborative functionality, initially as a shallow end alternative to a SharePoint collaboration or team site; this has evolved over a few iterations to now usefully include Skype-based group Conversations, Files (actually a SharePoint library, but with limited customisability), Calendar, OneNote Notebook (we really approve of that), Planner (their Trello competitor) and a related SharePoint Site. However, the Groups strategy was clearly work in progress. For example they got as far as introducing them into the Outlook online client and OneDrive for Business, though not really into SharePoint, which was odd. There are mobile apps, but no Group tile in the O365 App Launcher. Jeff Teper shared some of this thinking early in 2016 and indicated that there would be a change that would see Groups becoming Teams, removing the confusion between permissions groups and collaborative sites. It’s good to see this come to fruition.

Microsoft are describing it as an entirely new experience…

With the introduction of Microsoft Teams, Office 365 now has mail, social, and chat connections to SharePoint and OneDrive. When you create a team, you create or connect to an existing Office 365 group, and the group gets a SharePoint team site.

msteams

It is worth reading Dan Holmes pleasantly marketing-spin-free  description.

So with the imminent launch of Microsoft Teams (it is currently in preview) there have already been some changes. Groups appears to have disappeared from most places and Microsoft continue to tweak the positioning against full-blown SharePoint Online.

Microsoft Teams is available in preview to eligible Office 365 commercial customers beginning November 2, 2016. We expect the service to become generally available in the first quarter of calendar year 2017.

There have been some immediate refinements to the Office365 offering plans:

  • Business Essentials  explicitly  references  including Teams,  with no mention of SharePoint
  • Enterprise plans such as E1 take business essentials and adds SharePoint Online, Delve, Video Portal, Skype Broadcast, without the 300 user limit.

It’s not yet clear whether Business Essentials no longer includes SharePoint at all or whether it simply hidden away as being perceived as too complicated for simpler use cases. Whether you agree with that or not, is likely that Teams are here to stay for a while and they do provide a simpler means of creating a rich collaboration and team site than ever before.

 

 

Leave a comment

Filed under Intranet, Microsoft, SharePoint

The changing shape of modern intranets

I talk a lot about the five pillars of enterprise intranets: Content, Communication, Collaboration, People and Process; in the past we were the first company to develop a solution accelerator for enterprise intranets. This became our Hadron 8020 portal and attempted to serve all those needs and act as the one place that users can go to carry out the organisational activities based on the way these five pillars interact. However times are changing, Microsoft have evolved their technology and, in the process made the overall technology landscape more complex and fragmented; this is beginning to have a knock-on effect on what’s needed from Hadron and other modern intranets.

Continue reading

Leave a comment

Filed under Innovation, Intranet, Microsoft, SharePoint

I’m a recovering SharePoint addict

Hello, I’m Simon and I have a problem.

10 years ago I fell in with a bad crowd and started doing SharePoint.

I thought I was in control. Just a little session here and there; a quick hit of site creation or an hour or so wrapped around list and library configuration. It was just a little buzz, pleasant but nothing to get excited about. But these things tend to get out of hand; before I knew it I was linking web parts, building information architectures and worse. I liked it, I wanted more.

I’m rather afraid that I began to get others hooked too, introducing them to the rush of building a solution to a business need without writing code or even asking IT. Sometimes we would even hang out together, getting a group.

It started intruding into my day job, sneaking in via that oh so seductive Connect to Outlook button. I admit that I favourited it in Windows Explorer as well as in my browser so I could get to it even more quickly.

About 6 years ago I really hot rock bottom, quitting my proper job to spend all my time with SharePoint. That year was tough; I had dragged my friend, Taran, down with me and we spent every day, 7 days a week, for a year, lost in the murky world of metadata, site template design, business processes modelling, more information architecture. It was all-consuming. We persuaded others to try it, gathering people to us to share the experience. After a while we even rented a den in the centre of Bradford where we could cluster together over the cold and uncaring code. Our dealer, Microsoft, hooked us on a new cut in 2010 and we fell into that completely.

As we learned more and experimented we learned our own way to package the stuff. We became a major dealer. Our package made it more addictive and much, much easier for new punters to get; instead of a gradual addiction over 6 months or more our “clients” started to get there in 12 weeks, then 8. We stopped short of trying to sell it on street corners, but people started coming to us, referred to their network or word-of-mouth. Another cut from our bulk supplier came in 2013 and they also started pushing an airborne, aerosol version that made it even easier to get hooked, with a simple monthly payment plan and no paraphernalia to have to buy before you started.

Then something odd happened. The cravings changed. Instead of being immersed in a browser wrapped SharePoint haze each and every day I found myself weaned off it a little. It was still there in the background, but now it sat below what else I was doing. I would make a note, and SharePoint would be there to looking after my notebook, giving me a little buzz of excitement; I would write a document and SharePoint would look after it and even let my addiction buddies write in it at the same time, another buzz; I would check my calendar and there would be SharePoint. It seems like everything I do to get through the day has SharePoint to ease the pain or add to the pleasure. Of course I still get my proper fix every now and then, but it’s not as often now that SharePoint has become systemic; it’s more like an IV drip than a major hit, and I’m pretty sure that’s a good thing.

So things have changed. I’m definitely not over it, but I am more able to live day-to-day. I started reaching out to others struggling with the same addiction, getting them to move beyond the early phase and into the much more gentle territory beyond. We are still hooked, but the addiction and the cravings are under control. You might even say that is a good thing; the obsessive tendencies have mostly gone, the compulsive needs are manageable and the background buzz as business gets done, information gets shared, documents get managed and activities get completed, is a pleasure not a concern.

I’m a recovering SharePoint addict, but I won’t be over it any time soon.

Leave a comment

Filed under SharePoint

Extending the perimeter – thoughts on establishing Collaboration in cloud vs on-premise

Understanding the file sharing collaborative products available from Microsoft

We tend to split file sharing and collaboration into 2 categories, real-time and non-real-time.

Microsoft’s core real-time tool is a Lync which is available both online and on premise. Lync users are able to is to message each other, people’s availability via real-time presence linked to their Exchange Server calendar and elevate discussions from text to voice over IP with supporting video and/or screen sharing. Lync is a great tool for meetings, team briefings and small groups working together on activities in real-time.

For off-line use the traditional way would be to store documents on file servers and, due to limitation of file servers, distribute documents and other content that needs to be worked on or approved via email. The new approach utilises a combination of SharePoint and OneDrive for Business (which actually also uses SharePoint under the hood). SharePoint allows Microsoft Office documents and other types of file to be stored in libraries and worked on by multiple users at the same time. Some key features include genuine multi-author editing in many cases (up to 16 authors can have the same Word document open for editing simultaneously); support for sophisticated metadata including document status (e.g. draft, awaiting review, published, expired); version control and approvals; the ability to send a link to the document via email without sending the whole document. Collaboration extends to other kinds of content, such as lists of information rather than documents, and can include other things such as shared calendars, tasks and more.

Generally, SharePoint is used for formal corporate collaboration, internal processes and team collaboration. It is possible to include an extranet solution within SharePoint to allow collaboration with people outside the organisation. Recommended best practice is for this to be a separate set of sites within a separate site collection. For this to work with an on premise SharePoint farm there needs to be a route to the SharePoint environment from the Internet through the organisation’s firewalls.

OneDrive for Business can be used to support collaboration with external parties or for informal collaboration activities and is a cloud solution only.

The other core collaboration technology, in our opinion, is OneNote. Our best practice recommendation is to have multiple OneNote notebooks, and to store these in SharePoint or OneDrive. We find that one notebook per collaboration site works very well and provides a real-time information capture, note taking and semi-structured knowledge capture tool.

Understanding the ease of deployment of an internal HyperV cloud based solution,

Although organisations talk about internal clouds or private clouds, the reality is that the crowd benefits don’t really manifest themselves until organisations have large farms running where the individual HyperV servers can take on or switch roles according to the load on the farm as a whole. We rarely see this for farms under about 12 servers, which is substantially more infrastructure and is required for this kind of deployment.

Nevertheless, installing SharePoint on-site requires a considerable amount of investment. Key steps are:

  • design farm architecture
  • provision Windows servers on HyperV
  • source SharePoint Server licenses
  • Install SharePoint Server on HyperV servers
  • configure SharePoint server instances, including permissions, site collections, templates etc.
  • source SharePoint Client Access Licenses and allocate

Only the last 2 items would be required using the Office 365 platform

Once installed, and on premise farm requires around 20% of an FTE to provide ongoing admin for the farm and the application.

Understating the security functionality / configurability in both the HyperV cloud solution vs Office 365 cloud options.

SharePoint security is a massive discussion in its own right. The summary version is as follows:

SharePoint maintains a sophisticated internal security model that provides granular access based on permission groups (which may be tied to or interact with Active Directory groups), supports security trimming (which prevents users seeing any content to which they have no access) and assigns different rights (such as view, edit, approve) to different roles and allows different roles to be assigned to different artefacts (sites, lists, libraries etc.) throughout the application.

Access to SharePoint is via a standard logon process. For on premise solutions this is usually based on the users Active Directory/Windows credentials, providing single sign-on. For cloud solutions there is an option to synchronise these credentials or to employ full Active Directory Federation which gives the same single sign-on option.

On premise solutions (e.g. a HyperV farm) are protected from the outside world by the organisation’s standard perimeter security, i.e. firewalls, threat protection and prevention. While this is often considered to be secure, the issue with this is that any content that needs to be accessed remotely or shared with 3rd parties have to circumvent this perimeter protection and this sharing rarely have strong governance; the extranet option referred to above requires holes to be created in the firewall etc. which can present a risk not only to the SharePoint farm and content but conceivably to other applications as well if not managed correctly.

Cloud solutions, including Office 365, generally has a much more sophisticated perimeter security solution. Furthermore the physical security of the server farm is far greater than can be easily achieved by most organisations with an on premise solution. Communication with the cloud solution is encrypted via SSL certificates (https:) and there is an option to enable encryption of the database. There is also an option to employ 2 factor authentication, which is achieved using a one-time code delivered via text message or using an authenticator app on a smart phone. We recommend using this sparingly as is option interferes with the ease of access to information for users, who will typically revert to less secure methods in response. The cloud solution includes an option to enable external sharing without compromising any of the organisations applications; Best practice still needs to be adhered to to protect the content within the SharePoint environment as noted above.

Security within the SharePoint application is, to all intents and purposes, the same whether on premise or in the cloud. In most cases an Office 365 environment is as secure as an on premise environment; while it is exposed to more potential threats from the intranet this is balanced by more sophisticated threat prevention built into the environment. In cases where the solution is only required for internal, on premise collaboration an argument could be made that an on premise solution can be made more secure; however when external sharing is required Solution has the benefit of segregating itself from other business applications, reducing the threat surface and avoiding compromise to the organisations network perimeter while enabling external collaboration and remote working.

This position is backed up by a number of security certifications for Office 365 and other cloud solutions. This includes an announcement from the EU in April 2014 that Microsoft’s cloud contracts and infrastructure comply with EU privacy laws and the UK data protection act across all of their infrastructure (data centres in the US and Singapore are treated as being within Europe for these purposes under this clarification). Details can be found here: http://blogs.microsoft.com/blog/2014/04/10/privacy-authorities-across-europe-approve-microsofts-cloud-commitments/

Organisations are wise to do appropriate diligence and research on the security capabilities of cloud offerings. However cloud services have matured over the last 5 years and the Microsoft ones are considered to be particularly strong. There are few reasons to reject cloud solutions out of hand on the basis of security; many financial institutions, multinationals and other organisations with commercially or legally sensitive information are committing their content to the cloud, with appropriate safeguards (which can include tools such as AvePoint’s compliance Guardian which can monitor what is being uploaded).

In reality most organisations employee local security and network security that is, at best, no better than cloud solutions. As ever the single greatest threat is the action of staff, and this needs to be addressed equally strongly regardless of the location of the application.

Leave a comment

Filed under Cloud, SharePoint

SharePoint – a strategic platform for business optimisation. Part 3 – Adoption

Adopting SharePoint

There are a number of important activities to consider in order to drive success of the SharePoint implementation. These include seeking appropriate user input in the early stages, continuing to obtain user feedback for an extended period of time after deployment and being seen to act upon feedback, setting out a policy and set of standards for the way the solution is used, enabling a steering board to take decisions on the way intranet and the organisation should interact and, of course ensuring that users are appropriately trained.

Although SharePoint solutions are mostly intuitive to use the business processes that they model are often not; furthermore SharePoint introduces new capabilities which allow the adoption of new, more effective practices which users are likely to be unfamiliar with.

A good example is the replacement of familiar folder structures for storing documents with apparently flat document libraries containing hundreds or thousands of documents. The careful use of metadata allows this large quantity of documents to be presented in views that rapidly let the user find and focus on what they are looking for without having to trawl up and down to an arbitrary directory structure; this approach also eliminates the problems that are unavoidably associated with hierarchical taxonomies such as the case where a document could legitimately exist in more than one folder, or where people are excluded from accessing particular files because of their location and the permissions applied to folders.

Avoiding the old ways

A combination of training, policy, good practice guides and support our needed to transition users from the old ways of doing things to the new, more effective options. This is especially true in the early days of adoption in order to avoid users reverting to old habits or replicating poor structures that are difficult to later unpick. It is helpful to have a business analyst/evangelist who can actively promote the new ways of working through hands-on, day-to-day interaction with users in the early phase; this role also is instrumental in identifying undisclosed business needs and with confirming whether the decisions made on features and strategy are correct and effective. The role typically transitions to a more (no code) development focused one over this period of time.

Creating the new

One of the things we really like about SharePoint is a tendency to make people consider their existing processes. There is a reasonable view that if you don’t need to change things you don’t need to introduce a new technology. So conversely introducing a major platform like SharePoint should for things to change and not simply provide a new way of doing what you are already doing. If the introduction of a SharePoint solution doesn’t shake things up you probably shouldn’t do it!

Use the rollout of the new application platform to explain to people how things are going to change, to overtly deal with their reservations and persuade them of the value of doing things differently. Understand adoption curve (diffusion of innovation) and be ready for pushback and the tension between early adopters and Luddites. Decide if this addresses a business critical activity that needs an overhaul, a tool for creating cultural change in your organisation, is a new strategic direction, or is just someone’s pet project. In three out of four of these cases you will need to push staff into adopting the change and abandoning the old ways quickly; and you have the luxury of being fairly uncompromising on this, after all it is their job to do it the way the business mandates. The new ways of doing things that SharePoint engenders are genuinely powerful, create new capabilities and solve problems for users (even if they didn’t realise that they had the problem). Just remember that by adopting this slightly new way of doing things it may be somebody else you’re mostly helping rather than yourself. I’d like to think that we worked in organisational cultures where this is perceived as a good thing.

Leave a comment

Filed under SharePoint

SharePoint – a strategic platform for business optimisation. Part 2 – Implementing SharePoint

Implementing SharePoint

In many regards SharePoint is remarkably straightforward and flexible for developing solutions with; very many applications can be developed by simply selecting appropriate features such as lists and libraries, configuring them using metadata and views and aggregating these within a variety of functional sites within a portal. All this can be done by super-user staff (rather than a technical expert or developer) directly through the browser without the need for a separate development and environmental tools.

However the very breath and flexibility introduces complexity and a depth of knowledge and experience in order to effectively plan and build solutions in an efficient and supportable way. There are many ways to make mistakes and while SharePoint itself is a resilient and forgiving environment, badly built solution will both fail to meet the business needs and disappoint or disenfranchise users.

 

Finding the right people?

When building sophisticated solutions it is best to start with someone who already has the skills and experience to deliver configured SharePoint applications; ideally they should have some knowledge of the solution that needs to be developed as this both exonerates the availability of the solution and minimises the risk of building it wrong. To this end it is often appropriate to engage a partner or highly experienced contractor, if they have existing experience. In order to ensure the solution is supportable in the long term it is also appropriate for knowledge transfer to the internal team to take place during the development. This way they understand it and can develop it further themselves without resort to 3rd parties.

It is also appropriate to develop the business analyst skills required to assess, triage and specify new solutions internally, as well as be able to provide guidance and support to users. Keeping the partner or contract on hand has value but it makes more sense to have internal skills backed up by external experts.

 

Making a plan

Of course it’s really important to plan your SharePoint project and specify the application trying to build. However SharePoint projects are not best suited, in my opinion, the pure waterfall project approaches and rigid specifications. Although you can get reasonable clarity on functionality and features required it’s difficult at the outset to define exactly how that will be achieved, or the user experience should be like and how best to mould the feature set to solve the problems or address the needs. SharePoint projects lend themselves to agile processes. There is much to be gained through iterative development with ongoing user input and evolutionary definition of the requirements. The simple reality is that the users really don’t know what they need in detail until I can see it and touch it, at which point they will think of new things that they want, change the things previously stated as requirements and rearrange the things that they see or have prioritised. The trick is to see this is a healthy activity and build it into your development plan. Fortunately SharePoint is largely very forgiving of this kind of development model, however there are still things you need to get right at the outset, such as defining the overall site structure and information architecture and really understanding the combination and quantity of lists and libraries required to store the different types of information and the relationships between them. Don’t be afraid to build a proof of concept and throw it away, but don’t be surprised if your proof of concept tries to involve itself into production environment. Know when to stop.

We also recommend trying very hard indeed to avoid writing any new code. It’s amazing how many business solutions can be solved simply by configuring the capabilities that SharePoint already has or, with a newer versions, by plugging in a SharePoint app or third-party technology. Custom development is fully supported in SharePoint that brings substantial issues around ongoing supportability and upgradability, often with little benefit.

Leave a comment

Filed under SharePoint