...
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 Has Might have an (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 (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) |
...
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).