When it comes to dealing with politics in IT, there are two general types I break things down into- Internal IT politics, and external polititcs.  The external politics are often one of the bigger challenges, as marketing, sales and other departments often feel a need to place their mark on a project, even if they have no idea what it entails. 

There are a couple of approaches that can be effective for dealing with External politics.  One of them is the classic bike-shedding method- give the people something minor to argue about that will consume all of their  attention so IT can get on with dealing with the important things. I find that the best method for doing this is to send an email to the potentially involved parties with a question about the bike shed that you want to use to keep them out of the technical things- perhaps a question about logos or fonts for official reports, or a whether a domain name should have a hyphen in it or not, something relatively  trivial that will have minimal impact on the actual code.  A similar tactic I like to use when presenting mock-ups/ prototypes is to make something that is easily modified with minimal impact, and make it have an obvious flaw so that people can point it out and feel that they have had a beneficial impact .  

When it comes to things like budgets and hardware purchases, I take a two-fold approach.  
The first portion of this is to show exactly why certain hardware is needed. Whether this comes from recommended specifications from a vendor for hardware involved in a new system being put in place, or showing why hardware for existing systems needs to be upgraded, I try to show that there are benefits to spending the money on upgrades.  In a previous job where I ran everything IT related for a collections call center, I was able to show the owners of the company that the server that they had for their database was running slowly enough to cause employees to spend an average of thirty seconds waiting for an account to open before they could make an outbound call, and an average of 2 minutes to be able to search up an account.  I then took information from the software's logs, and showed that most employees were spending up to an hour each day waiting for accoutns to load, and/or searching.  i then cross-referenced this with how many calls that came in and hung up because employees were unable to find who was calling for what before the person on the other end got upset and hung up.  In doing so, I was able to quantify the cost of having a server that was too slow as (employee hourly wage  x 1hr / day x # of employees in the office).  I then showed how much it was costing them per week , per month and per year to have a slow, outdated server.  I then compared it to the cost of the new server.  To further reinforce my point, I also showed how much money was spent on repeatedly calling people who did not stick around to wait for an employee to pull up their account, then looked into how many accounts per week this happened with, as well as how much less likely people that hung up due to delays in pulling up their account were to set up a payment plan.   The point I am trying to make about this is that when it comes to budgetary issues, it helps a lot to be able to speak in the language that management understands- money.  The second portion of the approach to getting budgetary approval is to speak the other language that management does not like to hear, but understands- compliance.  For example, the costs of upgrading software (OS, SQL server, etc. ) If a software upgrade is needed to maintain compliance, pointing out the fines for failing to do so is a good way to get approval for software upgrades- especially when the fines are an order of magnitude higher than the cost of the upgrade.   The combination of using the carrot of decreasing costs or increasing revenue and the stick of non-compliance fines tends to work well with management types when it comes to IT budgets in my experience. 

When it comes to internal IT politics, I find that a more nuanced approach is needed, as you are dealing with people that not only understand at least half of what you are talking about, but also frequently have strong feelings about technologies, vendors and other factors in IT.  for Internal politics, I usually try to get some input from as much of the team as possible, then do research into the various technologies, vendors, etc.  One of the biggest things I look for are specific aspects of a technology or vendor that makes it impossible or impractical to implement, such as security problems, cost, or compatibility with existing systems.  Once the impossible & impractical have been eliminated, it becomes a lot more feasible to debate things and arrive at something resembling a consensus.  When one or more people have had their  proposals eliminated due to the impossibility or impracticality of the proposed solution, it makes them more likely to look for flaws in the remaining proposals, as well as to make suggestions that can improve the remaining proposals.  In my current role, I am no longer in charge, which makes it a lot easier for me to shrug off politics for these kinds of things , because in the end, I am not the final decision maker.    I end up just making sure that I have lots of CYA for when there are things being implemented that I do not agree with for one reason or another, so that if something does go wrong, I at least have a paper trail to show that it was not my decision that caused something.  

Another  thing that I have noticed in IT politics is that there are two extremes in IT.  People that want change for the sake of change, and always want to use the newest, most up to date software and hardware, and people that think change should only happen when things are broken.  Striking a a balance between these two factions can be very difficult, as they both have their merits.