I work in a large company and most coding projects are fairly structured with a project plan and review process.

However, for existing support there are occasional periods where a department will need lots of tiny changes made to an existing app or site such the accounting department at the end of a fiscal year.

The problem is that they get incredibly busy and my team gets a slew of tiny emergency changes thrown at us. We need to be flexible enough to support their needs as they are real and provide a great deal of value to the company. On the other hand, given how crazy their environment is, they sometimes give us contradictory changes (change the text to 10pt, then the next day change it to 12pt).

Again, the changes are trivially tiny but they can suck up a developer's day given how frequent they are. I'd like to push back and set some fair limits for how we'll handle these requests going forward. Is there a best practice for handling these types of small changes? The department in question is far to busy to commit a lot more time to working with us. We also don't charge back so it's hard to communicate the problem to them. What's a good approach to resolving this?

2 Answers 2


One thing you should definitely consider is that they too may be reacting to lots of time critical requests. Taking your example of "change the text to 10pt, then the next day change it to 12pt", unless you have reason to believe that they are deliberately screwing with you, which it does not seem like they are doing, then think about why are they asking for these changes? Is it because someone is asking them for these changes?

Perhaps the outside auditors are placing demands on the accounting department at year end? Perhaps they have to comply with changing outside reporting requirements?

My suggestion would be to meet them when they are not busy (and definitely not at year end) to understand what they are going through. If they, like you, are feeling pressure at year end then perhaps the best solution is to develop a joint staffing plan where you schedule someone from your department to be available to meet these "emergency" requests and they assign someone from their department to act as the liaison to work with your person. If in fact the work being done is of high value to your company, then you can gender a lot of good will by helping them in this way.


I've found that if you sit down and agree with users on a fixed cycle (one or two weeks), explaining it as necessary so that fewer bugs are introduced because there is more testing, users usually agree and start prioritizing their requests better.

Two weeks are better because it would give you one week of coding and one week of testing (users actually seeing all the features they asked exactly how they asked). Another advantage is that users themselves get less distracted by just sitting down once or every other week to see all the requests done.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.