Product Quality Through Change Management (1999)

The term "validated" here typically refers to the GAMP5 "V model" of building software releases where there is a direct correlation between the various stages of build and release to some documentation (requirement, specification, design, install procedure, and test procedure).

By far, this was probably the highest quality software I've built in my career. Given the scope of what we were delivering for large enterprise pharma customers, our defect rate was surprisingly low. This is a system that's used every day in tens of thousands of clinical trial sites around the world.

An interesting aspect of change management in GxP validated software is that the process starts with identifying the documents that are going to be affected. In other words, when we start a release, we would work with the sponsor (like a Merck or Pfizer) and the teams would make a "change request" document that inventoried which documentation would be affected. For example: which original requirements are to be updated, which specifications are changed, which installation procedures need to be updated, which test scripts are affected, etc.

This process is incredibly onerous and time consuming, but also ensures that not only is the output very high quality and low defect, but also well documented. I often thought that this is probably one area that is ripe for disruption, especially with LLMs. (It is also one of the reasons why it is rare to see startups building software that supports GxP processes).

(For most teams, I think that Basecamp's "Shape Up" [0] is probably the most balanced change management process that yields acceptable speed, minimal wasted effort, while still allowing space for high quality software to be built.)

When I think about this period of my career, I often think about an article They Write the Right Stuff [1] on how NASA's tolerances are perhaps at the extreme end of human perfection in software. A great read!

[0] https://basecamp.com/shapeup

[1] https://www.fastcompany.com/28121/they-write-right-stuff

Understanding what is valuable is the key to the whole process. It's achieved by "requirements management" [CMMI1.02, p86]

Uh uh I LOVE when "the key to the whole process" of figuring out what "valuable" is, is a quick, off-hand reference to another doc. Since it's literally the key to the success of this whole operation let's visit that CMMI1.02, page 86 real quick to learn "requirements management":

The term "requirements" refers to product and product component requirements that are received by or generated by the project, including those requirements levied on the project by the organization. The requirements are both technical and non-technical. The practices in the Requirements Management process area are the source for the current, approved set of requirements upon which all of the practices in the other project process areas act. The project takes appropriate steps to ensure that the agreed-upon set of requirements is managed to support the planning and execution needs of the project. When a project receives requirements from an approved requirements provider, the requirements are reviewed with the requirements provider to resolve issues and prevent misunderstanding before the requirements are incorporated into the project's plans. After agreement between the requirements provider and the requirements receiver, commitment to the requirements is obtained from the project participants who have to do project activities and implement the requirements. The project manages changes to the requirements as they evolve during the project and identifies any inconsistencies that occur between the plans and work products and the requirements. Part of the management of requirements is to capture requirements changes and rationale and maintain bi-directional traceability among source requirements and all product and product component requirements. CMMI-SE/SW, v1.02 Staged Representation Maturity Level: 2, Requirements Management 87 This process area is tightly coupled with the Requirements Development and the Technical Solution process areas, which address the processes for transforming stakeholder needs into product requirements and deciding how to allocate or distribute requirements among the product components. The practices in the Requirements Management process area should be done concurrently with the practices in the Requirements Development process area and the Technical Solution process area when those practices are implemented.

That's for point 1 of this simple 3 step process. I bet steps 2-3 are just as straight forward.