Professionally decline to assist with unsupported products
G'day experts,
Much like most works sites our IT ecosystem is a mish-mash of different technologies and initiatives that have sprung up over the last 30 years.
A consistent problem for our internal IT team is being asked to 'fix' a Microsoft Excel workbook that a random unknown employee outside of the team has set up some time in the dark ages that a team of 20 have grown to use every day and now 'rely' upon. Sometimes it's an ODBC datasource that's missing, or a macro that refers to a file that no longer exists, or (most often) it's just so poorly put together that the slightest deviation in conditions causes the whole thing to stop working.
We didn't build these things. They're not part of the services we actively offer to the internal customer base. They just sprout like mushrooms whenever someone has a bright idea and think they know how to use Excel.
Nominally it wouldn't be a big deal, but some of these workbooks are monolithic and horribly spaghetti-style complex which means it can take hours to deal with some of them.
In much the same flavor occasionally some internal customers will ask we solve a problem with some third-party product they've bought and installed without letting us know.
In both cases we ultimately spend more time poking around trying to understand how they fit together than actually resolving problems. And all the time we're spending on peoples little pet systems is time that we're not spending on higher priority systems that actually add value to the business.
I feel that if we don't clearly draw a line in the sand then our team is going to have a never ending expansion of our scope of responsibilities (without increasing resourcing to match).
It's important that we don't sound like we're just lazy and are fobbing them off.
I need a way to respond to the individual requests and hopefully some way to communicate to the work site where the line in the sand is.
Background
Much like most works sites our IT ecosystem is a mish-mash of different technologies and initiatives that have sprung up over the last 30 years.
A consistent problem for our internal IT team is being asked to 'fix' a Microsoft Excel workbook that a random unknown employee outside of the team has set up some time in the dark ages that a team of 20 have grown to use every day and now 'rely' upon. Sometimes it's an ODBC datasource that's missing, or a macro that refers to a file that no longer exists, or (most often) it's just so poorly put together that the slightest deviation in conditions causes the whole thing to stop working.
We didn't build these things. They're not part of the services we actively offer to the internal customer base. They just sprout like mushrooms whenever someone has a bright idea and think they know how to use Excel.
Nominally it wouldn't be a big deal, but some of these workbooks are monolithic and horribly spaghetti-style complex which means it can take hours to deal with some of them.
In much the same flavor occasionally some internal customers will ask we solve a problem with some third-party product they've bought and installed without letting us know.
In both cases we ultimately spend more time poking around trying to understand how they fit together than actually resolving problems. And all the time we're spending on peoples little pet systems is time that we're not spending on higher priority systems that actually add value to the business.
I feel that if we don't clearly draw a line in the sand then our team is going to have a never ending expansion of our scope of responsibilities (without increasing resourcing to match).
The query
What is a professional way for us to decline to work on these requests on the basis of them being exceptionally low priority and ultimately unsupported by the team?It's important that we don't sound like we're just lazy and are fobbing them off.
I need a way to respond to the individual requests and hopefully some way to communicate to the work site where the line in the sand is.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.