IT Employment

General discussion


# of Change Requests per promotion metric

By Patty100 ·
Does anyone have to deal with a metric that looks at the number of Change Requests used to document a promotion?

If we don't have at least 5, then the entire team is 'dinged' on our reviews.

This not only includes software defects (coding bugs not found in testing), but it also includes year-end maintenance, software changes dictated by company policy / procedure change, federal / state changes, the user with power that screams loud enough to get their small enhancement promoted asap...

The Leads in the department are trying to get this changed, but we have to come up with metrics that would help prevent continual 'small' promotions from occuring.

Any suggestions?

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Change Advisory Board may work for you

by dafe2 In reply to # of Change Requests per ...

Are you using Remedy to drive some of your Stats? I think your using the work promote the same we use the word escalate - meaning to move to another support level or onto a different project scope?

This may give you another view..or some ieas....hope it helps: (I'm describing the way change managent is used in operations. We've recently moved Application support into the CAB for the issues I believe you've described)

Our stats are drive by three PI's or performance Indicators:

PMO - Project Management Office
High Priority - Important Change, Low user Impact
Emergent - High Impact
Remedy - Standard Change RFC

Implementing a CAB (Change Advisory Board) and involving stakeholders from key Business Units to the CAB meetings give focus to High Impact Change requests and keeps small RFC's as FYI stuff, including the political ones.

Another way to drive a metric may be to implement a formal RFC process. Only recognize written request and escalate as necessary through the CAB. In our case, when everyone sat at the CAB the FYI stuff remained exactly that & did not impact the operations team - just the PMO as it should in our case. In this case, the only change that are "escalated" are those that are implemented unsuccessfully.

You may already do this. If your not using ITIL as your framework (I suspect you are) the following link may provide some other ideas for you.

Try here:

Related Discussions

Related Forums