Skip to end of metadata
Go to start of metadata


The Specify Needs phase doesn't explicitly refer to proposing statistical solution options to addressing client needs, it just separately mentions various aspects of these solutions, probably because a survey solution is assumed. Some of the sub-processes also don't seem big enough to warrant being explicit at this level (e.g. identify concepts).  In the new ABS Business Architecture we have combined and re-focussed 1.1 - 1.5 into two sub-processes -  'Understand and confirm statistical needs' and 'Scope statistical solution' (scoping and preparing a high level solution design is effectively what a business area does to get approval to proceed with the project, and before the detailed design, build/assembly and implementation processes commence in earnest). To be in scope of the GSBPM any solutions prepared would need to result in the creation of data outputs.

Statistics New Zealand response to GSBPM v4.0

Responsiveness to indigenous peoples

Statistics New Zealand has moved a long way towards making the organisation’s commitment to responding to the information needs of the Māori people more visible in our documentation and in our work generally. In light of this, we have been considering whether it is worthwhile adding an explicit sub-process within the Specify Needs process to better highlight this need. Currently, activities associated with identifying and responding to the information needs of Māori would sit under each of the sub-processes within Specify Needs, but are nowhere referenced explicitly.

Meeting legislative requirements

Similarly, there may be legislative requirements that form part of the assessment of information needs. Examples relevant to Statistics New Zealand include preparing and submitting a Privacy Impact Assessment to New Zealand’s Privacy Commissioner when information about individuals is involved, and obtaining Ministerial approval for new statistical surveys commissioned by government departments (including Statistics New Zealand). At present, activities associated with meeting legislative requirements are implicit in one or more of the sub-processes within the Specify Needs process. It may be useful to have legislative requirements explicitly referenced as a sub-process in the Specify Needs process.








  • No labels


  1. I'm not sure that a change to the specify needs sub-processes are needed, but a few of the descriptions of the sub-processes may benefit from being clearer. For example, 1.3 Establish output objectives, the text doesn't seem to be aligned with the heading as well as it could be.

    In terms of the Stats NZ responses, perhaps responsiveness to indigenous peoples could be explicitly referenced under 1.1 Determine needs for information and 1.2 Consult and confirm needs, although I would generalize the language to be about specific communities of interest, perhaps using indigenous peoples as an example (or disabled people, as another possible example). I see legislative requirements falling under 1.5 Check data availability, in particular where it states about possible data sources "the conditions under which they would be available, including any restrictions on their use" and then, later, where it states "This sub-process also includes a more general assessment of the legal framework in which data would be collected and used, and may therefore identify proposals for changes to existing legislation or the introduction of a new legal framework."


  2. Discussion 15/10: Phase is missing broad level solution considerations, legislation and indigenous populations.

    Add higher level solution as part of business case text (look at 1.5 or 1.6). 1.5 is important for admin data - looking for where data is available. If GSBPM is not linear, then you can do design first.

    Rising level of importance or need to emphasise sub populations added in description

    Also adding legislation into text.