Tag: document

Choose Your Font!

For a lot of reasons paper (and paper-on-glass) documents are with us for a long time. So it continually surprises me when I see documents in some basic, reduced readability font .

Even when we go to electronic systems that choice of font is going to be an important one. And it’s probably not the same font as what worked for you in a paper world.

And then there is all that training material and presentations (including conference material).

So spend some time and choose the fonts that works for you and your users. But please for goodness sake don’t default to a font because it is what you have always used.

I’m a huge fan of Roboto.

There was a nice writeup on fonts on SlideModel: 20 Best PowerPoint Fonts to Make Your Presentation Stand Out in 2023

The Program Level in the Document Hierarchy

A fairly traditional document hierarchy, in line with ISO 9001 and other standards looks like this:

Document hierarchy

This process tends to support best an approach where there is a policy that states requirements to do X, a procedure that gives the who, what, when of X, and work instructions that provide the how of X, which results in a lot of records providing X was done.

But life is complicated, and there are sets of activities that combine the Xs in a wide variety, and in complicated environments there may be multiple ways to bundle the Xs.

This is why I add a layer between policy and procedure, called the program, which is a mapping requirement that shows the various ways to interpret the requirements to specific needs.

Document hierarchy with Programs

The program document level shouldn’t be a stranger to those in the GMP world, ICH Q11 control strategy and the Annex 1 (draft) contamination control strategy are two good examples. What this document does is tie together processes and demonstrates the design that went into it.

The beauty of this document is that it helps translate down from the requirements (internal and external) to the process and procedures (including technology), how they interact, and how they are supported by technical assessments, risk management, and other control activities. Think of it as the design document and the connective tissue.