There are two aspects to organizational structure. The first refers to the human factors group's position within the company's organizational structure which has a significant effect on how effectively the group operates. Human factors groups have existed in several areas of the company organizational structure such as engineering, logistics, marketing, research & development, documentation, just to name a few. The placement within a specific category (e.g., engineering vs. marketing) is less important than where that category sits on the organizational chart with respect to power and influence. The human factors group should be placed at a level which affords enough influence to require the input of human factors in product development cycles (for example, ownership of the user interface).
The second aspect refers to the organizational structure of the group itself. These structures range from very centralized groups which act as a separate consulting body to a completely decentralized model where individual human factors persons co-locate with the project team they're working with. In essence, they become more a member of the project team than the human factors team. There are arguments for both approaches. It's my opinion that the most effective implementation is a hybrid of the de-centralized and centralized models.
When considering a company to join, ensure that the mandate of the human factors group is clear. Ensure management makes commitments with respect to the group's power, future hirings, and position within the company organizational chart.
The financial models of funding (i.e., how you get paid) can significantly impact the success of your group. For example, if the financial model dictates that your group is paid by the specific project being worked on, you'll find that you spend a great deal of time writing proposals and justifying your costs and effort. Also in this model, there is no recourse for doing non-project specific work (e.g., research, work that indirectly benefits many groups, but doesn't directly benefit a single group). A better situation is the existence of an overhead-style account to deal with non-project specific work.
There has been some debate over the issue of a centralized vs non-centralized implementations of human factors groups. However, it's my opinion that a hybrid of the centralized and non-centralized approaches is the best way to go. In this scenario, there is a centralized and identifiable human factors group. All requests for human factors related work is funneled through the group and the group leader distributes this work among the individual team members as he/she sees fit. Depending on the nature of the work, individual team members may be working in short consulting types of projects or may become dedicated project team members on specific projects (de-centralized). The key, however, is that de-centralized members ultimately report to the human factors group and when they finish working on the project ,return to the human factors group. Another key component in this model is control over the how human factors personnel are utilized. The decision as to who from the group will support a project and at what level the support will be should be left to the human factors group, not to individual project teams. It's also important to actively avoid the pitfalls associated with decentralization such as "disappearing" personnel (i.e., individual becomes so involved with the specific project that he/she begins doing non-human factors work for the project), alienation of decentralized individuals, and the loss of team concept. As such, the group has to actively preserve a team concept. Several methods are discussed in the maintaining Team Attitude section.