A have a technique and example for you. Our dev team and I have 2 methods of communicating bugs and bug fixes: e-mail and Excel. If it is a bug or feature of large scope, or an installation build, I use excel.
In terms of bug or feature of large scope, my excel spreadsheet has a minimum of 3 tabs. The first has the versions and objects affected, as well as any testing notes the dev has told me. The second has my test scenarios with staging data, steps, expected results and real results. This is stored per version and per platform so it can get fairly large. The 3rd tab has what we call the "Issues list." (wink wink nudge nudge, aka "bug list") On the Issues list I number the issue, provide a description, a hyperlink to documentation and a 'status' column (open/closed/he said/she said). There is usually a column for 'notes' as well since the devs will occasionally break down for me specifically which object they fixed or the design logic behind why it's as designed.
When I started here, none of this was being tracked. I put a stop to that. After I clarified theirs and the customers expectations (not well received at first, but I'm a bulldog), I then provided my testing steps and results, usually in a Word .doc file (baby steps, folks). Slowly, my system grew on our team. I have said on SQA before and I say it again: do what works best for your team. What works for your team won't work for mine, and vice versa. Flexibility is key!
One day, a dev called me "Macguyver" - I didn't watch that TV show and had to ask someone else, did he just insult me or what? Thankfully I found out it's a compliment.
I am proud of my excellent rapport with devs and work to protect it.
Finally what I am most proud of with my .xls files is this: I campaigned and sold the idea to management and devs to upload a comprehensive .xls to SharePoint where we ALL update the .xls file with the latest and greatest updates to issues. It works; they are ALL on board with this. At first they were put off by having to look at my test scenarios but I quickly learned to make it open up to the issues list to save them time. Also, to save them time, when an issue is verified as fixed or otherwise closed, and if there are > say 10 issues, I move it to a tab called 'closed issues list' thereby eliminating closed items so the devs can focus on the outstanding issues.
One thing I love about files on SharePoint is the ability to receive an e-mail when a file is updated. So as soon as they update it, I get an e-mail. I then check to see if I found a valid bug, it's as designed or I misunderstood the feature (few to no requirements are provided).... and sometimes I am flat out wrong.
You mentioned using Excel for test planning. I did attempt a Excel test plan many years ago, which my manager welcomed, but it didn't go further. We strictly use Excel for test scenarios, object/version reference and a bug list.
And, finally, when I first came to work here, I instituted a practice of using Excel to store test cases (they were 99% nonexistent). I have hundreds if not thousands of examples of Excel test cases if you need one. But since our QA staff went from 3 to 1, I no longer have time to create and maintain test cases.