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:

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:

 

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: