Many IT organizations organize themselves in such a way that each IT discipline is a different group that is managed independently of the others. The Oracle group does Oracle. The UNIX guys do UNIX. The scheduling group does scheduling only, and so forth. Many companies also choose to separate the 'project' IT resources from the 'operations' IT resources, so as to complicate things more.

So, when a large LIMS project comes along that deals with multiple functional IT groups, someone has to take the different functional groups in IT and make them all work cohesively together to deliver a unified system to the end users. And yet it so rarely happens. Instead of an integrated solution, we have systems that are barely held together.

Matt's premise was that it is the application team's responsibility to add the cohesion to the working group. In other words, because IT organizations are so bent on creating groups that essentially do one thing and only one thing, it is the LIMS application team's responsibility to learn all of the specifics of the functional IT groups so that the application team can provide proper direction. Since the LIMS application team is the closest to the end users, they should bear the chore. My argument is that IT as a whole should provide a dedicated project group to do all of the cohesion and coordination.

Matt is biased by reality, whereas I prefer being naïve. Being a pragmatist, Matt knows that when push comes to shove, most IT infrastructure groups only care about satisfying their group metrics and charging back for their services (but that is a separate rant). Although they charge back, customer service to internal customers is almost never a consideration for IT functional groups. In fact, if they can charge back without providing good customer service, why would they?

In my perfect world, if a group is going to charge another group an obscene amount of money to perform basic IT functions, the least they should be able to do is absorb the overhead of making sure that those services are coordinated well. That shouldn't be that hard. It isn't like I'm asking that all of the project team members actually understand what LIMS is. That would be remarkable, but that too, is the subject of a future rant.

Outside consultants are required by market forces to provide good service to customers. Any that don't will not survive for very long. But so far in my experience, too many IT groups have been given a pass on providing appropriate customer services along with their technical services. And because of that, you have LIMS application groups who feel like they have to learn UNIX, Oracle, scheduling and Citrix internals just to tell the Administrators and DBAs what to do on their project. It almost makes me wonder why we don't go back to the days when IT generalists worked on projects and learned the whole system.