In the interest of full disclosure I was asked to answer this.

For those that feel there isn't enough information to fully answer - while correct, defeats the purpose of Quora in my opinion so my answers might be a little vauge, but I'll try to be as precise as possible

1 - Definately consider early consulting to do the work - Focus on hiring someone with data warehouse implementation and archtitecture to lead the initiative.

I wouldn't try and hire for ETL until you know what integration strategy your going to use. Same for reporting. I would hire a data modeler if you can, but good luck finding one or a good one. Lean on staff aug or consulting for a data modeler.

I've seen good data warehouse implementations and I've seen bad. The single commonality across the good ones - having a great leader lead them.

2 - This is no different than any other data warehouse implementation - data growth, user growth, and usage of data will continue to grow (and should) through the lifecycle

3 - Time constraint: Is the sense of urgency maybe a lack in excel knoweldge? There isn't much (other than advanced visualizations and extremely large data sets) that excel can't handle for most users. Many times what I see is that reporting tools are used to grab data and aggregate it into usable chunks, and then exported to excel.
You can gain a lot of value in a few simple (not necessarily easy though) initial steps:

- Prioritize your subject areas - What is the most important to executive leadership - sales or customers. Don't let them tell you both because they want sales by customers, you'll get there but not by trying to bring in both at the same time. If sales are the focus, bring in sales, and then build from there.

- Cataloging data - what data do you have, where is it, what grain, what format, what platform
- Define the business logic behind the data (Weekly sales start on Monday or Sunday?) and enforce them across the enterprise
- Identify Data stewards - who owns the data and is responsible for it? Do it by subject area - i.e. sales, product, customer, location, time, etc

Data Warehouses take a while to build and mature. Set the expectation up front that end state is not going to be in 6 months. You can delivery value in six months, but it won't be a fully matured data warehouse.

4 - Project management: Most DW projects fail because of poor IT to business interlocking. Requirement sessions that go like this are never going to lead to successful projects:
IT: What are your requirements
Biz: We need data and reports
IT: What data do you need?
Biz: What data do you have?
IT: We have it all, what do you need?
Biz: We need it all, what can you give me
etc.

Start with strong executive sponsorship and a well defined business problem. For foundational data and initial build of a warehouse - stay away from a pure agile system. Data integration does not lend itself well to agile, you will need waterfall. Once you get into reports and ancilliary data sources, agile is fine.

5 - DWH tools: You keep referring to a high growth SaaS company - makes no difference what kind of company you are - from old retailer to silicon start up - your toolset is going to be dependent upon the following:

A. avaialble talent in the space (single largest driver). This will lend itself toward a tool. More people and staff aug companies can provide skillsets in Informatica than they can in building a DW from the ground on Perl.
B. Cost. This is going to be the competing factor to talent. Enterprise class software is expensive - so you might lean toward open source. Any sensitive data - lean back the other way..
C. Integration and database environment - Don't get Informatica if you're going to try and do something silly like build a data warehouse on Hadoop. Don't look at SSIS if you aren't running it on a SQL server - stuff like that.

6 - Technical: Kimball is more about data model than pure architecture, but you're on the right track. Again, it goes back to requirements and lifecycle. I hate to sound like a consultant, but it depends. leaving the hardware aside and looking at it from a pure data perspective - how many sources are you bringing in, how advanced are your users from a data anaylsis perspective, do you have the talent on staff or willing to try and get the talent to support complex data modelling efforts (trust me this is a huge undertaking. Data Modelers are being hoarded and guarded all over the place. Probably more so than Data Scientists).

I would start this by first hiring someone knoweldgeable in the space to lead the initiative. Preferably someone with experience on the entire lifecycle (from start to support). Then, either while trying to hire or once you've hired, define the following:

What is the business problem you're trying to solve with a warehouse.
What is the technology underpinning your warehouse (database, etl and reporting)
How much money are you willing to throw at it.