views:

156

answers:

2

Our current project has a large team, and we have come near the end of the project

Like most end of projects, dozens of dependencies are popping up - everyone is waiting on someone else to complete a task. What is the best strategy for dealing with this.

I have thought of scaling the size of the team down, so the depenencies can be done in parallel by the remaining members of the team, but I'm looking for ideas that will include keeping everyone on the team still.

+3  A: 

The only way I know how to handle this is to split the team in two. If you're lucky you can set the other half up to work with the next release. The message to BOTH teams is that the release version has priority over work on the next version. So the people who're working on the release version can enlist people from the "next" version as long as there is a reasonable need (this is normally related to different areas of expertise, who worked on the code in question).

Normally we only let the team working on the release version get advice from the people working on the next version, so the people working on the next version will typically give up an hours work without any discussion. If they should be pulled back into developing the feature we normally let that be a managerial decision. Most of the time these things are just obvious.

krosenvold
Good idea, do you then branch the code base in the version control system? What other factors need to be considered?
Saul
Yes. We generally let the release version be the branch in svn.
krosenvold
A: 

It's the ole' line them up and knock them down approach. Make sure you're really at the end of the project and not uncovering any missing deliverables, prioritize the deliverables and based on the top priority items determine the remaining work, dependencies, etc. Priority could be based on most value of the deliverable, most costly resource or resources likely to move on sooner then later. If people are waiting and have nothing to do, it's time to delegate end-of-project documenting tasks...(someone has to do it).

meade