Let's start with the basics. Functional organizations are divided in functional groups e.g. finance, IT, HR etc. Within these groups, people are divided in teams. If you are lucky, you belong to only one team and have only one manager! Managers of these teams are called functional managers in project management terminology. They are responsible for resource assignment, performance evaluations etc. In short, they keep the organizational engine well oiled and running.

The problem arises when this model is applied to IT projects. In my consulting life, I have seen IT groups divided in teams based on competencies (Java/J2EE/software development team, database team, reports team) or by the kind of work they do (architecture and planning team, business analysis team, application development team). When there is a project, a project manager is found and resources are assigned from these teams. Why this common practice doesn't work for IT? Because, IT projects typically span across the tools and technologies and require various disciplines to work in harmony. A custom development project, which integrates with SAP and CRM systems, has hardware requirements to support the user base and must support web services to fit into the architectural vision, is not uncommon yet not easy to do in a functional organization.

I strongly believe that this model is inherently flawed for the following reasons:

• The project manager is not formally the boss of the team members. He/she sometimes has the input to the performance evaluation of the members but that's it. This is unfair to the team member who may have worked very hard but not under the nose of his formal boss. This is also unfair to the project manager as he/she doesn't have the absolute control over the members of the team
  
• Resources almost always aren't dedicated 100% to the project but have other responsibilities within the tree they belong to. In some organizations, resources are even pulled out of the project (though temporarily) impacting the project timeline
  
• Projects within functional organizations encourage 'throw over the wall' methodology. In many cases, a planning group does some planning and 'hands the deliverables over' to the implementation group. The project manager becomes a project coordinator juggling between team and people issues
  
• Team members bring the agenda of their tree/group to the project. For example, members from architecture and framework group might be more interested in doing things right according to the technological vision of the group while the project manager might be interested in getting the work done cheaper and faster. Mainframe group might try to push the functionality out to Java group or vice versa to control the scope of its work
  

So what is the solution? There are many ways to solve these problems: organizational culture, policy and process enforcements and organizational structure but I want to focus only on the organizational structure. The IT group shouldn't be organized into functional teams. Period. IT group should work pretty much like a consulting organization; relatively flat and project based. Depending on how much new development is going on, there may be a separate team or resources for maintaining the applications. The project manager picks the resources and they are 100% dedicated to the project. The team members' performance evaluation, which is done by the project manager, is based on their performance on the project. This gives the project manager enough control and empowerment to get the projects done, makes it easy for the resources to pick a career path as they don't have to change their group to pursue their career interests, makes it easy to shuffle the resources around and leaves no room for finger pointing between teams.

If you like to solve technology issues and hate to get into people issues, ask questions about the organizational structure before you accept that job.