Tips for efficient software project management

I have accumulated a number of practices that help me to stay 'on-top' of projects.  Some of them gleaned from various project management and productivity text.  I share some of them here, hoping they might be useful to those of you running projects with a technical hat and a PM hat on.

• If you have any tasks that can be done in 2 minutes or less, do them immediately, otherwise schedule them for a specific time or add them to a prioritised "Todo" list. 
• Only check your email three times each day:
• first thing in the morning
• lunchtime
• an hour before you intend to leave the office
• When you read each email, or piece of correspondence, make a decision about what to do with it:
• Delete it
• Archive it in a relevant directory (Ask yourself, if I need to reference this, where will I look first?)
• Reply (if you can compose a reply in less than 2 minutes)
• Move it to a 'Todo' directory (if you need to respond, but doing so would take longer than 2 minutes).
• Only attend meetings you have been sent an agenda for.  If there is no agenda, there will be no real decisions and it is a poor use of your time.
• Maintain a "Follow-up" list of things people have committed to doing for you, and their due dates.  Review this daily and follow-up proactively - don't just sit and wait.  If one if these tasks is quite some time away, send a friendly reminder a few days ahead of the due date.  Maybe send an email saying that you are looking forward to receiving it, and offering to help them finalise it if necessary. 
• For each project, maintain a daily log of decisions made, the reason why, and by whom.  This will be invaluable if you  need to hand over the project (even if only temporarily while you go on leave).
• Maintain an accurate and up to date progress log.  A requirements traceability matrix with additional 'date started', 'assigned to' and 'date delivered' columns is a useful starting point in the absence of anything else. Once again this helps with handover.
• Proactively communicate progress to stakeholders.  This prevents you from having to respond to endless emails asking for updates.  Publishing a weekly report can be useful.  You can refer all requests to the status on the last report or tell them to wait for the next one.
• Never accept or believe a '% complete' progress update.  A feature in a software product has only 3 statuses:
1. Not started
2. In progress
3. Ready to ship
• Break software features down into 1-5 day tasks where possible.  Estimates will be more accurate, and bearing the aforementioned point in mind, progress updates will be more accurate.