Login

Fillable Printable SharePoint Best Practices Project Brief

Fillable Printable SharePoint Best Practices Project Brief

SharePoint Best Practices Project Brief

SharePoint Best Practices Project Brief

SharePoint Best Practices (Phase 1) Project
Improving the SharePoint experience and showcasing exemplars
PROJECT BRIEF
Project abbreviation
SPBP1
Project Title
SharePoint Best Practices (Phase 1) Project
Start Date
1 June 2012
End Date
31 May 2013
Project
Sponsor
Dr Michael Fraser
Project Manager &
contact details
Dr Mark Norman
Email: mark.norman@oucs.ox.ac.uk
Address: Oxford University Computing Service, University
of Oxford, 13 Banbury Road, Oxford OX2 6NN
Tel: 01865 273287
Fax: 01865 273275
Collaborating
department(s):
PICT funded.
Social Science Divisional Office, Council Secretariat
1. Purpose of this document
This document is a lightweight project management document, including the
business case, objectives, deliverables, schedule and significant risks of the project.
The document will be updated monthly, with the recent changes highlighted thus.
2. Background
The Nexus SharePoint service was launched in April 2011 for the collegiate University after
an early adopter period. It has been recognised that, due to its beginning from a low starting
point of understanding that potential, the uptake needs to be stimulated in order for the service
to be as successful as possible. Currently the Nexus team provides very little outreach and
encouragement of best practice, but runs a robust, highly available service. In the early life
cycle of a new service, this is not enough and the Groupware Programme Development Panel
has acknowledged this in their request for enhanced support for several high profile
committees and/or offices. These exemplars should serve as beacons of best practice at a later
stage.
3. Outline Business Case
SharePoint has been a major investment and, in order to see a return on that investment, some
stimulation of its use and the level of expertise available across the University is needed.
Before SharePoint reaches a self supporting level (or adequately supported by local unit
ITSS) some expertise must be generated regarding design, but also in how clients access the
service.
SharePoint Best Practices (Phase 1) Project
SharePoint Best Practices
(Phase 1) Project
Page 2 of 9
Project Brief
03/01/2013 14:16
Currently SharePoint is able to automate highly bureaucratic and time consuming business
processes that are repeated around the University. It will not, however, be employed for these
purposes until more people engage with it and achieve a level of competence in other areas,
such as simple document storage. This project needs to build exemplars and how-to
documentation, given the experience of solving some high profile committees’ and offices’
needs. This, in turn, should increase expert levels across the University and uptake of these
business process opportunities.
4. Intended time scale
June 2012 May 2013.
5. Objectives, Deliverables and Requirements
5.1. Project Objectives
Engage with a major committee and office (such as a divisional office) in order to
provide the expertise and research in order to address their end-to-end SharePoint
needs (from site design to issues such as printing, document distribution and preferred
client access, including mobile devices, iPads etc.)
Improve the SharePoint sites for the above two sets of users to increase popularity
and engagement in those sites
Interact with the core user base of the above two situations in order to troubleshoot
and improve the general quality of interaction with SharePoint; this includes
assistance with client software and hardware
Produce best practice documentation, exemplar sites/lists/libraries and how-to
documentation in order for these to become beacons of best practice
Look into the specific needs of large volumes of documentation for meetings (e.g.
single paginated PDFs of many documents) and attempt to meet these needs within
the lifetime of this project
Seek official recognition from representatives from these two groups of users that the
service is able to meet the functionality expected by them and meets their needs in
terms of ease of use
Investigate specific areas of functionality, which are known to be needed, such as
providing users easy look-ups to show the different committees (and sites) of which
they are members
5.2. Project Deliverables
Business processes captured and delivered via SharePoint for Council Secretariat.
1
Business processes capturing and delivered via SharePoint for Social Sciences
Divisional Office
2
Best practice documentation and two beacon site exemplars
A set of recommendations regarding favoured software and ways of operating with
regard to mobile devices such as iPads and Android tablets (N.B. These will be
point-in-time recommendations as to demonstrated solution working adequately
within the time scale of this project)
1
The number of business processes captured (and which they are) is to be defined within the
project.
2
Ditto the above note.
SharePoint Best Practices (Phase 1) Project
SharePoint Best Practices
(Phase 1) Project
Page 3 of 9
Project Brief
03/01/2013 14:16
At least one solution addressing the specific challenges of large volumes of
documentation for meetings
Plans or actual implemented solutions regarding specific areas of functionality
o e.g., providing users easy look-ups to show the different committees (and
sites) of which they are members
o e.g. Collation and PDF production of documents for meetings
Publicity of new materials and exemplars
Statement that the software is, in principle, considered fit for purpose for the two
groups selected for enhanced support
Statement that the software meets the needs of the two groups in terms of ease of use
Statement of recommended support model, following consultation with users from
Council Secretariat and Social Sciences Divisional Office
5.3. Requirements
This project has no formal requirements gathering stage. Both the major groups will be
engaged in two phases; initially to establish 3-4 requirements or initiatives and later, to reflect
on these and to raise further requirements for work or development.
6. Stakeholder and/or User Groups
Our intention is to use the SharePoint Nexus User Group and the Groupware Programme
Development Panel, as well as the Project Board as general stakeholder groups. The actual
stakeholders will comprise the members of the Council Secretariat and Social Sciences
Divisional office, and informal liaison with members of these groups will be continuous, and
formal liaison is anticipated to occur every two months.
7. People, team and process
7.1. The Project Sponsor
Michael Fraser is the Project Sponsor
7.2. Project Management
7.2.1. The Project Manager
Mark Norman is Project Manager with supporting co-ordination work from Daryl Theobalds.
7.2.2. The Project Board
The Project Board is currently being assembled. The expectation is that the board will meet
three times during the lifetime of this project. It will be chaired by Michael Fraser.
7.3. The Project Team
The Project Team is the group of individuals involved in the major work of the project. It may
or may not include the Project Manager.
Mark Norman, project manager, 0.2 FTE
Daryl Theobalds, systems administrator, user liaison, task co-ordinator, 0.5 FTE
Rob Eadie, user liaison, business analyst, 0.4 FTE
SharePoint Best Practices (Phase 1) Project
SharePoint Best Practices
(Phase 1) Project
Page 4 of 9
Project Brief
03/01/2013 14:16
We have some funds to temporarily co-opt expertise into the team as needed.
7.4. Constraints
General constraints include:
Desktop support being provided from a variety of places. We will, occasionally, need
desktop support to re-configure a desktop where administration rights are required.
o However, part of the rationale of this project is for the Project Team to give
direct support, which includes updating the desktop support teams of the
users’ requirements
Urgent service work within the Nexus Team can occasionally affect scheduling (see
Risks)
Direct support from the Project Team to the users in the project may be unavailable
on some days (due to the part-time nature of people on this project)
Limitations of third-party tools: for some purposes this will be limited to what the
market has available
7.5. Dependencies on other services
See note above regarding desktop support (delivered mostly to our users via the ICT-
ST and BSP)
Occasionally we have a dependence on the OUCS web team in order to assist with
documentation and CSS (screen layout etc.). The team is not always available.
8. Risks
8.1. Risks to the project
Possible risk Likelihood Severity
Risk factor
(LxS)
1. Staff in units identified for engagement in this
project are too busy/preoccupied at critical stages
2 2
4
Risk: Project stalls due to lack of progress and iteration between the stakeholders and project
team.
Mitigation: Frequent communications are needed to keep interest high in all of the
participants. We will try to sustain frequent, short meetings, between the team and individual
stakeholders rather than leave extended periods between meetings. A monthly update
should be sent to stakeholders to maintain interest.
2. A better tool than SharePoint is clearly available
for the tasks identified
1 3
3
3. Members of stakeholder group change (e.g. due
to work pressures, change of roles) during project.
3 1
3
4. Difficulty in scheduling meetings.
3 2
6
Risk: Time.
Mitigation: Schedule all future meetings at first stakeholder meeting. Amend this schedule
when necessary.
5. Any custom development performed during the
project is difficult to maintain thereafter
2 3
4
SharePoint Best Practices (Phase 1) Project
SharePoint Best Practices
(Phase 1) Project
Page 5 of 9
Project Brief
03/01/2013 14:16
Possible risk Likelihood Severity
Risk factor
(LxS)
Risk: Project benefits cannot be sustained.
Mitigation: A relatively small amount of custom development (outside of the functionality
already provided in SharePoint) is likely to be undertaken. Also, scope exists within our
‘Development budget’ to develop in-house or to obtain external expertise. We have budgeted
for training in order to train internal staff to support any new code/configuration.
6. Ongoing expert support is absent after a period of
enhanced engagement
3 2
6
Risk: Project benefits cannot be sustained.
Mitigation: The recurrent budget for SharePoint is not sufficient to cover the close
engagement that this project gives. Therefore, the project has time allocated for an exit
strategy. Also, one implicit aim of the project is to raise the general expertise with
SharePoint, which mitigates this risk.
7. Dependency on desktop support causes a delay in
delivering functionality to users
2 2
4
Risk: Project delay and stakeholder frustration
Mitigation: This is a threat that has been considered deeply, and is a motivation behind the
project. If/when the first set of issues comes up that requires desktop changes, we will
schedule a meeting with the local IT Support in order to involve them. It is likely that many
desktop changes can be made without the direct input of local IT Support, but we need to be
proactive in engaging these people.
8. PDF conversion/compiling functionality benefits
cannot be justified by costs
3 3
9
Risk: There is a chance that the numbers of users benefitting from the sophisticated features
of PDF conversion and large document compilation will be so low as to merit a non-
SharePoint solution for this functionality (i.e. a desktop conversion using stand-alone PDF
software).
Mitigation: We should either seek more funds so that this functionality is available in
SharePoint ‘just one click away or document the recipe for doing this with SharePoint within
the SharePoint support documentation
9. Emailing SharePoint groups functionality problem
3 2
6
Risk: One previously considered quick win was to enable those who can managed
SharePoint groups to be able to have them as emailable groups. This is something we have
been asked within and without the project. There may be a bug as this functionality failed to
work in December.
Mitigation: There are some notes on forums showing that others have had similar problems
but their work arounds do not seem to work for us. We may open a ticket with the Education
Support Centre to get their and (possibly) Microsoft’s recommendation.
8.2. Risks to the organisation, department, team etc.
The main risk to the department (OUCS/IT Services) of this project not being undertaken, or
performing badly, is that the value of SharePoint to the University will not be fully realised
until a future date. There is also a risk that SharePoint could be perceived as an unnecessary
overhead if the engagement level is not high enough.
SharePoint Best Practices (Phase 1) Project
SharePoint Best Practices
(Phase 1) Project
Page 6 of 9
Project Brief
03/01/2013 14:16
9. Budget
The budget for this project has been approved and, initially broken down as follows.
However, budget lines for Client Software specialist and ‘Development budget’ may be used
differently as opportunities arise.
Cost/resource FTE Grade Duration
(months)
Cost to
project
Notes
Sysadmin backfill 0.25 7 12 £ 10,440 To backfill a Grade 8 systems
administrator (L2 support
duties)
User liaison
specialist
1 8 12 £ 50,023 Requirements gathering but
excellent SharePoint
expertise
Client software
specialist
1 7 2 £6,960 Research into client software
and mobile hardware use
Project
management
0.2 9 12 £ 12,033
Development
budget
£ 16,000 (either outsourced primary
development, but training an
internal individual, or one or
more members of University
development staff)
Training budget £ 3,000 Whatever technical advances
are made or developed, they
must be supported in-house
in the future.
Total
£ 98,456
10. Basic plan with time lines
Work package
2012
Jun July Aug Sept Oct Nov Dec
2013
Jan Feb Mar Apr May
1 Project Management
2 Stakeholder liaison
3 Client issues focus
4 Site (re-)development
5 How to documentation
6 Beacon site reprod.
7 3
rd
-party tool deploymt
8 Dev of new tools
9 Final stkholder feedbk
10 Exit strat/suppt model
11 Final doc amendmts
SharePoint Best Practices (Phase 1) Project
SharePoint Best Practices
(Phase 1) Project
Page 7 of 9
Project Brief
03/01/2013 14:16
10.1. Milestone summary table
Deliverable / Milestone: Due Date:
Revised
Date:
% Complete
Completed
Date
Project kick off meeting Jun 2012 100
June 2012
Kick off meeting with SocSciDO Jun 2012 100
June 2012
Kick off meeting with
PRAS/CoSec
Jul 2012 100
July 2012
Project plan first iteration Jul 2012 100
July 2012
Key areas for development
selected for SocSciDO (round1)
Jun 2012 100
July 2012
Business process analysis for
key practices at SocSciDO (r1)
Jul 2012 100
July 2012
Demonstrate SharePoint
Temporary Account
Functionality with Esther Byrom
(SocSciDO)
Jul 2012 100
July 2012
Key areas for development
selected for PRAS/CoSec
(round1)
Aug 2012 Oct 2012 100
Nov 2012
Iteration1: Finding people with
similar interests (SocSciDO)
July 2012 Aug 2012 100
Aug 2012
3
Iteration1: Suggested site
improvement/permissions
management of personnel
records (SocSciDO)
Aug 2012 100
Aug 2012
Iteration1: Central calendar and
poss bulletins for leave, WfH,
important absence etc.
(SocSciDO)
4
Aug 2012 Sept 2012 100
Sept 2012
Reproduce Soc Sci Section 3
Academic Appointments within
their HoD handbook, in
SharePoint
Aug 2012 Stalled 70
5
Business process analysis for
key practices at PRAS/CoSec
(r1)
Sept 2012
6
50
Gradual/
constant
Iteration1: Demonstrator of
guidance Information supplied
to departments (SocSciDO)
Sept 2012 Stalled 80
7
3
Decided that WebLearn may be the better vehicle
4
N.B. The scope of this task has been limited as the requestor (Miia Laurikainen) has
simplified the requirements
5
Slow progress: The ability to convert Word Docs to HTML went live in early October (as a
service). Waiting for content from SocSciDO.
6
Instead of being carried out in wide iterations, this has been a gradual process based upon
regular meetings. It has been focussed on Committee Site design and PDF conversion thus
far.
SharePoint Best Practices (Phase 1) Project
SharePoint Best Practices
(Phase 1) Project
Page 8 of 9
Project Brief
03/01/2013 14:16
Deliverable / Milestone: Due Date:
Revised
Date:
% Complete
Completed
Date
Review use of Smartphones/
tablets by SocSciDO
Sept 2012 100
8
Sept 2012
Iteration1: Show available
functionality to ‘find sites you
participate in’ (SocSciDO)
Sept 2012 Oct 2012 90
Oct 2012
Investigate Cambridge Univ.
use of or interest in committee
sites and PDF conversion
Sept 2012 Jan 2013
9
40
Team Calendar accessed via
SharePoint for SocSciDO
Oct 2012 100
Oct 2012
PDF creation functionality (to
meet CoSec req.mts)
investigated online+off line
Oct 2012 Nov 2012 100
Dec 2012
Social Sciences Site Collection
restructured
Oct 2012 100
Oct 2012
Committee site template
restructured and simplified for
CoSec/PRAS
Oct 2012 Jan 2013 90
10
Review, ending in
recommendations of software
(or browser) for mobile devices
and SharePoint
Oct 2012 Jan 2013 80
11
Iteration2: Suggested site
improvement/permissions
management of personnel
records (SocSciDO) to possibly
include workflows
User feedback re Ref 2014 Site
(SocSciDO)
12
Nov 2012 Feb 2013 40
13
General plan for Council
committee (set of) sites
Nov 2012 Feb 2013 40
Member(s) of Council
Secretariat appointed to
manage permissions to CoSec
(etc.) sites
Nov 2012 Stalled 20
7
This activity is now focussed on purchasing and deploying Alert Plus to ‘push’ information to
recipients. Alert Plus is purchased but user documentation and SocSciDO content is
outstanding.
8
Divisional office, not much information but we now have a list of 6 members of the division
(outside the SocSciDO) hence the later SharePoint mobile device milestone addition.
9
After some difficulties getting a response from the SharePoint contact at Cambridge, now
have 2 interested parties there. Likely to have a joint project meeting in January or Feb.
10
Good recent progress but awaiting feedback from CoSec (PRAC secretary’s evaluation).
11
We very nearly have the knowledge required, but need to write up a
report/recommendation.
12
The site is finished but we would like (end) user comments.
13
Probably trivial work to complete, but we have been asked to hold off from contacting
participants until January.
SharePoint Best Practices (Phase 1) Project
SharePoint Best Practices
(Phase 1) Project
Page 9 of 9
Project Brief
03/01/2013 14:16
Deliverable / Milestone: Due Date:
Revised
Date:
% Complete
Completed
Date
Emailing SharePoint groups
functionality (SocSciDO and
CoSec)
Nov 2012 Feb 2013
14
60
Develop exemplar (for support
site) of web part to list relevant
sites based on the group/role of
the viewer
Feb 2012 50
Document exemplar
functionality of Team Calendar
accessed via SharePoint for
SocSciDO
Feb 2012
Social Sciences Site Collection
final structure (ongoing project
work)
May 2013 40
Exit report recommendations for
SharePoint expertise on the ITS
Help Desk
May 2013
11. Acronyms and abbreviations
Abbreviations used throughout this document are summarised below.
CoSec Council Secretariat
ITSS (Local) IT Support Staff
PRAS Planning and Resource Allocation Section
SocSciDO Social Sciences Divisional Office
Document History
Version
Date
Comments
0.7 13 July 2012 Project colleagues agree that this is a good starting
point.
1.0 22 Aug 2012 Interim version on the way to being the August final
version.
2.0 28 Sept 2012 Version for end Sept
2.1 26 October 2012 Version for end October 2012
3.0 4 December 2012 For November 2012 (but to include 3 Dec)
4.0 3 January 2013 For December 2012 monthly report.
14
This deliverable put back due to deployment problems: see risk 9.
Login to HandyPDF
Tips: Editig or filling the file you need via PC is much more easier!
By logging in, you indicate that you have read and agree our Terms and Privacy Policy.