Portfolio for JIRA Program and Plan Granularity

[Cristiano Mariano]

Hi guys! How are you doing?

We are evaluating Portolfio for JIRA and trying to define a work model that matches the concepts we use in our company and, at the same time, offer different views to the stakeholders. Our main concern is the granularity in which we should create our Programs and Plans.

We understand that Business people would like to see all the scope of changes in the business processes they work on. We first thought of creating a Program for each Business Unity and a Plan for each Business Process. The scope of this Plans would be a Project we created for cross-project Initiatives plus the Projects/Boards related to the systems that implement these processes.

On the other hand, we understand that IT people would like to see all the scope of changes in systems they work on. We imagined a Program for each IT Department and a plan for each IT Team. The scope of this Plans would be the Project we created for cross-project Initiatives plus the Projects/Boards related to the systems they work on. It would be very similar to the Business view.

And another view we would like to offer is one for Project Managers. They usually are interested in all work related to a specific Initiative, no matter what processes or systems are involved.

We did some tests on these 3 views and faced some issues:

- As Business/IT Plans would show all the work related to a specific Team and Project Managers Plans would show only part of it, the calculated dates would be different, as the Project Manager Plan does not consider all the work the Team is assigned to.

- If we create a higher level Plan for Project Managers that shows all Initiatives, we would solve this issue, but even so, some flags would have to be set the same way in all these plans, in order to make sure the calculated dates are always the same (whether Teams use Kanban or Scrum – and number of weeks in iteration - is one of them). This is very error prone.

- If we use only the Project Managers Plans (one Plan per Initiative), the IT teams would have to split their teams and capacity and make sure it won’t cause overbooks.

Now, it seems to me the best option is to create only one plan, that shows all work we have in the company. In my opinion this is not the best fit, because our company has a lot of users and give to all of them the possibility to commit changes in the same plan at the same time would certainly break things, but at the same time I don’t see another way.

How are you guys creating Programs and Plans in your companies? Any thoughts on this?

Thank you very much!

[Amanda _Praecipio_]

Hi, Cristiano! 

I've implemented Portfolio any number of ways with Plans/Programs, but each implementation has varied slightly based on the criteria of the client. I tell my clients one word: simplify. 

One plan is not enough. I think your idea of a Program per Business Unit and a Plan per Business Process is close. However, if you are splitting teams across Business Processes, this will not work. You've already seen that with trying to split capacity. It gets super messy really quickly. 

Because Plans are Team/Scope centered, you might try a Plan per Business Unit and surface the custom field you use to separate the Business Process (this is assuming your Teams do not cross Business Units). Playing with filters in each Plan may then allow each Project Manager to hone in on their project for a specific Business Process while providing transparency across the entire Business Unit. The Project Managers for the Business Unit will then have to negotiate the prioritization of projects based on all of the work the Teams have in front of them. Themes can help with that as well, but since they don't perpetuate across Plans and you have to work with them manually, if you have more than 60 Initiatives, this is painful. 

Shared Services Teams (like infrastructure or systems teams) may not fit into a Plan. This depends on your Definition of Done and when the Team says something is Done versus when the Business says something is Done. Again, since a Plan is Team/Scope centered, accounting for the work of the Shared Services Team must be done either 1) with the Capacity workaround across Plans that you mentioned above, or 2) changing the Definition of Done to Code Complete and Tested, but not deployed. You may be able to use Stages for this as well, but you will have to account for the extra work for the Shared Services Team in your estimates. 

A Program can then give the "Big Picture" for reporting across Business Units. 

If all of your Teams cross Business Units, you may want to look at that as an Organizational Change Management problem instead. Fix your Teams to Business Units (which in turn enforces the delivery capacity of the Business Unit). If your Teams constantly change in size and structure, Plans will require constant maintenance and will fail to provide you an accurate picture of "what's really going on."