Separate project to manage initiatives in Portfolio

Kenneth Young

In the Getting Started page on how to orgainize issues sources, it mentioned

"If you plan to use a custom hierarchy such as initiatives we recommend you create a separate project and store those issues independently. In that project configure the issue types and, if you do not already have one, create an issue type for your custom hierarchy issue type. If you’re not using a custom hierarchy, you can skip to step 3."

Are there any solid reasons to use a separate project to track Initiatives independently? Are there any drawbacks to have one single project to manage all issue types including Initiatives? What are the pros and cons? 

Thanks in advance.

 

 

Walter Buggenhout

Very often you will want your initiative (or program or portfolio) level issues to be visible to a separate and maybe limited set of people.

There might be an ideation or approval lifecycle process behind the issues and you might only want to release them to be actually worked on after approval. Keeping them in a separate project saves you a lot of hassle in managing visibility and/or access to them.

You also avoid that people by accident start creating issues of the wrong type in your operational project, which clutters your overview of a strategically important piece of information.

So it's really just a best practices thing, making things easier to manage.