Assuming that we want to use (a somewhat) Agile approach to delivering scope of WIP II we need to decide on where we begin the iterative (two week?) cycle of analysis, design, development, testing and deployment. Deciding where to begin is important and will differ according to the criteria used. So, the following table is designed to gather a range of perspectives for each HLS being the starting point and then to provide input for a PMO decision.
Start with | Reasons for | Reasons against |
|---|---|---|
| Student information | Delivers benefit to key user group Builds on the existing student hubs Few internal dependencies Could deliver some early benefits | Low recruitment benefit No clear product owner Has manageable external dependency on Learning Success Large and may be difficult to break in to smaller releases |
| Course and Subject Information | Meeting stakeholder (i.e. PMO) expectations User numbers (GA) Already partially done in WIP I Valuable for recruitment | Requires decision on purpose of F&S sites (assumption that it is desirable to move this information out of departmental structures) Requires (simple) decision on the purpose of PG hub Require a reference group to provide product owner input Has manageable external dependency on CIP and COO Large and may be difficult to break in to smaller releases
|
| Postgraduate information | Large room for improvement Key focus group Few internal dependencies No external dependencies Could deliver some early benefits | May be difficult to identify a product owner |
Research Centres, Institutes and Chairs | No internal dependencies Could deliver some early benefits
| Fringe to WIP II purpose Low visitor numbers |
| Faculty and School Information | Central to WIP II purpose Meeting stakeholder (i.e. PMO) expectations Frequently clicked links Easy to break into small releases, delivering benefit early and often | Large, as in many faculties and schools Complex, as in the most internal dependencies Some very large faculties (i.e. many schools) |
Tash Davey (Unlicensed) (in discussion with Andrew Bredenkamp and myself) identified that we could use the intersection of a "horizontal slice" by faculty/school and "vertical slice" by course/subject/programme to identify a starting point. For example, we could take the School of History, Philosophy, Political Science and International Relations and work with them on subjects and courses, then move up to the Faculty of Humanities and Social Sciences and work with them on programmes.
Extending this further, some early work on the content strategy and high level IA for both the Postgraduate Information and and Research Centres, Institutes and Chairs areas would allow us to tag or ring fence content on this school and the associated faculty site that would later be moved
We would then take another school in the same faculty and address their subjects and courses.
We then have the choice between doing the next faculty or doing the Postgraduate Information and and Research Centres, Institutes and Chairs for the FHSS.
A few things to be aware of:
- Consider complexity early on: To reduce risk of rework if we build templates for the simplest and find they do not grow/scale. This does not mean we have to tackle all the complex areas early but we might do some prototyping or proof of concept. Audit findings would be useful here, so Anne Nelson (Unlicensed) please join the discussion. For example, I selected HPPI because they have an institute.
- Start with a good school: Meaning that they have a good handle on their content (especially subjects and courses) and are willing to work with us.
This approach should meet with stakeholder approval because it aligns with the recruitment imperative. It also allows us to release early and often (with a 1 October deadline bringing focus on how much we can achieve).