This Month’s Pattern *

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.*

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.

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

* Each month we plan to publish here one of the patterns from our Jolt Award book, Adrenaline Junkies and Template Zombies — Understanding Patterns of Project Behavior. (Watch this space for a mere 86 months and you'll have read the whole thing.) The book is published by Dorset House Publishing, in the US and Hanser Verlag in Germany. It is available at Amazon and also as a Kindle book.


Stockholm, Mastering the Requirements Process
9-May-2017 to 11-May-2017

Brussels, Mastering the Requirements Process
13-Jun-2017 to 15-Jun-2017

James Robertson teaches Mastering the Requirements Process. Please contact I.T.Works for details. 

Hilversum, Mastering the Requirements Process
13-Jun-2017 to 15-Jun-2017

James Archer presents Mastering the Requirements Process for Adept Events. Details and registration: English - Dutch.

Oslo, Mastering the Requirements Process
12-Sep-2017 to 14-Sep-2017

Mastering the Requirements Process with Suzanne Robertson. Contact Den Norske Dataforeignen for details. 

Brussels, Mastering Business Analysis
13-Sep-2017 to 14-Sep-2017

James Archer teaches Mastering Business Analysis. Contact IT Works for details of this course.  

Stockholm, Mastering the Requirements Process
26-Sep-2017 to 28-Sep-2017

Brussels, Mastering the Requirements Process
10-Oct-2017 to 12-Oct-2017

James Robertson teaches Mastering the Requirements Process. Please contact I.T.Works for details.  

Brussels, MRP part 2
11-Oct-2017 to 12-Oct-2017

Rome, Mastering the Requirements Process
16-Oct-2017 to 18-Oct-2017

Rome, Mastering Business Analysis
19-Oct-2017 to 20-Oct-2017

James Robertson teaches Mastering Business Analysis. Contact Technology Transfer for details of this course.  

Oslo, Mastering the Requirements Process
6-Nov-2017 to 8-Nov-2017

Mastering the Requirements Process with Suzanne Robertson. Contact Den Norske Dataforeignen for details. 

Hilversum, Mastering the Requirements Process
7-Nov-2017 to 9-Nov-2017

James Archer teaches Mastering the Requirements Process. For details please contact Adept Events. Dutch description, or in English.

Oslo, Mastering the Requirements Process part 2
9-Nov-2017 to 10-Nov-2017

Suzanne Robertson teaches Mastering the Requirements Process part 2. Details for this advanced class at Den Norske Dataforeningen.

London, Mastering the Requirements Process
14-Nov-2017 to 16-Nov-2017

James Archer teaches Mastering the Requirements Process. For details and registration, please contact IRM UK.

in depth

Business analysis is often seen as a technical skill. But the business analyst has another set of responsibilities -- to dig into what the stakeholder's mind and uncover what is really needed, and not just what they say they want. 

A Ruby Beam of Light, Book I of Tom DeMarco's Andronescu's Paradox saga is now available in English in paperback and ebook, from Double Dragon Publishing.

"This war isn't going to blow anything up, only turn everything off."

Suzanne and James Robertson's "Requirements: The Masterclass LiveLessons-Traditional, Agile, Outsourcing". 15+ Hours of Video Instruction. 

Als auf der Welt das Licht Ausging, the German edition of Tom DeMarco's science fiction epic, Andronescu's Paradox, has now been published by Hanser Verlag in Munich.  Translation by Andreas Brandhorst.

James Robertson’s webinar for Software Education explains how agile stories are best used to ensure the right solution. Writing the Right Agile Stories on YouTube. Download the webinar slides.