Most Excel programmers will at least occasionally need to automate something in Word, Outlook, PowerPoint, or Project as part of their Excel applications. This post addresses all of the standard components of MS Office that include VBA (there is no VBA for Visio). I suggest you read all sections of this post even if you're currently only interested in one of the applications, because there are comments in some sections that apply to other sections as well.

Access
Access is by far the closest companion to Excel of all components of the Office suite. It can be used to create self-standing applications that rival Excel-based applications or to create partial applications to accompany your Excel applications (such as for data entry or data viewing); and it can be used as a complete back end for your Excel applications or as an intermediary back end in cases where your data is stored in a database for which you don’t have write privileges. There is more than enough information out there online for you to use, and I’m not really an Access application developer; but if you know how to contact me and would like assistance, I will do my best to help. If you haven’t discovered ADO, I strongly suggest you learn to use that before doing anything complex with Access/SQL. For the most part, you will probably find it's much better to use ADO to query all kinds of databases directly than to write queries in Access that have to be translated. Access pass through queries are useful though, especially if you're already using Access for an intermediary back end because you can also use Access to resolve your data down to what you need in Excel to cut down on data transfer volumes. For those unfamiliar with Access, it uses VBA not only for application development, but also for tasks that would be done with triggers and stored procedures in other database applications (eg, Oracle, Sybase, MS SQL Server, etc.).

Outlook
After Access, I’ve found Outlook to be the most useful component of Office for business automation purposes because it can be used to generate and track mass distributions of individually customized email messages, which can save a great deal of time. I’ve written more of such applications than I care to remember, and they can be generalized to an extent, but I suggest you develop one to meet a certain need and then generalize from there because your needs may be significantly different from those I’ve had in the past – if you know how to contact me, I will gladly do my best to assist you though. (See “Creating Outlook Messages With HTML Formatted Ranges” in the Email category if you need to include charts, tables, or any complex or precise formatting in email messages.) In addition to controlling Outlook with Excel, data can be retrieved from Outlook, which can be useful for such things as tracking your user requests by counting certain types of messages. This is a less common need but it can save a lot of time as well, and it may impress people more than generating email because it's not used as commonly.

Word
After Outlook, it’s a toss up between PowerPoint and Word. VBA for Word works well enough to do most things you might need to do, and you can also use VSTO if you’re coming from a non-VBA Microsoft programming background and need to generate customized Word documents but don’t want to waste your time with Word’s VBA. I’ve never used VSTO for Word so I can’t say for sure, but I'm pretty sure VBA is still better for building Word applications, which is also still true for Excel (if you're not a true Excel programmer you may not know what you're missing with VSTO). I’ve developed complex Word applications using VBA and the main challenge has been fully understanding Word’s functionality (AKA, it’s 'object model'). I was more than proficient with Word beforehand, but I found it critical to fully understand the majority of the application to determine the best methods to do most complex tasks. That's not the case with Excel, as I've seen programmers who had little experience with Excel develop robust applications – don't get me wrong, a good Excel/VBA specialist should be able to write better code than a programming generalist in almost all cases (exceptions might include such things as intense matrix manipulations and calculations, but common instances of those things can usually also be handled externally – eg, DLLs called from VBA). I don't plan to teach Word programming on this site; but if you know how to contact me, I will gladly do my best to give you direction for your Word programming needs.

PowerPoint
PowerPoint works better in combination with Excel than Word, but again you may prefer to use VSTO for some purposes because you shouldn't need to link your completed PowerPoint presentations back to Excel (data is rarely entered through PowerPoint, and although it would be possible to use SQL/ADO/OLE through PowerPoint, I can hardly imagine a reason to send any data from PowerPoint to Excel – that is unless you're developing an application in PowerPoint with Excel as the back end, which is not really in the scope of this post). I suggest you write code both in Excel and PowerPoint that works in combination to create your PowerPoint presentations, using OLE to link the two applications together – dividing up your code between applications also applies to most Access and Word applications you are likely to develop to accompany Excel applications. OLE can cause fatal freezes when things go wrong, so it should be used sparingly or not at all for Access back ends – if your company's security policies don't preclude you from using Unix scripting tools like AutoSys, you may find scripting a better way to automate things like calling Access code at certain times than OLE. OLE is fine for creating PowerPoint presentations though because freezing isn’t much of an issue if you’re the one using your own automation software. I wouldn’t send someone a PowerPoint presentation that is controlled by Excel and hope they were able to deal with any problems that might arise though – for that, you would want all of the code they need to run the presentation to be within the PowerPoint file – you would only use Excel to create the PowerPoint file. Of course, the other use for VBA in PowerPoint is for developing complex animations or interactive presentations, but that is not really my bailiwick so again I will advise you to search the Internet for starter code. I haven’t used Project’s VBA enough to say for sure, but these guidelines for PowerPoint should also apply to Project for the most part.