SharePoint Wheeling & Dealing

The following items can be used in regards to issues with SharePoint for what I call the wheeling & dealing:

 

1)      Think on how one can better a site via content, graphics, features and functionality

2)      Ask for clarification – if content and layout being asked for doesn’t make sense

3)      It is recommended to create a wiki of governance items that contains polices in regard to sites, permissions, naming conventions, requests for new functionality amongst other items. The wiki can then be referred to as the golden rule when issues/clarification is needed

4)      Ask users when you meet or talk with them “Am I making sense?”

5)      Say something once – in regard to pushing back when items out of scope are asked – then move on – don’t have negative behavior

Video:

SharePoint – Working on a Project Collaboratively

Some core items to work collaboratively:

1)      Have to have process for how SharePoint projects are run (Agile, Waterfall, Constructive Cost Model – COCOMO, etc.)

2)      Have to obtain – good detailed specifications for what is needed on a site

3)      For new requirements that are requested – have to have process for approval if items will be approved by project/manager/manager/director

4)      Have to decide if out of the box functionality works or if customization is required

5)      Have to track issues/support tickets even if they are calls, e-mails or via a web-based form entry

6)      Capture changes to sites/applications thoroughly (maybe just use a simple custom list)

7)      All team members across the group – should be on the same page

 

SharePoint – Top 10 Ways to Train Users

The following are the 10 top items to consider in regard to SharePoint end user training:

1)      Create short quick guides (4-12 pages) of applicable features (uploading files, views, using calendars etc.)

 

2)      Create short videos on key aspects and make sure the videos are organized by topic area. Make them available via easy to find subject titles

 

3)      Create a blog and then post key items which the system can do – have good clear categories available so users can find information quickly

 

4)      Create guides 20-50 pages for those whom will be acting as site owner/content owners

 

5)      Run lunch and learn live and remote based sessions – keeping subject matter one hour in duration

 

6)      Offer – live training one hour to 90 minutes in duration which encompass showing users needed functionality

 

7)      Create a custom self-help by overriding the ? with one’s own content (could be a custom wiki/blog)

 

8)      Create live classes and offer a curriculum teaching basic users (covers navigation, terminology, simple basic items in regard to what SharePoint can do, etc.)

 

9)      Create live classes and offer a curriculum for content owners (covers editing/adding pages, creating lists and views, etc.)

 

10)   Create live classes and a curriculum for site owners (covers editing/adding pages, creating sites, handling permissions and site features which can be enabled, etc.)

Video:
 

SharePoint Purchasing Travels – Capital vs. Expense

In my travels – around the world of purchasing SharePoint – I’ve had a variety of experiences. Typically – my experience has been I’m sent a very complicated spreadsheet from a re-seller or directly from Microsoft. I’m then based on the numbers in the spreadsheet – trying to negotiate the best price per seat as well as per server license. Since a large majority of my experience is based with on premise I’m keen to the fact that every user that attaches or will possibly attach to SharePoint needs a license.

Now, if I’m running a standard edition only – typically this is easier because all the users will need a license. Now, if I’m running an enterprise edition – it’s a bit more complicated because not only do all users need a standard license but they will also need an enterprise user license as well. This in my view is a complicated aspect that many don’t realize.

I will say however that the model has gotten easier as Microsoft now provides an enterprise framework, however even though this appears to be marketed for the cloud based organization, it can be utilized for on premise and cloud. Example if one purchases 100 user licenses under what is known as an E3 (Enterprise 3) license those licenses can be utilized for either on premise or in the cloud. This makes getting users the needed tools quicker and easier.

In regard to cloud, those who rely on a capital vs. expense budget are in luck. Under newly established accounting principles cloud based can be capitalized if one can make changes to the software/system and also if the service can be controlled from an on premise point. Therefore, if one is in an hybrid situation where SharePoint is installed on premise and OneDrive for Business is in the cloud – the case can be made that the cloud standard are met and can capitalize expenditures instead of using an expense.

Historically, a vast majority of the SharePoint work I’ve done is expense (training, user licenses, service agreements and support and enhancements) while I’ve capitalized the following -> server licenses, virtual machine licenses, virtual machine racks, and software licenses.

Every organization may think differently on this front but in my view it’s an important one to think about to account for as it’s not always about what SharePoint can do, but how to get it!

Video:

SharePoint Disaster Recovery Thoughts

Lately – the subject matter of SharePoint and disaster recovery has been an interesting one which I’ve had several discussions about in my various SharePoint travels. This is indeed a serious subject that many times is not thought out, nor planned – nor even tested or accounted for. However – in my view the opinion should be that as much time is spent in setting up and architecting a SharePoint site, this same amount of time – should be spent in thinking about a disaster recovery strategy.

I see two views on this matter – the first is what I will call the “poor version” of disaster recovery and this involves essentially backing up and then shipping offsite the SharePoint databases each night. This plan also would include shipping off the snapshots of the virtual machines as well – so that a server and database set can be restored if necessary.

