You must consider the corporate culture and be sensitive to the associated issues when introducing human factors or usability engineering. When people are comfortable with a situation, they tend to view new ideas or new ways of doing things with skepticism and doubt. It's best to "blend" into the organization as opposed to forcing your way in. While banging your hand on the table and demanding in no uncertain terms that human factors or usability MUST be involved may give you immediate results, in the long run, your group is more likely to gain true acceptance if you ease your way in. The key is to eventually make people want your services, as opposed to force your services on them.
It's success on an initial or early project that spawns curiosity, interest, and eventually demand for your services (the key being success on that project). As such, you need to:
There are definitely times when you have to "butt heads" to get what you need. However, you want to make sure you reserve these battles for truly important issues. Going to battle on every little issue (without regard to its significance or importance) is contrary to the idea of "blending" into the organization. Always creating a ruckus will reduce your credibility. If you only battle over truly important issues, people realize that you are the type of person who only argues important issues. I've seen it many times where the person who is rarely talks during a meeting is the one that everyone listens to (as opposed to the person who is always complaining about everything). Fighting battles is time consuming. There's no shortage of battles that need to be fought and it's too easy to end up spending all your time fighting battles. There are better ways to spend your time.
Minimize grief on the other side by tailoring your own procedures to fit neatly into existing procedures. Take advantage of successful procedures already in practice. Minimizing your effect on existing processes goes a long way in showing that your input does not negatively impact current practices.
Use tools, terms, processes, procedures that are familiar to the people you're working with (e.g., engineers like quantitative things so provide quantitative usability goals, or quantitative usability metrics). This helps to put you on more even terms with them and helps forward the concept that you are all working on the same team toward the same goal.