Monday, September 18, 2017

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:

Thursday, September 7, 2017

Three B’s of SharePoint

Overall in SharePoint the three B’s are important concepts to know in regard to the framework options of SharePoint:

Business Connectivity Services (BCS) – Enables users to read and write data from external systems – through web services, databases and .Net assemblies.

Business Data Catalog – Provides connectivity to back-end business systems and data sources.

Business Data Connectivity (BDC) – provides business connectivity using a declarative model to external systems so that external data can be exposed in SharePoint.
View Video:

Design a SharePoint Taxonomy


One of the most important aspects of SharePoint is having a good taxonomy -> because how users find information as well as where new sites and subsites are built depends on taxonomy.

Typically, I recommend that a taxonomy be filled in as such – so that end-users can start to see how the information, libraries and meta-data in their site will be created:

The one item – I’ve been utilizing for many years is the use of a private site which basically is a team site with unique permissions only to those users whom are granted permission to that said site.
View Video:
 

Saturday, August 12, 2017

How to Measure Success in SharePoint

The following are some items to consider to measure that SharePoint is successful:

       End-users understand the capabilities of the platform and are well trained to use them

       New sites and applications are systematically introduced with quick time-to-market leveraging site templates, compliant with standards which follow approved corporate branding

       Governance teams review and proactively act based on the usage data and business needs

       Business users are aware of the security model and help to enforce

       Service-level agreements (SLAs) are in place, platform performance is good, and any custom coding and enhancements are well tested

       The growth of the server farms, servers, and storage is planned out to be scalable as the business needs

       Operational costs are in line with business value delivered by the platform
View Video:

Building and Evolving SharePoint Governance

The following are some points to take on while building the phases of a SharePoint Governance plan:

       Initial work stream should focus on:

- Addressing major areas of operations, support and development activity

- Mitigate key immediate risks

- Establish the right organizational structure and ownership is key (people aspect)

- Develop foundation of governance polices, standards and a compliance process

       Leverage existing processes and teams

       Bring in new teams only to help with gaps in the organization

       Realize that the governance document or wiki is a living document and will change with the business
View Video:

SharePoint Governance Phases

The following are three key phases to utilize when putting together a SharePoint governance planned approach:


       Phase 1 – Plan and Initiate

       Establish appropriate teams and oversight

       Develop actionable SharePoint strategy aligned with business needs

       Define initial set of policies & standards with focus on short term pain points

       Start education and training

       Implement compliance enforcement processes

       Phase 2 – Operationalize

       Integrate policies and standards into day-to-day activities and existing processes

       Finalize policies and standards

       Continue oversight, education and training

       Automate compliance where possible

       Phase 3 – Mature as needed

       Review progress and results

       Mature policies, standards and processes

 
View Video: