Having working in multiple Fortune 500 companies as a Project Manager, and IT Delivery Manager, the head of a Production Support team, and certified in CMMI process I can tell you there are a number of questions that need to be understood before your formal structure can be fully defined. From the perspective of a 10,000 foot view there is always a starting and ending point that need to be tracked plus managing the tasks in the middle. For example, How / what initiates your IT requests? Is there a central way these efforts are communicated? Are specific approvals needed before the work can start (aka, is there a budget to do the work). Is an estimate needed first or do you go right to project? Who manages the project? How do the impacted teams get identified / notified? Does scope creep ever happen? if so, how does that get approved / paid for.? In essence, there are a lot step by step tasks that can be thought through and grouped together into logical components and recorded for tracking purposes in a spreadsheet. Ultimately your goal is to create a repeatable process with the proper oversight to ensure time / cost / quality / scope are as expected. Once you understand the tasks, you can identify who is responsible for the oversight. And then you can document the process. Some people may suggest creating the process first and assigning responsibility second, and id'ing the tasks third. Either way, having a formal structure to your projects (without overkill on the process) will serve your company well. Any need to discuss further let me know...