Hi Teri, We have a similar setup, but we have our Landing Projects in the scenario as Team Projects (as opposed to Application projects). The reason is we have many many applications and about 7 Agile teams. One team will support several related applications (i.e. an ERP Team, and HCM Team, and of course a Workfront Support Team �� ). This keeps the number of those projects down and you don't have to create a new one for each new App. To address the Apps we have an Application field in the custom form of the requests that lists every App. Then they can select the App the ticket is for and we can report on Apps later if we wish (i.e. to see which Apps have the most tickets, etc.). But for the landing project I recommend (under Edit Project): Schedule From Start (Planned Completion Date field will change to Planned Start date) Settings (see attached) You probably don't need or want a Milestone Path (not sure why mine has one �� ) Completion Mode - to Manual (so your project doesn't automatically set to Complete when all the requests and tasks are completed) Summary Completion Mode - to Automatic so your Summary tasks DO close when the subtasks are closed Update Type – I like Automatic & Change Schedule – you'll want to use whatever Schedule you set up (i.e. if you have a 24 hour on call team, you might create and use a schedule with all those times open) Resource Leveling – I'd put manual. If you're using Agile, you shouldn't be in this project plan too often, you'll be using your Agile view. So this project is really just a holding place. Resource Pools – if you're going to use Capacity Planning you might fill this out. If you're not there yet, you can probably leave it blank. Access – I would use the settings in the attachment. But it depends on how you want to give access to people that get assigned to Tasks and Issues. This automatically grants permissions when they're assigned. I think those are the basics.
