For anyone in the technology management business that should be a very obvious and simple question to answer: Development is about programming and creating software applications and IT is about installing and managing servers and networks. While those are true and accurate differences, there is less value in obvious and simple answers and what we really want is something more meaningful. What if we’re looking to understand the nature of the processes used to manage development and IT functions and how those processes are different? What if we’re looking for the influences that make an application developer’s job different from a system administrator’s? How would you respond from that perspective?

Broad and open questions are really meant to be debated, but let’s try to put a stake in the ground and consider a response; so here’s one perspective. When Developers interact with end users it’s to define a new feature in an application. Usually a single end user or a single business group owns the definition. Once the feature is understood and defined, a developer creates the feature and delivers it to the end user after some period, usually on the order of days, weeks, or in some cases longer. When the feature is delivered, the process starts over again to define the next new feature which is always different from any of the previous ones.

When IT managers interact with end users it’s to deliver something that’s already defined. For example, an end user may need a new desktop, a faster notebook, a replacement Blackberry, or a new fileserver share to store documents. Since what they’re asking for is already defined, the end user expects that the request will be delivered quickly, in hours or in a few days (at most) and it will be delivered in working order exactly the same as the previous times (which is not at all unreasonable from the end user’s point of view).

So Development is in the business to deliver new things over-and-over again, and IT is in the business to deliver the same thing over-and-over again quickly.

And that’s one way to answer the question in a single and meaningful discrete statement. But be careful not to underestimate the differences. In software development there is a one-to-one relationship between the definition of a feature to its delivery. For example, an end user wants a new button on a screen to perform a function. An end user will define the button and the function and a software developer delivers the new button and its associated function. That’s one-to-one, one definition to the delivery of one feature.

On the other hand, in IT there is one definition that is applied to many deliveries. For example, an end user wants a specific set of software applications to be included on desktop computers and an IT manager configures and delivers the desktops to multiple end users in a department. That’s one-to-many, one definition to the delivery of many desktops. And unlike Development, in IT the deliveries are not distinct and usually occur over an extended time period.

There are additional differences. In Development there is typically a single business owner who defines the feature, however, in IT, definitions usually have to satisfy multiple business owners sometimes across multiple departments that are operating different business functions.

In an IT function it’s easy for the definition behind a delivery to be become out-of-date, stale, and sometimes inaccurate as hardware is upgraded, software updates change features of vendor-based applications, or when feedback from multiple end user groups change the definitions in small incremental ways over time.

IT groups also have the challenge of keeping the already deployed systems in-sync. When Blackberry releases a software upgrade, for example, in some cases new hardware devices may require the new software version to function, and in others the new software may not work on older devices, which results in a deployed base of devices that can work differently from one another. However, from the end user’s perspective they provided a definition for a mobile email device and a Blackberry is a Blackberry and each one should work the same way.

An organized IT group will maintain definitions for end user requirements in the form of Build Documents and attempt to keep them up-to-date. However, as business groups grow, objectives change, and collaboration scenarios between business teams expand, end users aren’t oriented to inform IT of the changes and in many cases it becomes the responsibility of IT to initiate dialog with end users to update requirements (rather than end users initiating the dialog which is generally the case when new application features are needed from Development teams). In addition, IT frequently has to manage, and sometimes rationalize, conflicting requirements from multiple end user departments that may come up over time. Since a Development function delivers one feature to one requirement, the dialog with end users is usually more current with the request.

Also be aware of the analogy between the “source code” of an application and the “configuration” of a product (such as a desktop, server, or network device). End user groups generally have an understanding that developers need time to change and test source code. But since end users expect IT to deliver the same thing over-and-over again quickly, there is not a similar understanding that IT needs time to change and test configurations. And making matters more difficult for IT, there are many good versioning systems to help manage changes to source code, but system “configurations” in many cases are disjointed and can’t really be versioned and controlled like applications’ source code.

So what can be done to improve the situation and avoid problems? Well first, IT managers and others responsible for an IT function should be aware of the underlying nature of Development vs IT processes. IT managers should maintain a collaborative and productive process with business groups and keep-up with requirement definitions in a Build Document type format that captures any differences between end user groups. IT managers should also attempt to make the nature of their function transparent so business-side teams have a basis to understand the processes that are used to manage infrastructure-based deliveries.