rtments & Sc a p
People are busy & may not be able to contribute as much and as often as we would like
??
words
?
Developers duct O n o r P er
are production ready
w
duct O n Pro er w
Minimum Viable Product
rs
Unpredicted events ‘bump’ developers off the project
duct O n o r P er
Development versions el o Dev
Change is hard - even when it is change for the better. Keeping users informed and in the loop is very important
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
pe
Production version rs
De ve
l o p ers
the Programmes Plant
W hat we did
What we did
De
Lessons Learned
s
Product Owner
Project Manager
w
What we did
Steering Group
el o Dev
Lessons Learned
Implementation Group
pe
RISKS
Pub lish
Stud e
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.
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
Data System nt
and report on how we were doing
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)
anagemen M nt
ols o h
and recruited key people to advise, liaise and generally
RISKS
Enrolm e
Lessons Learned
ance r u s As
RISKS
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
one authoratative source of data.
Office ing
Qual ity
What we did
which course data was created, maintained, processed or consumed. Knowledge of current systems was
Balancing the need to include all stakeholders against the need to keep working groups to a manageable size. Requirements for attendance tailored to agendas.
Existing methods for collecting data to feed the online
ces ervi tS
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
RISKS
the
What we did
W
D
TARTE S E W E R HE
Revised content, design & functionality of online prospectus based on user needs
I
R
C X
HEAR KIS c.uk a . s t c e prosp etc.......
Lessons Learned
Our Goals Linking modules to Programmes on the course pages was key to improving
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/