Best way to divide & assign development work on projects?

Question

Currently I'm part of a development team which create software and web applications; And I get assigned to tasks randomly (kind of); most of the time I'm the only one working on a certain project, as other co-workers have another project assigned to them individually.

I feel that it is extremely difficult to keep to deadlines when at the same time you have to solve issues you come across, which you can't always predict a time frame for, and so most of my tasks that keep getting assigned to me start stacking on top of each other, and some being more important than others I have to sack most of the tasks given to me earlier on to complete the more urgent ones that came in late.

What is the best way to complete projects efficiently? Should projects be assigned to more than one individual, resulting in more projects overall to have no one actively working on them? Is it something I might be doing wrong? Should tasks by assigned by asking the development team who's up for it/who will be capable enough? Or who has less tasks?

How do you think employees in my position should be assigned in order to complete a project successfully with least amount of truble?

Answer 1

I'd strongly encourage you to talk to your supervisor about the project management practices your company uses. I've been in a similar situation, and it's much more effective to be on a project team, then to have to do all project work by yourself. If you have a team dedicated to a project, it's likely to be a much more solid piece of software than one written by a lone coder.

That said - what you're dealing with is a phenomenon I see where organizations assume that if every developer is doing their own project, that means more projects are being worked on, and more projects will get done in a year. The fallacy there is that what really happens is projects are delivered with lower quality, and end up incurring a good bit of a support overhead because the management team was under pressure to get more projects done. It sounds to me like your business needs to get better at prioritizing what "the most important things" are and re-align the development staff so that each of the "most important things" can have a team devoted to it. Also - it sounds like your organization needs to understand the difference between a "project" and a "product" - something that I've seen cause headaches in the past.

Once you've established those practices, I'd suggest running the team using some flavor of agile development methodologies. It gets any given team working out of the same project backlog, and also has processes in place for ensuring that backlog is accurately prioritized. At this point, it then becomes the developer's responsibility to best deliver on their part of a team's needs, instead of just being randomly assigned to "whatever's next".

Answer 2

TL;DR

What is the best way to complete projects efficiently?

There is no canonical answer to your question, because it is highly dependent on the organization, the skill sets of the teams, and the scope of the projects involved. However, it is safe to say that whatever your organization is doing is currently not working for you, and that's a valid point worth bringing up.

Projects Aren't Staffed by Algorithms

It doesn't matter whether your organization uses project teams, feature teams, or a "divide and conquer" approach. The central fallacy here is assuming that people behave like algorithms, and that your process problems can be solved by deciding between round-robin task assignment and least-used developer criteria. Such choices may work fine for a network load-balancer, but they fail miserably when applied to people or projects.

The 100% Utilization Fallacy

There is also another fallacy here. On PMSE, we call it the "100% utilization fallacy." This is a logical fallacy that assumes that the optimal use of team members involves keeping everyone busy at 100% of theoretical capacity, with no slack in the process. At a fundamental level, the fallacy is that being busy is functionally equivalent to being productive. They are not the same things at all.

Your Real Problems are Estimation and Prioritization

I feel that it is extremely difficult to keep to deadlines when at the same time you have to solve issues you come across, which you can't always predict a time frame for, and so most of my tasks that keep getting assigned to me start stacking on top of each other, and some being more important than others I have to sack most of the tasks given to me earlier on to complete the more urgent ones that came in late.

Based on your own description, your project is sub-optimal because the project team isn't doing an adequate job of:

1. Estimating work packages accurately.
2. Isolating new work from bug fixes or rework.
3. Providing sufficient slack in the process to handle modest deviations in the schedule.
4. Managing change requests or implementing formal change control.
5. Triage and prioritization of incoming tasks.

All of these are fundamental process issues. From your description, the only process that you seem to have is:

Pour all the work into a bucket, stir vigorously, then let the developers try to serve themselves with a slotted spoon.

— CodeGnome's Recipe for Project-Failure Soup

I'm not sure what school of project management that comes from, although I suspect it comes from the Dribble Glass Project Management Framework™. Regardless of its provenance, it's not a sustainable practice. Your mileage may vary, I suppose.

Recommendations

Process issues aren't about blame; they are about improving workflow and efficacy. You should certainly bring these issues up as process issues with your manager and your project management team.

Be politic and polite, but don't be silent. If your organization isn't interested in continuous process improvement, then you may want to give serious consideration as to whether it's a sustainable and healthy environment, and one where you want to remain. If not, dust off your resume and look for another job that has project management practices that you feel more comfortable with.

Answer 3

As already mentioned in another answer there is no Holy Grail answer to this question, but let me give you some food for thought:

Issues happen

This is not a real eye-opener, is it? Bugs, issues, defects or whatever you call them should not jeopardize the schedule, at least to a certain extend. Although rework is a loss of time, it happens in every (software) project and should be considered since the beginning. If every people - who are called "resources" in such a case - is stuffed with tasks at 100% capacity, any issue will make it 120%.

My advise here would be to identify classes of service based on urgency and criticity, and allow some slack in the system so that the team can expedite important bugs when they happen without killing the schedule.

"[I]ssues [...] you can't always predict a time frame for"

So what? You cannot crystal-ball predict how long it will take to solve a particular issue : is this really going to change the fact that the issue must be solved? If so then maybe this issue was not that important after all, and some other tasks could have had higher priority.

When running too many projects at the same time, none of them will meet the schedule.

Running too many projects at the same time produces at least two effects:

• People have to switch between projects. Switching from one task to another is hard. Switching between projects is harder by an order of magnitude. When switching, people lose focus, experience difficulties reminding about the context and basically lose time.
• People have to deal with too many things at once. The human brain is not multitask. When someone has to work on several work items at the same time, the quality of his work will drop significantly. Not a surprise that making phone calls when driving (at least in France) or chatting with your neighbor in a classroom are forbidden

My advise here would be to limit the amount of work in progress at every level of granularity

Pushing work

[...]and so most of my tasks that keep getting assigned to me start stacking on top of each other

Giving - pushing - work to someone is easy. When we tell someone to work on a specific task, we can then come back later and blame her for not having finished the assigned work, which is pretty comfortable, isn't it? But by doing so we blind ourselves : we ignore systemic problems and transform them into personal problems. The PM won't think "We have a problem with our process : we start too many things without finishing them..." but "This guy is really slow : look at how late he is".

So my last advise will be : implement a pull system and visualize work. A pull system will make sure that the team "stops starting and starts finishing" (a Kanban adage, I can't remember who said it first) while visualizing work might trigger some improvements in the way work is processed ("Don't tell me that we currently have 26 work items at the same time for only 4 people?!")

Hope this helps.