How can I manage multiple large, parallel, distributed projects with different workforce commitment levels?

Question

I'm starting a Games Development club. I'll be thrown lots of people with their own skill-sets, commitment levels, goals, etc. I need to ensure they are pointed towards appropriate yet stimulating tasks, and hopefully manage to produce some finished products.

My current plan to deal with this is to have a website with listings of projects people are currently working on, and encourage people active in these projects to link all their work to the website. The system would have various functionality, but the basic idea is to help project members find people with the skills they need, and people with nothing to do to find a project task that interests them. The outcome would be that, even if a project died, anybody could continue it if all the work that had already been done was available.

My main concern is people dropping out and leaving half-finished work behind, but I'm sure there are other challenges I need to consider. I also want to make sure people can move between projects as they wish when their skills are needed.

How can I manage a potentially large, distributed, and fickle workforce in an effective way?

Answer 1

Your Question, Redefined

My main concern is people dropping out and leaving half finished work behind but I'm sure there are other challenges I need to consider.

There are many such challenges with any drop-in/drop-out resource matrix. Your question is broad, and not fully answerable in it's current form. However, I think it's answerable if you redefine the underlying problem that you're facing.

Specifically, I believe the underlying issue to be one of chunking. Whether you're talking about distributed computing or distributed project teams, the question of how to decompose tasks into discrete units of work, each of which can be performed independently, is a common one.

A Generic Solution

From a project management standpoint, there will be a large pool of potential answers to this question. However, at a macro level, they will all have some similar features.

• Work units are small and independent of one another.
• Work units are largely self-contained.
• Work units can be completed within a short, well-defined duration.
• Work units must be either done or not-done; incomplete work should not be turned in or reassigned.
• Work units need not be unique, and the same work unit can be handed out to more than one worker at a time.
• Work units produce outputs that are provably correct.
• Work units must not block; each work unit remains available to anyone until it is completed and removed from the work queue.
• Work units can produce identical work products without causing problems, and duplicates are acceptable project artifacts that are handled properly during turn-in, collation, or integration.
• Collation/integration of the completed work units is centrally- and actively-managed.

GitHub Repositories as Concrete Examples

If you think about it, this is how a lot of open-source projects are managed on GitHub. Issues are created, one or more volunteers pick a given problem from the issues list, and the issue is closed only when the maintainers approve a completed patch and integrate it with the existing code base. If someone starts work on an item, but doesn't complete it, the system keeps those same items available to others until the issue is marked "closed."

The one problem this model faces is that it can't guarantee that any given unit of work will actually be worked on or completed. However, that problem is implicit in your drop-in/drop-out model, and may require other incentives or project controls to address effectively.

Computational Examples with Project Management Implications

While more in the nature of computational solutions, you might want to look at the way projects like SETI@home, distributed.net, or BitCoin have attempted to solve these problems. Even if your problem is not computational, the packaging and integration of work units for these projects is the same class of problem that you're attempting to address.