You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Revision of text on Quality Management in Overarching Processes (from previous call)
Based on the discussion in a previous call regarding where "design of evaluation" fits into GSBPM (or GAMSO), the conclusion is that it fits into places like GAMSO Quality Management (where there’s a quality framework mentioned), but also in GSBPM overarching processes, which clearly signpost the links to GAMSO and the Evaluate phase of GSBPM.
However, when examining the description of the overarching processes, Juan felt there wasn’t a clear link between the lifecycle diagram and the rest of GSBPM, and Juan prepared some extra text in paragraph 117, which he outlined within the call. He outlined the 4 stages in the cycle diagram, and said that:
At the beginning of the production process we need to design a new quality framework or utilitse an existing one.
During the “Run” stage we need to collect all the information during the execution of processes.
During Evaluate, need to evaluate products and processes, but also summarize and take decisions about improvements before commencing the next cycle.
Some minor enhancements to that proposed text were made during the call.
Design of Security proposal (follow-up)
Following previous discussions about “Design of Security”, Chris presented a minor adjustment to the introductory text of the Design phase to accommodate that point (mirroring the approach taken to dealing with security in the Build phase).
Security isn’t really something you design, but rather a requirement to bear in mind when designing, and is more of a capability than an activity, so there isn’t a specific subprocess it applies to, although there may be circumstances where there is greater risk (certain types of data or operations that are considered more risky).
The group agreed with the proposed minimal text change in the Design phase introduction.
Non-linearity
Iterative loops are mentioned in part II of the document in the subsection on “Understanding the GSBPM”.
Edgardo said that it’s difficult to know in advance where the iterations will be, as it depends on the approach taken by those who follow GSBPM.
InKyung suggested showing a figure to emphasize the point about non-linearity, and the group agreed to this.
Boundary between Design and Build phases (and Overarching processes) (previously discussed in Build issues)
Consistent with the discussion of this feedback in the Build issues, it was decided not to change GSBPM in the way suggested in those comments.
Design vs Overarching processes
The suggestion to incorporate the “design of statistical areas” that cover multiple statistical programmes (presumably such as “social statistics” rather than “crime survey”) was felt to be outside of GSBPM, and so it was decided not to modify GSBPM on the basis of this piece of feedback.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Revision of text on Quality Management in Overarching Processes (from previous call)
Based on the discussion in a previous call regarding where "design of evaluation" fits into GSBPM (or GAMSO), the conclusion is that it fits into places like GAMSO Quality Management (where there’s a quality framework mentioned), but also in GSBPM overarching processes, which clearly signpost the links to GAMSO and the Evaluate phase of GSBPM.
However, when examining the description of the overarching processes, Juan felt there wasn’t a clear link between the lifecycle diagram and the rest of GSBPM, and Juan prepared some extra text in paragraph 117, which he outlined within the call. He outlined the 4 stages in the cycle diagram, and said that:
Some minor enhancements to that proposed text were made during the call.
Design of Security proposal (follow-up)
Following previous discussions about “Design of Security”, Chris presented a minor adjustment to the introductory text of the Design phase to accommodate that point (mirroring the approach taken to dealing with security in the Build phase).
Security isn’t really something you design, but rather a requirement to bear in mind when designing, and is more of a capability than an activity, so there isn’t a specific subprocess it applies to, although there may be circumstances where there is greater risk (certain types of data or operations that are considered more risky).
The group agreed with the proposed minimal text change in the Design phase introduction.
Non-linearity
Iterative loops are mentioned in part II of the document in the subsection on “Understanding the GSBPM”.
Edgardo said that it’s difficult to know in advance where the iterations will be, as it depends on the approach taken by those who follow GSBPM.
InKyung suggested showing a figure to emphasize the point about non-linearity, and the group agreed to this.
Boundary between Design and Build phases (and Overarching processes) (previously discussed in Build issues)
Consistent with the discussion of this feedback in the Build issues, it was decided not to change GSBPM in the way suggested in those comments.
Design vs Overarching processes
The suggestion to incorporate the “design of statistical areas” that cover multiple statistical programmes (presumably such as “social statistics” rather than “crime survey”) was felt to be outside of GSBPM, and so it was decided not to modify GSBPM on the basis of this piece of feedback.
Beta Was this translation helpful? Give feedback.
All reactions