Question

I have been using FB for a few years now for my personal project managment and issue tracking. I am about to introduce it to my company and I need a little bit of help on how to handle the following scenario:

There is a Software development team (SW) and a Project Management team (PM) that belong to different business units within our organization. The PM team takes internal Client (other BUs) requirements and may decide to proceed with some of these. So it passes a request to the SW team together with design templates and other files for development. As you can imagine, there might be a lot of communication back and forth until the project is done.

The two (or more) teams should have separate "workspaces" so that they cannot see each other's internal case workflow (projects) but at the same time be able to exchange assignment of cases; thus keeping the whole communication within the system (no separate emails).

For example, a PM person should be able to create and assign a case to an up-for-grabs user of the SW team (ie SW-Inbox) and sometime later get a response (case is reassigned to him) for approval or further communication.

I imagine we can handle the above scenario with a single fogbugz instance but I am not sure how to set up groups and projects.

Any suggestions ?

Answer 1

James beat me to it... separate Groups with a small sub-set of users with multiple Group membership to shuttle Cases between projects is one idea. Whatever you do, I'm sure you will need that sub-set of users who have access to multiple groups.

My other suggestion is to use mailboxes. You can set it up so NewCase@yourCompany.com, (or Bug@..., Feature@..., etc) is linked to a particular project, which in turn is configured for a particular group. Project Managers would send an email to one of those mailboxes and a case would be automatically generated. Correspondence between the developer and the PM is tracked in the Case, as long as they use Reply in the actual Case and send to the same mailbox with an unchanged Subject line. FogBugz creates a "ticket", which is a URL to a special view of the case that contains only correspondence, not developer's comments.

We use this method for external customers, who we do not set up as FogBugz users. So, in the case of internal users, you might want to pursue answers to these questions:

• the "ticket" works for non-users - anyone not logged in to the system. what happens if a user is logged on but in a group without read access - will that user have access to the case view that includes only the correspondence?
• You said your initial request from the PM group to the dev group carries number of files with it... how good is the mail handler at taking attachments from your email and putting them in the case? (since you are dealing with internal users only, maybe you could put design templates and other information in a Wiki article and link to that from the case).

Answer 2

Here's what I would do.

Set up a group for (and named) Development, and another group for (and named) Project Management. Customize the permissions for each group to include only the required members.

Each development project (you may have only one) should be assigned to the Development group. Also create a project, e.g. Project Management, for project management to use.

The workflow is a little cumbersome, but cases can be moved from one project to another by anyone who is a member of each group, or administrators. You may also want to set up a shared group (which gives full permission to all members) to which members of either group could assign cases, for use during interim periods during which there is significant back-and-forth communication required.

Answer 3

Grouping projects together can provide 'people teams' but has significant overhead if you have many GROUPS a lot of USERS. We currently have over 450 USERS and a dozen GROUPS. Managing 450 x 12 permissions is significant overhead with lots of room for error. It would be helpful if Fogbugz supported TEAMS of USERS like it supports GROUPS of PROJECTS. That way for large installations you could assign a USER to 1 or more TEAMs and assign a TEAM to 1 or more project GROUPs. For installations that don't need TEAMS thre could be 1 default TEAM just as there is currently 1 default GROUP.

Answer 4

Another Idea - can we use the "Area" field as the team? That is, create areas as "FW Team 1" or "infrastructure team". The drawbacks are

1. is that more information is needed to be entered title and description.
2. Every project has to have this area.
3. Not very intuitive.