Question

We have a series of short-lived, mostly independent projects. For instance we might be integrating with customer A's system this week, writing a new feature next week etc. These don't really roll up well into a series of releases of our product though so it doesn't seem right to simply have a "Product" project with a series of version milestones.

Once option I see it to indeed have a "Product" FB Project, then have a milestone for each project, "Customer Integration A", "New Feature B". However, the milestones are independent and FB seems to have a more linear view of milestones.

Another would be one FB Project per project, but then there would be loads of projects and they would have to be closed and it looks like FB only allows you to delete, which isn't what we want.

What would people recommend?

Answer 1

I've gone with the following workflow and it is working well for us:

One project, so "Professional Services" for example. Multiple areas, eg "Database", "UI" etc, for the different types of short-lived project we deal with. Then one milestone per project, eg "Customer Integration A", "Customer Integration B".

This works well for a few reasons:

• People know where to log cases, because the Project list isn't in constant flux
• Ultimately, projects do have due dates so FB's linear view of milestones is actually quite appropriate
• By assigning cases correctly, you do still end up with some developers working on the "next" milestone anyway, because they don't have any work left to do on the current one.
• We can see how one mini project interferes with another, because they all show up in the same reports.

I actually have a couple of projects because we have a few totally separate areas of our company where this pattern emerges, but the idea is the same.