I'll take a [very slight] segue from support costs to talk about one aspect of running this web team which I find difficult... How do you strike a balance between working on new projects and maintaining the older ones?
We have lots of older applications that are in constant use and have a large amount of feature requests. When those features are urgent we usually get to them immediately. However, the vast majority really aren't urgent - they are nice-to-haves, wish-lists, or corner cases... But they pile up.
Now, many of these are trivial, so it seems like we could just quickly fix them and move on. But any coder will tell you that context switching can be very detrimental to performance, especially when you're "in the zone", so to speak. So what do you do? Ignore these little requests, and you'll soon be left with hundreds of feature requests in your queue. Pay them too much attention, your new projects grind to a halt and you end up missing all your deadlines.
We're tried three approaches:
- Spend 1hr of each day (for example) working on small items.
- Take a few days/weeks after each project to clean up the small items.
- Attempt the above two, generally fail, and end up having a large queue of small items anyway.
We seem to be pretty good at #3, but the first two are not as simple as they seem. #1 assumes that you can split your day into periods of calmness - spend an hour here, seven hours there. The truth is that often throughout the day you're being pulled in different directions, and it's often impossible to set aside periods of time. #2 ignores the fact that it's difficult to put aside new projects (which are usually high priority) for a few weeks. How do you justify to customers that you're going to spend a month dealing with tiny issues that don't have much payback?
At this point, I'd give some brilliant solution to this problem. It would be simple, practical, fool proof. You'd be amazed! ...Unfortunately, I've got nothing 🙂
What about you? Any ideas?