(Note - I'll add to this post as new information is updated - latest post date is August 6th, 2013)
I've been working on cloud projects of all types for over three years now. Along the way, I've learned some basic patterns that make for a successful project - and also the things to avoid. The general steps depend a great deal on whether the project is an Infrastructure, Platform or Service deployment, and also if it is a hybrid or completely cloud architecture. In all cases, what you do before deploying the system - the "plumbing", if you will - turns out to be the key for a successful deployment.
If this is your first cloud deployment, I recommend working with your local Microsoft team or a partner you trust that has Windows Azure experience. They can help you through the process, and then you can take over from there. It's a far faster, successful route to get a good deployment quickly.
Accounts and Billing 
Probably the most non-technical parts of the project that causes the most issues is setting up an account for the cloud provider and how you pay for it. But this needs to be done first. You have three progressions: No account (everything local), optionally an MSDN account for Dev and Test, and then on to the production account.
NOTE: The order here is not required. It's simply a guide I use to progress from on-premises to Windows Azure. You can start directly in Windows Azure, and that's completely OK. For a complete overview of accounts, check this resource: http://msdn.microsoft.com/en-us/library/windowsazure/hh531793.aspx.
Step One - Local Dev and Test
There are a couple of dependencies here. If you're looking at an Infrastructure as a Service (Iaas) deployment of Virtual Machines, you'll use Hyper-V to create images whether that's on-premises or through the portal on Windows Azure. For a local system, simply create the VM's using Hyper-V using the sizes and requirements shown here: http://www.windowsazure.com/en-us/manage/windows/common-tasks/upload-a-vhd/.
If you're deploying a Platform as a Service (PaaS) application, it's also quite simple. Download the Software Development Kit (SDK) from here: http://www.windowsazure.com/en-us/downloads/?sdk=net and then write your code. When you run the code, a Windows Azure emulator will fire up right on your laptop.
For Software as a Service (SaaS) offerings such as Windows Azure Media Services or HDInsight (Hadoop), there is no local testing other than the code or scripts you want to run. You'll simply skip to step three.
Step Two - Dev and Test on Azure
You have two options for your development and testing environment. The first is to use your Microsoft Developer Network (MSDN) account, if you have one. If you do, you have "free" Windows Azure time built right in. It's not a separate Windows Azure or any different than production Windows Azure - it's the same data centers, servers, services and so on, it's just billed differently.
There are some restrictions here - this isn't for production, you can't "bundle them up" or anything like that. It's the same as the software you use with your MSDN account. You can learn more about this here: http://www.windowsazure.com/en-us/pricing/member-offers/msdn-benefits/.
If you don't have an MSDN subscription, you'll need to create a regular, billable account, for Dev and Test. This is the same process I'll describe below.
Step Three - Deploy to Production
To set up an account, you'll need to figure out how your company wants to pay for it. Remember, this is a "pay as you go" model, so the two routes you have are to pay a monthly bill (using a corporate credit card or a purchase order) or you can pay ahead of time and use the money throughout the year on an "Enterprise Agreement (EA). Get with your local Microsoft team to work out the best route and price. The general process is detailed here: http://www.windowsazure.com/en-us/develop/net/tutorials/create-a-windows-azure-account/
Figure out who will control these accounts right from the start. In general, one person should control Dev and Test, another should control production. In any case, determine this before you start - I've seen projects fail not because of technical reasons, but because no one checked on whether they could pay for the service.
Speaking of pricing, there are a couple of simple calculators you can use. If you followed the process above, you already have an idea of which resources you are using, and how much of each you have used in testing. From there you can plug in the usage numbers from Dev and Test to get a prediction of how much production will cost.
Resources:
General info on pricing and billing: http://www.windowsazure.com/en-us/pricing/overview/?fb=en-us
"Slider" calculator: http://www.windowsazure.com/en-us/pricing/calculator/?scenario=full
Planning and Education
In all cases, you need to start with a good plan. It's true that you don't always know what you don't always know, so you'll need to allow for some amount of adjustment. You still need to start with a good plan, however, even before you know what Windows Azure is or how it works. Your plan should start with what the project does when it is successful. That allows you to use the right technology to accomplish the goal.
I can't overemphasize this step enough. It sounds simple - certainly you know what you want the system to do, right? So often I have seen teams start with how the system should work before they consider the hard and fast requirements of the system. And sometimes teams are unwilling to try some other technology to solve the problem, instead clinging to the technology they know or like best.
After you have a solid understanding of the success metrics, it's time to start learning. The route I recommend is an overview of the platform's capabilities, and then a focus on the components you can use in your solution.
References:
General overview of Windows Azure:
http://blogs.msdn.com/b/buckwoody/archive/2012/06/13/windows-azure-write-run-or-use-software.aspx
http://www.windowsazure.com/en-us/develop/net/fundamentals/intro-to-windows-azure/
http://www.windowsazure.com/en-us/documentation/infographics/windows-azure/
http://www.windowsazure.com/en-us/develop/net/fundamentals/compute/
Documentation:
http://www.windowsazure.com/en-us/documentation/
IaaS Hybrid Deployment
The "plumbing" for an IaaS Hybrid deployment needs the most preparation. You need to think about the connectivity, security, and DevOps before you deploy the first Virtual Machine.
To begin, follow the steps here to set up a Storage Accounts, Virtual Networks and then the Availability Groups where the VM's will be deployed: http://blogs.msdn.com/b/buckwoody/archive/2013/04/17/creating-a-windows-azure-virtual-machine-the-right-way.aspx.
Connectivity
With Windows Azure, you can set up three types of connectivity from your on-premises to Windows Azure VM's. The first is to use a public-facing TCP/IP address. While this isn't the most secure route, it does have specific use-cases, such as a public-facing web application that you want to access from your internal systems. The Portal will show the public IP your system is assigned, and then you have control over whether any endpoints are exposed - from there you can map them to your internal endpoints on the Virtual Machine, or even load-balance them if you like. More on that here: http://www.windowsazure.com/en-us/manage/windows/how-to-guides/setup-endpoints/
The second method of connectivity is to set up a site-to-site VPN. In this option the Virtual Network you created in Azure (along with the VM's you put in that Virtual Network) are connected directly to your internal TCP/IP network - making a secure, transparent connection. The process for this connection is here: http://msdn.microsoft.com/en-us/library/windowsazure/jj156075.aspx.
Your next option is to set up a point-to-site VPN. This allows a single computer on your network to connect securely and directly to your Virtual Network (and the VM's you put in them) using only software - no hardware needed. Here is the process to do that: http://msdn.microsoft.com/en-us/library/windowsazure/jj156074.aspx#BKMK_VNETPT. Read that entire page for context.
Security
If you want single-sign-on from your local Active Directory, you have two choices. One is to follow the process above to create the VPN connection, and then deploy a Virtual Machine in Windows Azure and run dcpromo on it. From there it's similar to an on-premises AD server.
Your second option is to use Windows Azure Active Directory - it's a service that acts as an ADFS provider. You can learn all the details starting here: http://www.windowsazure.com/en-us/documentation/services/active-directory/?fb=en-us.
PaaS Deployment
For a PaaS deployment, the primary plumbing considerations are the accounts and billing decisions I described above, security, and DevOps.
Accounting and billing can be more challenging in a PaaS environment since you aren't always sure how much the service will be used and when. To gain more accurate predictions, you need to place monitoring and metrics right into your code. Your primary knobs and controls fall under Windows Azure Diagnostics - more on that here: http://msdn.microsoft.com/en-us/library/windowsazure/gg433048.aspx. Start with the main topic and follow *all* the links on the left-hand side of that page.
For security, the plumbing involves deciding on what type of authentication and access you want to use. The best place for references on that is here: http://www.windowsazure.com/en-us/develop/net/how-to-guides/access-control/.
DevOps is becoming a huge concern for cloud deployments, and you need to think about how you'll manage and monitor the PaaS application up front. Start with this reference and follow the links for more: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WAD-B337#fbid=5xe4PAr30H3.
References:
General Guidelines are here: http://msdn.microsoft.com/en-us/library/hh674495.aspx
"Real World" guidance is here: http://msdn.microsoft.com/en-us/library/hh127475.aspx
SaaS Deployment
For a SaaS deployment, you'll need to consider the accounts and billing, security, and DevOps links I mentioned above. In addition, you'll need to consider data movement strategies from the outset. More information here: http://www.windowsazure.com/en-us/develop/net/fundamentals/cloud-storage-scenarios/