As a project gets closer and closer to handover to QA, I find myself tracking a list of outstanding items that need to be completed before the software is completely ready for testing. I'm trying to think of a way to do this that's more rigorous and visible - so that everyone is aware of what needs to be done and so things don't fall off the table. One possibility I'm considering is simply logging problem reports (trouble tickets) on the items which are outstanding. Would it be better to add them as explicit tasks to the project plan or is there a better way still?
For me the answer is hidden in a question. You want to make these things visible? Well, make them visible. Visualize your punch list, possibly on a physical medium and in a place which is frequently attended by the project team, be it a room they share, a hall or the place next to a coffee machine.
Using physical medium - a whiteboard or flipchart serves two purposes:
It gives a big picture to everyone. If the list is in bug tracker or something I likely filter out items which aren't assigned to me, thus I don't see what others have on their plates, thus it's unlikely that I consider helping them. With a physical board I want it or not I see the whole thing.
It makes the message more accessible by everyone. Whenever people are walking by the board they will take a quick look at it and possibly learn that something has changed or there is a problem with one of items etc. It is sort of learning "in the meantime." That's why the more crowded the place is which you put your board in the better.
There are also a few pleasant side effects:
Physical board is extremely flexible. You can draw a picture if you like, or attach a sticky which means something, e.g. a blocker, or have cool avatars of people who are assigned to tasks, etc.
It serves as a continuous reminder what else there is to be done. You can forget to log in into the app which stores your list when under heavy workload but you will eventually take a look at this big thing on a wall.
If the board is in a room the team works in you get additional information - everyone sees that someone comes to the board and changes something, thus they get an update in a very non-intrusive way.
It is a place where you can meet during project meetings to discuss most important and urgent things to deal with.
It gives you the place where you can do some brainstorming without losing a context. You can just use the empty place on the board.
It is fun. Definitely more fun that yet another bug tracker.
Does everybody need to be aware of what must be done? I think this might cause you more troubles if you have nearly completed development.
Regarding issue tracking. If it's a bug/defect/issue, then it should be formally logged, analysed and then tasked up. E.g. I found a bug on the live system. I have logged it. Front end senior developer has picked it up and analysed it. Another web developer knows how to fix the bug, so he then tasks it up, gets it approved by relevant parties and then starts development.
If it's just a task/feature, then it needs to be analysed in exactly the same way.
It doesn't matter at this stage whether it's in a bug tracking application, document sharing application or excel. As long as it's consistent and clear - you'll be fine.
Relevant stakeholders must be aware of this feature/task/bug, NOT everybody.