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.
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.
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.
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.
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.
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
