SharePoint and Change – Part I

The following are some key items to consider when using SharePoint as a platform for change:

 

1)      Let proper team members know of change so that a plan for how to communicate change to organization can be created

2)      Define how SharePoint will be utilized in the organization. Will its main purpose be document management, content sites or utilization of key and core workflows

3)      Account for governance – know what users will be allowed and not allow to do. Make the governance plans readily available in a wiki or series of blog posts.

4)      Account for at least a one hour to 90 minute overview of SharePoint functionality that users will need to know (upload documents, use lists, how to search, how to use managed metadata, etc.)

5)      Develop and fine tune – processes for how best to manage work and requests in SharePoint by utilizing request forms for requirements so that an Agile model can be followed by creating from such requests the needed stories and tasks for what was being asked.

View Video:

Paradigm Shift & SharePoint

In regard to SharePoint a paradigm shift is present as a lot of the time newer processes are needed for the system to be successful. Thus, adopting these traits will be good to possibly utilize:

Have a plan – in this regard, it’s having a scope for the SharePoint launch – this should include not only a schedule for launch but a launch for each teams/departments new sites/subsites. When launched proper training of basic functionality (uploading, alerts and views) should be given.

Value Driven – sell the platform via town-hall meetings, videos, e-mail blasts and proper on-line documentation. SharePoint empowers users which can’t be un-sprung if users don’t know how to utilize the system or know what it can do.

 

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:

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:

 

User Centered Design (UCID) Methodology

To have a focus on end users throughout a SharePoint project – the UCID is sometimes utilized.

The methodology includes four stages and both developer/designers and end users are engaged and work together at each step:

Research concept and plan – at this stage getting the user and compatibility requirements is done.

Design prototype – via a white board or wireframe – an actual working prototype is built – because most end users are visual.

Define branding – what are the color schemes and logo to be utilized.

Develop, launch and test – the prototype is developed then put into production and tested for general usability and accessibility.

SharePoint is Collaborative

SharePoint is in many aspects about participation, sharing and collaboration. Overall one wants helpful, ready to use information that can be put to work quickly and easily. Thus, because of this three categories are prevalent:

1)      SharePoint is for organizations – with just a simple browser, it can be used by individuals throughout the organization. SharePoint is purpose driven encompassing an audience that includes executives, managers, decision makers, staff, etc.

2)      SharePoint is for communities – users can foster relationships based on profiles, actual communities, groups, wiki, blogs, etc.

3)      SharePoint is for public engagement – every interest in being engaged and telling a story with content on a site is key.

 

View 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