How to organize team resources with ever changing clients / project requirements

Question

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.

Answer 1

Use an issue tracker such as JIRA

Answer 2

Personally I would take a look at using a Scrum board. This can be accomplished with a physical wall, PowerPoint slides, or Bugzilla.
Try the following:
1. Assign each tech to a cell
2. Assign each tech x amount of job/task give each job/task a priority level.
3. In the slide/wall create your different stages of To Do, Test, Very, Done and have the developers move them across the stages to give greater visibility of the tech and the projects.

Answer 3

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.