Hi everybody,
Fairly new to SharePoint, we are planning on using Office365 SharePoint for a company information WiKi but we are getting stuck with setup.
We have several departments: HR, Management, Sales, Marketing, IT, Finance.
Should we setup a separate WiKi library for each department ? As obviously management information doesn’t want to be shared with Sales etc..
What about company information that is relevant to everybody, should we have an everybody WiKi as well as one for each department.
It seems a pity that you can’t have folders and permissions within a WiKi library (easily).
Each department also needs to have its own document library.
Or would a subsite for each department containing a document & WiKi library workout best ?
I originally started with the subsite structure but have now switched back to lots of different library’s on the main site, however I am now thinking of heading back down the subsite route.
Just wondered if anybody had any compelling advice ?
Thanks
BigJoe
So everyone has their own opinion on this and it is largely based on their own experience. There are some best practices that Microsoft has posted.  This one is around Governance and still should be considered here, so I encourage you to read it.
I don’t know if I would continue down the path you are currently on. It can get messy and you are forcing your single site to have one purpose (maybe two). To hold wiki pages and documents. There is no room for growth as your company matures with the product. I would set things up more as team environment. So have one site setup entirely for a team. You can get more granular if you wish from there. For example, setup an IT team site. It can hold subsites for your Dev team or your LAN\Server team. This way each group can store documents that are specific to them. On top of that you can store documents and wiki pages for the IT group as a whole in the parent site. This may seem a bit silo-ed but it does allow for logical separation. I would be careful in that I would suggest you don’t go any deeper hierarchically than that.Â
The way you are designing can cause some serious admin issues down the road if it hasn’t already. Another things I would strongly suggest is that you have sections (maybe separate libraries) for confidential\restricted documentation. Things that contain employee information, financial information or business confidential information. Keep that separate. The reason I say that has to do with my next suggestion:
Open up the access. Don’t ask “Why do you need access?” Instead ask “why shouldn’t I give you access”. The biggest pain point I hear from my clients is that SharePoint doesn’t let them share that easily (not if you follow best practices in security). If you open up the access to things that don’t need to be secure (see above) then users can collaborate so much easier. This means that even if you are a bit silo-ed, it doesn’t matter too much because people can still access the data they need. SharePoint has protections in place to ensure things don’t get messed up (version history, recycle bins, auditing).Â
I kind of went off on a tangent there, so please allow me to recap. I suggest you go to a bit more separation into sites than you have. Allow for some granularity (HR to HR, Sales to Sales, etc), but don’t restrict the access where you don’t need to.
I hope this provided some help,
David
