A colleague asks:
hoping you can provide your perspective on “grouping changes”. That is, rules or guidance on when it is appropriate to lump several small changes into one change control.
There are lots of reason’s to want to group changes into one change control – ease of implementation, a perception of “reducing work” or just convenience. I apply three general rules for when this is a good idea:
Implementation
All changes should have the same “Change in Use” and “Regulatory Approval”
I talked about this is in “Changes become effective“:
| Tell and Do | Do and Tell | Do and Report | |
| Change in use | After regulatory approval. When change is introduced to the ‘floor’ | When change is introduced to the ‘floor’ | When change is introduced to the ‘floor’ |
| Regulatory approval | Upon approvals | After use, before send to market | Upon reporting frequency (annual, within 6 months, within 1 year) |
| Sent to market | After regulatory approval and change in use | After regulatory approval and change in use | After change in use |
Ideally chose all changes that are “Do and Tell” or “Do and report”, I strongly do not recommend blending “Tell and Do,” there are just so many complexities here and it can lead to a constant revision of change controls and even increase risk of inadvertently sending products to the market.
Release of Product
All changes bundled together need to be releasable at the same time. Look at PQ/PV requirements and other testing that can be different and keep them in segregated change controls. Putting product on stability (or even needing stability data) is another good reason to separate changes.
Similarly, keep changes that have different internal product segregation requirements unbundled.
Concreteness of Work Bundles
The best reason to bundle changes is that they involve changing the same things: same documents, same automation, same piece of equipment. Once the bundling starts increasing scope of the change, it is time to have separate change controls.
If bundling changes starts changing your project management triangle (resources, time, scope) then do a deep evaluation. You probably have separate change controls, even if they are under the same project.
Evaluate effectiveness reviews. Chances are totally separate effectiveness reviews for same impacted area are really separate changes.
What about risks?
You might notice that I do not call out risks as one of the criteria. Risks drive mitigations, which drive impact to the three criteria I gave. If a high risk’s mitigation does not trigger one of these criteria, it is usually not a problem to group the changes together. Though I’d pause and consider why the addition of a change that adds high risks does not drive mitigations that change the amount of work I am doing and ensure that is appropriately documented.
Conclusion
Sometimes bundling changes make sense. other times you will curse the day you agreed to bundle. I find these three rules provide a framework for making the decision.
Investigations of a Dog 
3 thoughts on “Group change controls”