Implementation Group Steering Group
Product Owner
Project Manager People are busy & may not be able to contribute as much and as often as we would like
??
words
?
uct O d o ne Pr r
RISKS RISKS RISKS
w
pe
Production version rs
De ve
l o p ers
the Programmes Plant
What we did
w
uct O d o ne Pr r
Development versions
el o Dev
el o Dev
Change is hard - even when it is change for the better. Keeping users informed and in the loop is very important
Unpredicted events ‘bump’ developers off the project risking the project finishing before critical applications are production ready
duct O n o r P er
Minimum Viable Product
rs
Legacy systems could ‘feed’ into the new Programmes Plant but might soon be replaced and could present data transfer problems
Product Owner acts as primary liaison between developers and users, reviews all developments, prioritises user stories and product features
words
Developers
pe
Ensuring the product owner is supported by line manager and line manager is aware of the amount of time the product owner will need to give to the project
RISKS
Enrolm e
Lessons Learned
What we did Lessons Learned
Qual ity
ents & m t r Sc pa
Stud e
De
What we did
s l o ho
Developers assess requirements with Product Owner. Revisit and learn from previous attempts to improve systems. Evaluate: bespoke v third party solutions enhance existing systems v new build.
Avoiding scope creep whilst keeping all the stakeholders on board, interested and contributing (even though we may not solve their problems within the life of the project)
Data System nt
Lessons Learned
Pub lish
w
What we did
nce a r u s s A
Balancing the need to include all stakeholders against the need to keep working groups to a manageable size. Requirements for attendance tailored to agendas.
ageme n a M n t n
Office ing
There are a great number of people involved in the process of getting course data to the prospective student. There are no clear hierarchies or paths in the process and no single point of authority
Existing methods for collecting data to feed the online course pages, data returns, subject leaflets etc were not fit for purpose, prone to problems and reliant on a small number of dedicated staff. The University lacked one authoratative source of data. ces ervi tS
Stakeholders were identified representing all points at which course data was created, maintained, processed or consumed. Knowledge of current systems was shared and points of failure and conflict and duplication identified.
Set up the project administration. Appointed officers and recruited key people to advise, liaise and generally keep the project wheels turning, resolve conflicts and report on how we were doing
Lessons Learned
Investigate current sources of course data Where?, What? Who - owns? compiles? validates? administers? Weak points? Duplication? Anomalies? Inaccuracies?
Acknowledging errors with systems or systems ‘past sell-by dates’ whilst appreciating valuable contributions from staff - the need for diplomacy
RISKS
Developing a course data administration application and producing the XCRI-CAP open feed
RISKS
Kent XCRI Project What we did
W
the
s
D
R A TE T S E W E R E H
Revised content, design & functionality of online prospectus based on user needs
I
R
C X
HEAR KIS k u . c a . s t c e p s pro etc.......
Lessons Learned
Our Goals Linking modules to Programmes on the course pages was key to improving our on-line offer
Links:
audrey
http://blogs.kent.ac.uk/kent-xcri/ http://www.kent.ac.uk/is/projects/xcri/ https://github.com/unikent/programmes-plant
http://blogs.kent.ac.uk/webdev/