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 that might block engineering but are not engineering specificsuch as marketing approval, usability considerations, branding, and visual designshould be tracked by the project manager, as they will impact the specification more so than the implementation (we'll cover the difference between the two in Chapter 7).
The wise project manager divides the open-issues list into two priorities: things that need to be resolved before specifications, and things that might wait until later. It's the most natural way to prioritize and focus on issues that have the potential to block engineeringand possibly the entire project. Anything on the post-specification list should be clarified with engineers because they're the only ones who can verify that the decision or information can wait. (How and why things should wait until after specifications will be covered in the next chapter.)
So, every uncertainty that needs to be addressed should be listed. No one but the project manager may need to see this list, certainly not early on. But as days go by, it can serve as a tool to unify the team in meetings or hallway discussions. The goal isn't to make people feel bad, it's to remind them of what remains and to help them see what problems other team members need to resolve. Because the project manager's work affects everyone, making the list visible allows people to collaborate on resolving the issues. "Oh, that's on my list, too. Should you take it, or should I?" This is one reason I've kept my issues list up on a whiteboard in my office or in the hallway. (A web site might work fine, but in my experience, no one ever looks at that list but the person who created it. Non-virtual and informal places work much better.)
I found that whenever people came by my office and asked how things were going, I'd point to that list and say, "That's exactly how things are going. When that list is empty, I'll be able to finish those specifications." While this isn't a performance metric or something rigorously measurable over time, the state of a project manager's issues list, and the scope of the questions it includes, reveal a great deal about how well things are going. If the list is long but contains very specific and narrow issues, things are in good shape. If the list is short but asks scary fundamentals like, "What problem are we trying to solve?" or "What programming language are we using?", you know the project has a long way to go.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.