triangle-man
commented
5 years ago Background
I think this document should have an introductory section on background context. It should be written for someone who has had no discussion on this issue at all and may not even know anything about REG. It should contain as much detail as possible that might be relevant.
For example, something like the following:
Background [EXAMPLE]
The Research Engineering Group (the Group, or REG) is a team within the Alan Turing Institute of about 20 full-time data scientists and software engineers with experience of academia. The bulk of the work of this team (perhaps 70% of the average time allocation over a year [CHECK THIS FIGURE WITH MARTIN]) consists of projects: work to support a specific, time-limited, goal-directed activity at the Turing, usually in the service of a particular Programme, or partner, or researcher. The nature of a project is a little blurry and might also include things like the present project, the one whose backbrief this is, which happens to be to improve working practices. The remainder of the Group's time is spend on, inter alia, personal development (such as training or attending conferences), ad hoc support to Turing researchers, support to particular Programmes, and general corporate administration and management. The main characteristics of a "project" from one perspective is that it is something to which the Group allocates its time so that its costs might be recovered from a funding source. (That is to say, we "bill" our "clients".)
In order to function, the Group therefore needs to engage in planning and monitoring of its members' time allocation. It needs forward planning to ensure that it does not agree to more projects than it has resource for (or conversely that it has "too little to do" and cannot recover costs) and that individuals find themselves on appropriate projects.
It needs to monitor actual activity to ....
The Group's approach to planning and monitoring has evolved as it has growing. Originally, it ....; then when it reached about 10 people, it use a Planning Board, which worked as follows ...
At around 20 people the Board became too large and it swiched to an ad hoc spreadsheet to do the following...
However, even that has become unmanagable.
Thus, the Group has recently sought to put in place a "scalable" solution to planning and monitoring, one that will suit its needs up to, a maximum size of, say, 50 (but possibly arbitrarily large).
The current approach is the use of two interconnected SAAS systems called Harvest and Forecast. These work as follows ...
Overall
My main comment is that (in my view) a backbrief must be opinionated. It is the author's view of what the problem is and how to solve it. The idea is to check with the client that this is what they expect, but definitely should not be driven by users saying what they want. (!)
The problem with asking users what their needs are is that users don't know (a) what their needs are (they know their wants); (b) how hard anything is. Also (c) if you have N users you will have N + 1 contradictory set of needs.
So a backbrief should attempt to translate what users say they want into what the author believes.