We have a pool of technical resources consisting of some front end developers, back end developers, graphic designers. Those resources are separated from clients directly by one or two account people per client.
Requests from clients come in through the account people and get sent to our synchronization manager. The synchronization manager keeps track of all client projects and has a basic idea of the workload for each resource. His job is to assign work to resources based on priority of the project and the resource’s familiarity with the project (to some degree). Currently, the majority of this data/logic is handled in a complex excel spreadsheet. We revisit the schedule every week on Monday so that people have a clear idea of what lies ahead for them.
This type of system works ok for linear projects that have a longer duration, but starts to fail when there are lots of little projects/tasks happening concurrently. Many times, tech resources are “lost” when updates come to the schedule mid week. Not to mention when there are “urgent” requests that supersede the existing schedule.
How do you handle assigning workload when you work with multiple clients on a daily/weekly basis? Is there any software that you recommend to help with scheduling / determining resource availability? Please keep in mind that priorities and projects change frequently, with us not really knowing what is going to happen 1-2 weeks out from the present.
Sounds to me like the classic consulting conundrum: hitting that sweet spot where the fewest resources generate the most revenue.
The first question that comes to my mind is: how much pain is this causing? Grumbling from amongst the developers? Complaints from upper management? Furious clients? The solution should match the level of trouble caused.
The simple fact that you can’t know the unknowable when it comes to schedule interruptions means that, in large part, there is no software fix to this problem. You have to build in enough room for those unexpected demands ahead of time and be ready to reassign on the fly.
It also bears mentioning that the seat-of-your-pants model, in which developers jump every time a client says boo, is a choice. It doesn’t necessarily have to be that way if everyone is willing to consider other options.