• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 365
  • Last Modified:

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).

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.
3 Solutions
Sounds like your IT organization needs to address the issue from a systemic standpoint

An this should fall under a "scope of work" category.  Sounds like you may not have a defined Scope of Services - something I would definitely push for from your IT director or equiv.

If you were performing this same work for a paying client would the client feel, say 2.5 hours at $100/hr working on some inane spreadsheet, was worth it?

In the past I built an internal IT department upon the idea of being a profit center.  With a simplistic model, we accounted for our expenses (agreed upon overhead, labor costs, and parts + supplies), and "billed" our clients for our time and materials just using a database fed spreadsheet (no pun intended.)  It quickly became clear where we were spending and wasting too much time.  That justified everything in our scope of work.

You may need to have some data about the actual time spent and with whom for what, and take it to the higher ups for some support.  With enough evidence of 'productivity theft' from your department, they may even produce the very document or proclamation you are looking for.
Dave BaldwinFixer of ProblemsCommented:
First you have to define what you do support for them in a written form.  Second, I suggest an hourly plus expenses rate for things outside that list with the option clearly expressed that some things will be declined.  Even if you're talking about an internal IT unit, you should be able to do that somehow.  The extra cost for these things let's the customer also decide how valuable it is.
I understand your situation ... but this is my take on this.

One can always take a hard-nosed approach with "policy manuals" - waste time and money on such things, and piss-off everyone concerned.

But the rule of the game is - the customer is NEVER wrong.  No matter what.  If you do not agree to this, then please stop reading this response.

I am sorry, as this may not be the answer that you like, but I hope that I am answering your question.

A good manager is the one who puts pressure up the chain ... a bad one who puts it down the chain.

As IT, we are supposed to know our (internal) 'customers' needs and make life easier for them.  If we take care of their needs, then no unnecessary macros will come up ... no unknown products will make it in.  After all, why are they doing these things?  To satisfy a need that they have with whatever tools they have or can afford ... even if it is with a poorly written macro.  If we had done our job (of taking care of their requirements), then they would not have come up with jack-a solution in the first place.

Now, why is it that IT does not have time?  Either because we are dreaming about working on fancy, new technology products - which are not really going to help our end users (they may be saving $s for the organization, but they do not help the end user in any way); or we are lazy and do not want to deal with our internal customers.  In either case, the end user cannot be blamed.

It is quite possible that we are too busy with work, we have too many projects that need to be done but do not have enough time for them.  If this is the case, then we need to take the problem to our managers, who need to go higher up and request for more resources.  This is the only appropriate thing to do in my opinion.

I tend to look at these "macro" writers as our assistants ... they may not be as savvy as us, but they do protect us from smaller issues by spending their own time on these things.  Sure, some of them will be arrogant to us, inconsiderate of us ... but that's a smaller price to pay as compared to everyone knocking on IT desks for every little requirement that they have.

Again, sorry, I am not giving an answer that you like, but I hope that I am answering your question.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now