SharePoint Intranet site - where to start

So the gist of it is to create a single site, with multiple pages, multiple document libraries, etc, etc.

Would the libraries be split per department or just be a repository for documents per se?

We have a team that splits data into projects, they currently use a folder structure to store data against a project, so they would have a site per project, yes? Currently our CRM system stores documents against a project / opportunity (soon to be against a project relationship), by the looks of it in a folder structure within SharePoint.

I honestly don't think we will ever move away from separate sites per department, it's how the business has been developed for many years and I cannot see it changing due to a new intranet site being developed - but hey should be fun trying.

Thanks for your help so far.


Matt

P.S. One question is why does microsoft harp on so much about team sites if you are advocating personal sites? https://support.office.com/en-gb/ar...e92-8ad3-3f8b0b6cf261?ui=en-US&rs=en-GB&ad=GB
 
Last edited:
From practical experience, once you create a team site people create a folder for themselves within a document library for their area and then dump all their crap into a single folder or library with their name on it. It is completely unstructured, uses no tags or workflow and is useless to anyone but the person who created it and they will then complain that it doesn't work as simply as how they used to use it.

So what I am advocating is to get your structure right first time because once people start using it, you are pushing a bolder up a hill. Team sites contain information specifically for the team, so documents that are relevant for the whole team and the sub-sites within the team site are for projects that the team are working on just together. The team site then displays information about the team such as how awesome it did last month or information about new procedures and documents they require you the external team member to use. As well as contact details and all the useful information someone else might need.

Project sites are for projects that affect multiple teams and it is here I am trying to get the point across to you about sharing because typically all projects relate to other teams, so you don't really want project sites on a team site. The reason for this is ownership and management. Middle management get very touchy about ownership, so it is best to just make project sites open. Projects might have sub sites about the project and even sub project sites, but it keeps it all organised and so once a project is done it can all be closed off and viewed historically. This way you manage data that is relevant and it gives people a central point to look at to use as guidance when repeating activity.

The idea of people putting documents on personal sites initially is just to get people using SharePoint as a place to ensure data is centrally available, secure and stored safely (I hate to use the word backup as it creates the wrong connotation for what SharePoint should be). Once people are using SharePoint as THE place to store data you are at milestone 1 and can say to management that you have made documentation safe, secure and available. It keeps your stakeholders happy and gets your customer base happier with the idea of using it.

From here on it is about letting the customers lead with their requirements, so they want to share documents about a project or within their team. Well they can just move documents to this project site or team site, but you can show them of the dangers of using it incorrectly and whilst creating a basic site for them and helping them populate it under your supervision.

If they haven't used SharePoint before they will be impressed how easy it is to create something so quickly and you can use this time to gather some requirements.
 
To answer your questions in more detail.

  • No don't just create a single site, create many sites, make sure you give them relevant names and it will be your job to manage these sites lifespans.
  • Give people personal sites (Mysites) and let people share work through them as well as store personal information such as PDP and expenses privately as well as a place to put all the crap they might use to build a document.
  • Create sites for specific requirements, so team sites for teams to put shared documentation. The team site can contain project sites, but these project sites should be for internal team projects such as providing better service or a place to show information about the teams hours, structure, who to call for what, how well the team is performing and hidden information that is only relevant to building the team.
  • If this is live / draft documentation then this is the time to look at workflows and procedures, but don't get ahead of yourself until you are confident doing it.
    As a further note, try to start building a managed term library across the organisation. The general message is to try to avoid unmanaged meta data. (This allows you to provide relevant information and should you ever adopt Office Graph then it will make life simple).

  • Project sites for project documentation related to organisation projects that affect multiple teams

Don't run before you can walk, so for your own sake just focus on simple things like ensuring work is being shared and documentation is secured.

You can create a project milestone for this in SharePoint using a task list and
show people your achievements in SharePoint to your seniors, and you can connect this to Outlook as well which can be used to Share tasks through.

Focus on simple milestones and build the infrastructure up piece by piece else the project will fail.

Having a snazzy front end is massively time consuming and doesn't actually do anything, so forget web design in SharePoint. When your organisation wants branding then they can folk out the cash for an upgraded licence and pay for a web designer to do it. Stay well away from SharePoint customisation unless you already have the experience. SharePoint master pages are not pretty.

Another note about workflows and integration with Dynamics CRM. You WILL need Visual studio to do anything really clever. Sure there are out of the box workflows and some customisation in SPDesigner, but long term you will be needing to start learning Visual Studio in either VB.Net or C#. However save doing this until you are being demanded to because a great many organisations never even get this far.

My focus would be: -
  1. Personal document management - Getting everyone on board
  2. Organisational document management - Getting people sharing
  3. Team document sharing - Building teamwork and further management
  4. Project management - Developing projects management and enhancing document management
  5. Organisational collaboration - Organisational sharing and historical justification
  6. Workflow

Another side note, is that H.R are probably your best bet to get things developed and shown off because they are primarily internal to the organisation and everyone uses their documentation. Also it is another potential milestone because you can say this type of documentation is now being centrally managed and nobody can deny the work you have done.

For other simple improvements focus on things like removing erroneous documentation, removing duplication of documents by centrally managing document sharing (through links and not email), enhanced version control (no need for V1, V2 at the end of documents), shared documentation (documents are visible to anyone at any time upon demand), structure (documents are kept in a organisational format), collaboration (people are able to empirically justify their work through existing documentation).

Matt_Hirst said:
So the gist of it is to create a single site, with multiple pages, multiple document libraries, etc, etc.

Would the libraries be split per department or just be a repository for documents per se?

We have a team that splits data into projects, they currently use a folder structure to store data against a project, so they would have a site per project, yes? Currently our CRM system stores documents against a project / opportunity (soon to be against a project relationship), by the looks of it in a folder structure within SharePoint.

I honestly don't think we will ever move away from separate sites per department, it's how the business has been developed for many years and I cannot see it changing due to a new intranet site being developed - but hey should be fun trying.

Thanks for your help so far.


Matt

P.S. One question is why does microsoft harp on so much about team sites if you are advocating personal sites? https://support.office.com/en-gb/ar...e92-8ad3-3f8b0b6cf261?ui=en-US&rs=en-GB&ad=GB
Click to expand...
 
Last edited:
Right so I have a number of sites in Sharepoint Foundation 2013.

I have created a number of document libraries on what I will call the master site - what I need to be able to do is show these document libraries on different subsites but I have tried a number of different ways , after googling but none appear to work. - Surely a better way for this would be to create one document library where all documents go into - the documents would be itemised / identified by metadata attached to them to signify what they are, the various views of this library would then be filtered - or is this totally wrong?

Any ideas on shaing the libraries, everything seems to point to me needing the paid for version of Sharepoint but at the moment without showing a few things that are possible in 2013 I won't be able to get buy-in.


Matt
 
You must log in or register to reply here.
Back
Top Bottom