While waiting for a decision on the delivery approach (and maybe to inform this, if not yet decided) I have started mapping out the chunks of work, key questions and noting critical path (or high importance areas). I suggest that we identify actions/tasks based on the content of this page but will not do so until I have discussed this with Chrissi (and maybe she is better placed to do so anyway).
Faculty and School (that is not CSP)
Amusing that CSP proceeds as core data, this component of the (current) Faculty and School HLS area can be though of as only loosely coupled to the rest of the F&S work, which in turn can be though of as comprising activity in the following areas:
- High level IA and site structure: Changing this is always easier before a major project rather than during or after. As such we urgently need direction or answers in this area. I think it sits with Nathan (and 'Tash for a few more days) to advance but I can not see a delivery date for a new IA. I am encouraged by the feedback of workshop participants with the direction of "audiences and their needs first", a pillar of how we think about the website and how we approach our work (but the devil might yet be in the detail). This is now on the critical path and maybe even a blocker, in that the following bullets are all reliant an a decision at this higher level.
- Lower level site structure and content plans: Well advanced by Anne, but potentially requiring rework depending on the high level IA work. Needs socialising with stakeholders, as it is currently a straw man or proposal. Workshops to date indicate an acceptance from half the faculties and a willingness to discuss from the others (but please do not mistake this for an agreement or willingness to implement). I suggest we have follow-up conversations with any faculty that does not seem onside with the "folding of school sites into the faculty site", meaning VBS and Science so far.
- Navigation: From simple (page sections, hyper-links, etc) to more complex (contextual search widgets). Can we identify some more complex ones early, with sufficient knowledge of their importance that work can start on them now?
- Functionality: I am thinking about this category (as tagged by Sam in Reframer for workshop observations) in terms of:
- Engagement: The more simple, one-way functionality that allows the user to do stuff he/she wants with our content. Client-side, not restricted (much) by Squiz, generic/modular (in that it could be placed on any/all pages as required). Examples include share, print, book mark, download, etc. Can we identify some more complex ones early, with sufficient knowledge of their importance that work can start on them now?; and
- Online Services: More complex, two-way, transaction-based functionality that allows the University to deliver a service to an audience online. Examples include buy, ask a question, subscribe, rate, register, change my details, etc. Can we identify some more complex ones early, with sufficient knowledge of their importance that work can start on them now?
We expect to start working intensively with FHSS on content but these may not require workshops (Anne and Sam to decide). However, in working on the first faculty (no matter who it is) there will be specific functionality required that is also required for (many/all faculty sites. Advancing this with only one faculty involved is short-sited (the requirements are likely to be incomplete and the solution sub-optimal and with less than ideal buy-in). Involving all faculties has challenges of the number of participants and can partly reduce the risk of disengagement of faculties we must leave waiting for many months until we can work with them on a new site.
Sam, Anne and I realised yesterday that the next round of "workshops" could well be functional requirements for a specific feature set (or set of related widgets). We could define an epic (e.g. events, course finder, change my details) and gather a small group of interested people (a core from FHSS and a smattering of other interested/knowledgeable representatives from some/all other faculties). This group could meet a few times, probably quite frequently, over a short period of time, until at least the stories are written, but ideally until the widget is built. As a group they would have the role of "product owner" for the feature set in scope.
After discussing with Andrew and Nathan I would modify this approach to the following steps:
- Identify the functionality set areas (maybe these are the epics) based on the information we have.
- Efficiently determine if we believe they are in the "Must" or "Should" category.
- Use team expertise to identify which ones we need stakeholder input on and which we can do without other parties being involved.
- Establish a "product owner group" for one functionality set.
- Work closely together for a short period of time to determine the requirements, and ideally demonstrate a solution.
- Any solution must be a reusable block/tool/widget that can be deployed all over the site (beyond even a faculty site). This point applies even back at the first point when we identify the functionality set.
CSP
Courses
- Let COO run its course (pun intended). I have concerns over the delivery date (when each story gets done) and the prioritisation process (with David and Angela) from a WIP perspective in as much as we need to know what COO will give us, so we can either assume it will be there in time, or deliver it in WIP if we really need it.
- Does WIP want to deliver some of the COO stories (earlier, as WIP)?
- WIP has some additional course requirements in the backlog and might yet draft some more (as our understanding grows).
Subjects and Area of Study
Area of Study
- The proposed term to cover a cluster of related/similar subjects (can also be though of as "topic" or "area of interest/enquiry')
- Would be a starting point for a future student who is exploring what to study
- Would map to subjects, programmes and maybe even courses (issues here listed below)
- All work to identify these (including if they will work) is on the critical path.