Somewhere in the Neutral Zone IT responsibilities become engineering responsibilities and vice versa. Let me illustrate with a recent example: Our sales department wanted to add e-commerce functionality to our rich media marketing applications. One aspect of this is the ability to process credit cards. So our engineering department took it upon themselves to get this going. In one of our weekly meetings they asked me to provide the server and Internet infrastructure to handle the credit card processing, using a service bureau they had already chosen (without even mentioning it to me).

Not the way I would have liked it to happen, but hey, I can deal with it! But as I am configuring the server, the issues start presenting themselves. Are we going to use the service bureau's secure servers, or our own? Do we need to use their custom API, or can we just post an HTTPS query? Can we use a public certificate from any authority we choose, or do we need to use an authority approved by the bureau?

I hammered the engineering guys on these issues, and they lashed back with their concerns. Left unchecked, this adversarial debate was sure to escalate, with each side pointing fingers at the other, until it culminated in an all out IT - Engineering war.

Thankfully, I was able to avert such a war by putting on my diplomacy hat and working through each issue. But what a frustrating process! It would have been so much easier, and far less adversarial, if our respective roles in the Neutral Zone were better defined.

So I decided to document just what those roles should be. What follows is a summary of that documentation. Take heed to my advice, and you'll weather the Neutral Zone without a glitch-regardless of which side of the Zone you belong to.

Establish Clear Cut Responsibilities
It may sound cliché, but it is nonetheless very effective. Make sure everyone agrees on who is responsible for acquiring software, choosing service providers, determining equipment needs, etc. Had there been an official policy in place regarding software acquisition, my battles with Engineering would have been minimal.

As you define these areas of responsibility, be sure to tie them to some kind of service level agreement. I have promised the engineers that when they present their requirements to me I will implement the appropriate solution within a certain time frame, depending on the production priority of the request.

Define Requirements Based on Desired Functionality, Rather Than a Hardware/Software Perspective
This is a tough one. We techies love to spec out hardware, and we tend to always want a dedicated box for each project. Sometimes this is necessary, but more often than not, all that's needed is a specific service.

Say you're a developer and you need a test environment for SQL server and IIS. Instead of asking IT to purchase and install two new servers for you, articulate what you need to test: "I need to test some ASP code against a SQL server database, ensuring that I've set appropriate permissions on the data based on user login credentials." All you really need in this scenario is an IIS instance and access to a SQL server where you can create a database and assign permissions. I could give you what you need using existing servers-saving time and money.

Specify Deliverables
Another cliché, but very important. Clearly defined deliverables are crucial in ascertaining if requirements are actually met. The key here is "clearly defined." Deliverables should be measurable, tangible and directly linked to requirements. Returning to our SQL/IIS example above, the developer's deliverable would be a specification document that identifies the need for an IIS web instance (with particulars like whether or not a DNS host is needed) and a SQL server (again, with particulars like whether or not sa access is needed).

From the IT perspective, the deliverable would be a document detailing the machine name, IP address, and security information for both the IIS instance and SQL server, as well as the servers themselves.

Choose an Arbiter
Even if you follow all these guidelines, there will still be times when people start donning battle armor, hands raised, ready to start finger pointing. That's why you need to agree (preferably before it's necessary) on a neutral party to act as a mediator when necessary. Ideally, this person should be someone higher up the management food chain. But even if he's not your boss, you need to abide by his decisions.

Sign A Peace Treaty
Developers and IT folks will always have to work together. So it makes sense to do so in as amicable an environment as possible. Apply these principals, and look forward to exploring the Neutral Zone as allies, rather than enemies.

I'd love to hear about your own Neutral Zone experiences. Post your comments below, or drop me a line at . Live long and prosper.