A proposal on where we start development

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 any Postgraduate hub at a banner level Require a reference group to provide product owner input Might have an (manageable) external dependency on 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 (in Business Justification Case) Low visitor numbers
Faculty and School Information	Central to WIP II purpose (in Business Justification Case) 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.

Based on this approach (or a similar one) we might be able to draft a project roadmap, a list of key features or scope areas sequenced (even with dates) on a timeline. This approach is a useful answer to the myth that in agile there is no long term planning. JIRA even provide a help article on this.

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