SharePoint Interaction Survey

When working with individuals and engaging with them on SharePoint projects, it’s important to gather some form of feedback – possibly via a survey or a face-to-face question and answer session.

Below are some questions to ask about the project:

1)      The process made it easy to complete tasks?

2)      Time was used efficiently?

3)      A personal interest for the project was displayed?

4)      Ownership of tasks was utilized?

5)      Clear expectations were set?

6)      It was demonstrated that knowledge of the situation was present?

7)      Other comments as applicable?

SharePoint and a Sprint Review Agenda

When SharePoint is utilized with agile, the following are some key tips to utilize during a sprint review agenda:

1)      Welcome everyone and state that during this time slot the SharePoint increments completed will be demoed.

2)      State what SharePoint aspects will and will not be demoed. Usually it is good to have test data in the sites, libraries, lists and workflows that are part of the demo.

3)      Demo the functionality in either a test or staged production environment.

4)      Discuss the new functionality and answer questions surrounding the delivered increment.

5)      Present upcoming backlog items as far as the features and functionality surrounding SharePoint.

6)      Conclude and review what was achieved during the sprint review and make sure that the product owner will enter and adjust priorities in the backlog.

View Video:

SharePoint & Waterfall

When it comes to what project methodology to utilize in regard to SharePoint, waterfall is indeed one method.

To use Waterfall with SharePoint the following steps are followed:

Gather system requirements – which for SharePoint this usually involves what is needed for a site/subsite, workflow or piece of functionality (custom web-part, list, calendar, etc.).

Software requirements – for SharePoint sake this could involve what features to turn on/off as well as what functionality to build.

Analysis – look into SharePoint from a 360 degree overview in order to meet requirements via how users work today. This involves knowing what works and doesn’t work for users after talking to them.

Program Design – in SharePoint speak this would involve the applicable page layout and needed imagery.

Coding – a developer, administrator or analyst – would then build the SharePoint functionality.

Testing – users would utilize a created test script to test and signoff on what was built.

Operation – functionality is put into production and when changes are needed – the process steps are repeated as needed.

View Video:

SharePoint & Agile Scrum

Overall – SharePoint and agile scrum are a good fit for many reasons – the common aspects of Epic -> Feature -> Story and Task are given an overview below of how they fit together in a SharePoint project.

Epics - SharePoint agile scrum allows teams to formulate epics (which would encompass a major release) – overall, epics maybe good for a new installation, upgrade, or cumulative patch of SharePoint.

Features – in SharePoint agile scrum, a feature (working functionality usually part of an epic) may consist of creating a custom web part or creating a new workflow for a change control process (these can be the features that are part of your new install).

Stories – these are the aspects that need created/built which will allow users to accomplish what they need to do in the said system. Stories are usually written in the context of:

As a <   >, I need  <   >, so that I get <  >. Where the text between the < > would be filled in by the users or an analyst working with a user.

A SharePoint example of a story would be:

As an end user, I need a button which when checked populates a list so that I get changes from the change control system from the day before.

Tasks – as part of a story – tasks will be needed so that the aspects that make up the stories asked are created and built.

SharePoint example:

                Custom list is created with proper fields

External content type is created for change control status field

Form is designed with button lookup to change control system

Thus – core agile scrum methods can indeed work well for SharePoint and tweaked and defined based on one’s business needs.

 

View 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:

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.