We will plant a tree for each of the first 5,000 downloads.
This issue's dive into project management got me thinking about the unique needs of certain departments and how to staff for those needs.
I'm not talking about desktop support, where it's fairly common to allocate IT end-user support staff on a department-by-department basis. I'm thinking instead about groups and departments with needs that are significantly different from those of others in the organization. Some common examples are R&D and engineering teams and even specialized product teams.
On a larger scale, companies often debate just how much of IT to centralize when the company consists of major divisions developed through acquisitions. When economies of scale are discussed as acquisition benefits, IT consolidation is often one of the targets.
It's also much easier to claim that you'll consolidate the IT teams than it is to do it. On large scales, and particularly when it's a true merger of similarly sized companies, fully combining IT operations is a multiyear process--the sort of thing that has consultants drooling on their pinstriped suits and paisley ties with the wide knots.
But what about those unique needs of smaller groups, sometimes startup efforts within a company? Basically, IT has three options:
1. Let the group do whatever it wants--run its own IT resources as it sees fit, including hiring the people who support its unique needs. This approach has the benefit of not disturbing IT's status quo, and if the mission of the group is truly crossways with the usual IT operations, it might make sense. In particular, if the group is savvy about its needs, letting it manage its own IT staff may cause the least friction.
2. Learn the needs of the group, and staff from within the central IT organization to meet them. The advantage of this approach is that IT employs the team, and so even if what those people do is different from everything else IT does, you can at least make them aware of policies and procedures, and when appropriate use existing IT resources rather than create new ones. One good example is backup and archiving, which rarely needs to be done in unique ways.
3. Use a hybrid approach, where central IT works with the department, jointly hiring and managing the staff. As much of a Kumbaya moment as this would seem to be, it's never easy to serve two masters, and making this arrangement work can have just as many pitfalls as any other approach. On the upside, IT has a chance to help the group not duplicate functions that aren't truly unique to its mission, while the group can get the expertise it needs to serve its mission.
The bottom line here is that there is no "right" answer. Any of these approaches may be right, and without some healthy dialog with business partners, IT leaders shouldn't put themselves in a position of dictating what easily could be the wrong answer.
This discussion needs to be an honest one with respect to the group's ability to manage its own computing systems, and IT needs to realize that business needs will probably trump its own procedures in these unique instances.
Conversely, if someone walks into the room and thinks he knows the right solution before hearing the problem, well, at least you know who you're dealing with.
Art Wittmann is director of InformationWeek Analytics, a portfolio of decision-support tools and analyst reports. You can write to him at email@example.com.
To find out more about Art Wittmann, please visit his page.