Get buy-in from the business office. If you feel strongly that a particular project is important, enlist someone on the business side to help champion your cause. You might encounter less resistance in getting corporate buy-in (and budget).
Be versatile and flexible. A single application based on a single architecture may not do the trick in every situation. Be open-minded enough to evaluate all the options before making your recommendation. If Microsoft's deep integration would shave 100 hours off a certain project, for instance, take that into account. If going with an open-source solution would save a significant amount in licensing fees, factor that into the equation.
Estimate high, but not too high, and don't blow your deadlines. Sure, most programming projects are more time-consuming than they appear at first glance, but if you inflate your time estimates unreasonably, you'll just foster the impression that developers can't be trusted. Cushion your estimates by 10 percent to 15 percent max, to cover yourself without looking foolish or lazy. Then do whatever it takes to meet the dates you set.
Encourage your customers to set priorities. Every department head believes his or her project is critical, but you can only put your team to work on so many applications at a time. Hold a regular management meeting to get a feel for the significance and immediacy of each project, and gently press the attendees to agree on a realistic schedule.