Hello all This is my first post. I'm the lead and sole member of a newly formed group called Improvement Management in our IT Department. We have approximately 200 employees in our company's internal IT group which includes operational teams that install, develop and support: desktop / server, WAN / LAN, structured cabling, voice communications, application development, web-services and a support desk call center. Recently, we've been struggling with process improvement initiatives and in particular, the importance (or not) of defining a Project vs. a Service Request / Work Order and Incident. Incident is pretty straight forward and everyone seems to agree that this is a break/fix event. The stalemate ocurrs around Project and Service Request / Work Order. Does anyone out there make a distinction in their organization between these two? If so, what hard and fast boundaries have you set and what useful process differences does that produce? Additionally, are useful metrics / reports produced as a result of these designations? Thank you for taking the time to read my post. Rich Nacinovich Arizona Department of Transportation Information Techology Group Improvement Management Saving Changes...
I have to wonder about the value of distinguishing between the two. If the work for both is being done by a shared pool of resources, then the pipeline through which they pass could be managed appropriately, without artificial distinctions. For that matter, floating gaps in the flow of planned projects/work orders could be maintained to deal with the "unplannable" nature of your "incidents" as well. A basic multi-project management process can easily be used to manage such a pipeline. Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
I have to agree with Frank. I would treat everything as a project and develop criteria for determining its priority. There is a template on gantthead for priority optimization. It uses about 15 criteria to evaluate and rate projects. As far as metrics go I would stick with on time and on budget to start. Then I would add softer items that deal with the cultural aspects of how projects are conducted and relationship management Saving Changes...
I would not so much worry about on-budget as a metric, since your overall operating expense (budget) for the total service provided is probably fairly fixed for the short run. On-time (as promised) is probably more important to your customers, but even that is a secondary metric (with budget as tertiary).
The key metric of major interest to your customers -- where they get the most value from -- is probably more related to speed than to hitting a particular calendar date. You can keep all the promises you want, but if those promises are too far out in time, the organization you serve won't be getting maximum value from your efforts. Average response time, project cycle time, and rate of completed projects are, in my opinion, more important metrics for such an organization.
Information is not knowledge,
Knowledge is not wisdom,
Wisdom is not truth,
Truth is not beauty,
Beauty is not love,
Love is not music
and Music is THE BEST
