79. Paper Mill

The organization measures progress by the weight and number of documents produced to date.

A project is a voyage for understanding a problem well enough to be able to come up with a solution that fits a given set of constraints. During the voyage, various aspects of the growing understanding need to be communicated to a diverse set of stakeholders. And this understanding is usually communicated using a mixture of paper and electronic documents. The questions you need to ask in designing this communication are: What content are you trying to communicate? and, What are the most effective media for communicating it? Failure to address these difficult questions means that people end up with too much, too little, or the wrong information for them to be able to provide necessary feedback.

Do statements like these sound familiar?

• “We have to produce the feasibility report by the end of the week.”

• “The functional spec has to be ready by next Tuesday.”

• “We have to distribute formal minutes of this meeting to all the stakeholders.”

If you reply to these statements by asking why, the answer might be, “Because we have to produce this document at this phase of our project.” If you keep probing, and ask, “Precisely what is in the document? What is it for? Who uses it to make which decisions?” then you discover that people do not know why. They are producing the document because it is the next thing to do.

If you recognize this behavior on your project, you may be working in a paper mill.

In a paper mill, every activity is marked by the production of a document, and progress is measured by how many of the documents have been produced—not by what the documents contain. The paper mill principle says: Just in case anyone needs anything, let’s give everybody everything.

Another sign of a paper mill is that the contents of the various documents do not have any formal connection to each other. For example, a process in one document might have a very or slightly different name in another document. So, while people suspect it is the same thing, there is no formal traceability and lots of room for assumptions and confusion. Another indicator of this pattern is that people become obsessed with having documents in their possession. If you produce something—anything—people ask, “Can I have a copy of that?” Everyone wants a copy of everything.

Paper mills are detrimental because when people are focused on the weight of documents that have been produced, they stop thinking about something that is much more important: Are we doing useful work that contributes to the goals of the project?

Projects that are not paper mills use objective measures, agreed upon by the team, such as number of inputs and outputs, business processes, use cases, constraints, features, modules of working code, function points, data elements, or anything else appropriate for the project.¹

¹ For more information on tailoring the process and the documentation to the project’s real needs, see Pattern 12, “System Development Lemming Cycle.”

Instead of automatically producing a document, these project teams consider other ways to communicate progress. They use white boards, teleconferences, blogs, and prototypes as communication vehicles. They also discourage the squirreling away of individual documents by keeping project artifacts in a central project library and making them freely available to people who need them.

The point is that every document that is produced should satisfy some well-defined need and should have contents that are traceable to the overall project knowledge.