Portfolio for Business Projects

[Deleted user]

I am new to Portfolio for Jira.  Besides Agile development projects, my company has implementation projects with partners and their clients, as well as internal corporate projects not related to any development release.  Before I started with the company, they created Jira projects to group these efforts, but timelines are not at the project level;.  Implementation projects have one issue for each implementation which has it's own timeline.  Internal projects have epics/stories/tasks with their own timeline and there can be unlimited epics/stories per Jira project.   

Three questions about Portfolio with that background in mind:

1. If the project doesn't have an end date, will this be a problem for Portfolio for roadmaps and scheduling?  
2. If an executive wants to see efforts (including resource usage) within a project based on a rolling period (i.e.,show me quarterly, show me the next six months, show me the past 6-12 months), is that possible?
3. How valuable is the information if hours/days aren't entered for each issue, but start/end dates are provided?

Thank you for your comments/advice for a new Porfolio for Jira user!

[Earl McCutcheon · Accepted solution]

Hey Robin,

First Portfolio is designed to work as an extension of Jira Software projects, however it still works with JIRA Core (Business Projects), but it looses all of the functionality around the Epic/Story relationships, Initiative hierarchies, sprints, and releases you get from Software project types that are not available in Core Projects and will ultimately affect the scheduling algorithm removing some of the major capabilities of portfolio, and the ultimate recommendation is to use portfolio on Software project types only.

For Questions 1 and 3 this ties heavily into the Scheduling behavior documentation, but ultimately the scheduling is going to rely on estimates and target start and end dates because the other data points defining the schedule are not part of Business project types (Sprint, Releases, etc..)

For question 2 Portfolio is designed to be a forward looking scheduling tool rather than a reporting tool on past items as covered in the following Feature Request to add in more historical data:

- https://jira.atlassian.com/browse/JPOSERVER-1267

This again ties into the Design of the application as an extension fo Jira Software where the Jira Software Reports  are designed for mapping the historical data and portfolio is the planning tool Forward looking.

Regards, 
Earl

[Deleted user]

@Earl McCutcheon, thank you for your response.  One sentence stunned me. though . Portfolio loses all of the functionality around the Epic/Story relationships?  The webinar I took seemed to indicate that wasn't a problem.  Can you point me to the documentation on the problems with Portfolio and epics/stories?

Thank you for the link to the Scheduling information.  I've barely started my in-depth research into this add-on which my company already purchased and expects to assist with corporate project management, hierarchical reporting and resource management.  I will definitely be going through that link carefully.

Thank you also for demonstrating that Portfolio is designed for forward-looking reporting rather than historical.  I'm going to have an interesting update for my manager.

[Earl McCutcheon]

Hi Robin,

There really isn't any documentation clearly defining this as the doc's at https://confluence.atlassian.com are noting what the application can do rather than what it is not able to accomplish.  The Closest thing really is This Document that describes the Default issue types created by each application, and This Document  Describing the Jira Core Issue Types (Task and Sub-task)

Additionally some notes in the Marketplace Listing:

"Made by Atlassian and speficially built to work with Jira Software."

And

"The agile roadmapping tool, built for Jira Software"

And additional reiterated in the Product page  that the tool is built for Jira Software and It ultimately comes down to portfolio being designed for Software but can be used at limited capacity for other project types (Business and Service Desk), as the alternate Project types have alternate use cases.

An Epics in JIRA Core is just another standard issue type as the Epic Functionality is built into the Software project type.  If you create an Epic in Jira core, you're creating a standard issue type with the name Epic but it is not inheriting the epic functionality for Agile built into the Jira Software application.

Regards,
Earl