Question: Is it possible to manage IT maintenance operations like a project, with typical project management mechanisms including scope, time, and cost planning? In our project we experience difficulties in such a management of our IT infrastructure support department. We don't know how to define their scope, how to control it, and how to make sure that the work is done. They are not developing any software but organizing our server space. Sometimes (and very often) their mistakes severely affect the entire project. I'm interested in finding some formal or semi-formal instruments on IT department management and coordination with the rest of the business.

Answer: 
There is a danger in trying to use PM methodology to manage an operational process. PM methodology - waterfall, agile, Prince2, whatever - is designed to deal with temporary endeavors. 

I suggest you build the processes you need to make thinks happen in the support department.

If you are unfamiliar with process development, you can find all kinds of resources on line. The basic steps are;

1. make a list of everything your department needs to do
2. organize it into process groups
3. document the steps for each process
4. start improving the processes
This may be considered as a project itself " **IT Operations Alignment**".

In order to manage the service delivered by the IT Support Team you will need liaise with the Team Lead to understand the following:

* Current ***Process Logic for IT Operations*** (planning, approval requirements, etc...)
* Current ***Service Level of Agreement*** ([SLA](http://en.wikipedia.org/wiki/Service_level_agreement)) to deliver solutions
* ***Resource Availability*** (remote teams, on-site testers, etc...)

Once you have gathered all relevant information regarding their processes try to match these with your own ones and identify any gaps or areas of improvement. 

1. **Document Agreed Business Process and Operations/Projects** - defining the scope of your business/project and where their support must imply.
2. **Agree a Service Level of Agreement** - for an estimated timing of resolution according to the severity of the issue/requirement.
3. **Define and classify the defects or incidents** according to the timing agreed on the SLA; *e.g. Critical issues to be resolved in less than 24h, Critical incidents can be unavailability of the system or servers down. Moderate issues to be resolved within 72h, and so forth...*

Finally, I would also recommend building a **robust defect reporting mechanism** which interfaces with IT. A good example could be eTracker, Jira, or SharePoint. By using these tools you can raise items according to the agreed scope and track the progress, flag concerns, escalate unresolved issues to senior management, and so on.

On a separate note, I would also consider that depending on the complexity of the teams and/or the business the maintenance of this relationship between IT Support and Operations may need to be managed by a separate role.