NCAS CMS Considerations (BNL Overview)

[bnlawrence]

This ticket is really a core dump of some initial thoughts about the existing code deck given we are considering whether or not we need a tool like this (or indeed, this particular tool). They are based on an initial conversation, and some very limited playing. If we take this forward, we'll likely close this ticket and replace it with other which represent more considered thinking (we may also update this ticket en route).

Some of these may actually be easily solved (or already solved) in the code-base, some may be more complex (or even show stoppers).

1. Our primary issue is not to use this for costing, for grants we will have costing carried out by university admin and often involve multiple staff each of which is on a different grade, and for core activities, we have a set budget - so in both cases what distinguishes a project is a budget, which is independent of any individual and/or salary grade. Some budgets change over time, some are fixed, even if costs change. There should be no dependency of a Project on any attribute of any staff member (or salary scale) - but we do have projects which run under different financial rules (of which more below). We are then interested in the projected and actual costs as a function of time as staff are assigned or report work on the project.

2. The financial year and increment year may differ from those hardcoded. We definitely need to report on financial years, but possibly two different financial years at the same time (when/if university and funder financial years differ).

3. We have projects for which the financial rules differ. There are easy ones, where we have different direct and indirect cost rules, but we have some where the overheads are a fixed value, independent of which staff member(s) is(are) working on the project - they are simply pro rata with FTE.

   • It would be good to have some which incur VAT (for service type projects), and some which don't (as work and customers vary and the VAT status does as well).

4. The entering of salary information needs to be simple. Could we have a spreadsheet upload for "new salary bands" which then get associated with a particular set of years (generally could imagine the end year always being infinitely far in the future, and then easily associate any individual with those bands? (I haven't spent enough time on this, so this thinking may be revised with more experience.)