The Art of Project Management

6.7. The open-issues list

As the field of alternatives narrows, there is one new responsibility for the project manager: the open-issues list. An open issue is anything that needs to be decided or figured out but hasn't happened yet. It's essentially a list of questions, and it should encompass anything that needs to be done, prioritized by its potential impact on engineering. The form of this list isn't as important as the quality of issues listed and the diligence of the person driving to resolve them. I've used a designated spot on a whiteboard or Excel spreadsheets for this, and I can't say that the tool I chose made much of a difference either way. I don't think these lists need to be controlled or managed like source code (that is, unless the politics or culture of your organization make it worthwhile); the simpler the tool, the better it is.

This list can start with a very rough list of unanswered questions ("Will we use data schema A or B?" or "We need final UI design from Sally"), but it should grow and improve in detail as fewer days remain before the specifications are written. Each item should have a name next to it of the person who is driving the issue to resolution. It should be the PM's job to make sure everyone is aware of issues they've been assigned, nag them appropriately, and track them to resolution.

Programmers should have the full burden of engineering questions and research, but if there are any issues that the PM can take on, he should. Typically, items ...