The second view and more expensive model involves taking a back-up each night of the whole entire farm and then having that farms copy of assets go to a local storage hub as well as offsite. In this model when I’m talking farm – I mean the whole farm – virtual machines, databases, configurations, site collections, sites, document libraries and lists, etc. In this model if someone deletes a whole site – it could be recovered in full – regardless of the size of the site. Also if someone deletes a library or list it can be recovered. Additionally a policy under this model could be put in place to have the data be stored for 90 to 120 days – which would be double the standard 30 day – end user recycle bin and then 30 day administrator recycle bin – that is currently available.

Thus, this is a broad topic but my goal is short posts to get you thinking!

Project Methodology - Waterfall vs. Agile for SharePoint Projects

In regard to project management methodologies and SharePoint – for a long time I utilized a pure Waterfall methodology where requirement analysis, system design, implementation, testing, deployment and maintenance was done. Since a large majority of the SharePoint work I’ve done to date involved migrating content from one system to another or from one SharePoint version to another – this methodology appeared to work well in these projects – however pros and cons were evident. Essentially since content always needed to be reviewed the requirement was well known it was move content from this SharePoint location/version to this SharePoint location/version. At the system design phase – the Waterfall and SharePoint do work a majority of the time because it is known what the said systems base will be utilizing. The only aspects from a systems standpoint is that from one version to another – different features typically needed to be turned on to support needed functionality. Great example being site publishing. Testing using Waterfall – seemed to always be slow as test scripts either needed to be written or a load test needed created in the designated application (example: Load-runner, Team Foundation Server, Stress Stimulus etc.) Additionally, deploying using Waterfall seemed to produce a fair amount of documents surrounding lists of various items that needed turned on, configured for, migrated, moved etc. Then maintenance using Waterfall – really always seemed to leave a lot to be desired as guess work into what was really being asked for a lot of times – resulted in sites and subsites that didn’t meet user’s requirements and thus – had to be scrapped.  

Now coming to age – it appears SharePoint and an agile project methodology – work well. The notion of creating work that is broken down into 5, 10, 15, 30, 60, 90 day sprints is ideal.  For the larger work an epic – usually work that spans a quarter (or 90 days) works well for SharePoint because typically this is how long the complex world of SharePoint to migrate a site or create it – spans if all the bells and whistles of content analysis, design, graphics, training and testing are to occur.

An example of an epic maybe: [SharePoint 2016 – IT Site]

A feature which would be a core item that needs to be included in the project and associated with this epic maybe: [SharePoint 2016 – IT Site] – Create IT site

Stories are core working pieces that need to be built and are part of a feature – so example items are:

[SharePoint 2016 – IT Site] – Create IT homepage landing

[SharePoint 2016 – IT Site] – Create IT calendar page

[SharePoint 2016 – IT Site] – Create IT contact list page

[SharePoint 2016 – IT Site] – Create IT project list page

Tasks will then appear under each story so in this example case these would be:

[SharePoint 2016 – IT Site] – Create IT homepage graphics

[SharePoint 2016 – IT Site] – Create IT homepage content

[SharePoint 2016 – IT Site] – Create IT calendar permissioned to only managers

[SharePoint 2016 – IT Site] – Create IT contact list permissioned to only IT employees

[SharePoint 2016 – IT Site] – Create IT project list permissioned only to project managers

Therefore putting this down on paper with the epic/feature/story/task – the project mapped out would look as such where the indenting depicts where the item fits in regard to this methodology:

[SharePoint 2016 – IT Site]

[SharePoint 2016 – IT Site] – Create IT site

[SharePoint 2016 – IT Site] – Create IT homepage landing

[SharePoint 2016 – IT Site] – Create IT homepage graphics

[SharePoint 2016 – IT Site] – Create IT homepage content

[SharePoint 2016 – IT Site] – Create IT calendar page

[SharePoint 2016 – IT Site] – Create IT calendar permissioned to only managers

[SharePoint 2016 – IT Site] – Create IT contact list page

[SharePoint 2016 – IT Site] – Create IT contact list permissioned to only IT employees

[SharePoint 2016 – IT Site] – Create IT project list page

 [SharePoint 2016 – IT Site] – Create IT project list permissioned only to project managers

Thus, it’s easy to see why the Agile methodology lends itself to SharePoint in a much broader way – as features, stories and tasks can be created as the project itself evolves. Since SharePoint lends itself to creating sites of business value – by using an Agile methodology users will have real working sites with the needed requirements more quickly and can therefore, change items as needed as the sprint progresses. Because of this – I’ve found that Agile is a better project methodology choice for SharePoint projects then Waterfall.

SharePoint - Public vs. Private Site

An overview of public vs private sites.

Public Sites – A site referred to as public will by default be available in a read only format to all users whom have access to the said Internet or Intranet site. The home page of the Intranet is an example of a public site.

Private Sites – A site referred to as private will only be available to those users whom have been granted access. Such sites will contain team collaboration information which should be shared only to applicable users. An example of a private site would be an IT Private Site which would contain content and diagrams which only IT team members would be able to see and collaborate on.

Overall, a good rule of thumb would be to have a private site created and available for applicable team members to create master content in (example as a .doc or .docx format) – then if such content is to be viewed on a public site – it should be created as a .pdf then uploaded/moved to a public site. This way, master documents are kept on the private site – then only posted in a .pdf format to a public site when content is to be shared to a wider audience.