I've been meaning to say this for a while now...
When working with an OLAP tool (say Microsoft Analysis Services 2005 -- or 2000 -- or Hyperion -- or any OLAP tool under the sun) there are three guiding principles.
#1: Know your data. It doesn't matter how snazzy your tools are, how good looking your web site/reports are if all the data is meaningless to you. Yes, it might mean something to your customer, but until it means something to you, you are going to have a hard time really helping the customer.
#2. Know your display tools. Depending on what tool your customers are going to use to see the data, it will change how you construct your cubes and dimensions. There are things you can get away with when your client is ProClarity that are a bad idea for Reporting Services, and a terrible idea for Excel.
Case in point is the naming of attribute dimensions. You might have a dimension named Project with an attribute hierarchy named "Name". Seems logical. Then you also have a Customer dimension with a "Name" attribute hierarchy. So in ProClarity or Reporting Services you will see the nice Project.Name and Customer.Name hierarchies. In Excel (via pivot , you will see "Name" and "Name". Not very helpful. So you have to name your attribute hierarchies "Project Name" and "Customer Name" to keep the Excel Pivot table people off of you back.
#3. Regardless of what tool your customer says they are going to use, always test the data in Excel -- especially Date dimension data. Why? Because some customer will always want to see the data in excel. They don't care that all the data is already in some other tool nice and formatted and pretty, if the data isn't in Excel it isn't useful to them. Just deal with it, you can't cant change their minds.
Also, be sure to test how your date dimension data looks when exported to excel. Excel has this helpful habit of looking at your data, seeing a date, and then formatting it incorrectly. What starts out as April 02 (for April 2002) is suddenly transformed into April 2, 2006. And you will be blamed for this. Not Excel. No, not our precious Excel that can do no wrong (quiet next time, it might hear you). You are in the wrong and must fix this error. And the fix is a four digit year which will anger someone else -- but you will get used to that.
I hope this becomes helpful to someone, it was a painful process for me to get to this point myself.