What is the best practice when trying to group projects for reporting?

Question

We have a portfolio of applications and projects and we are trying to come up with a way to group projects into logical buckets for reporting, etc.

Right now we have the following constructs:

1. A project can have one or many milestones

2. A funding grouping when represents which funding bucket it comes from (LightsOn budget, Discretionary budget, initiative budget) so a project has to map to one of those categories.

3. Tags: A project can have one or many tags. This is just a label (like stackexchange tags) that allows people to provide metadata to projects so people can group by these tags.

Because #1 is very high level and in #2 a project can have many tags, we are trying to come up with another "container" to represent a stream of work of related projects. The reason we don't want to use Tags is that in this case we want a project to only belong to a single stream.

So the idea was to create a new container called "Stream" which looks like a tag but you could only select one of them per project.

I am just trying to validate if this makes sense and if there is another construct or container that would suit better as I feel like having initiatives, streams and tags can get confusing and i am trying to keep things as simple as possible. The alternative idea would be to have the idea of having projects have parent projects so instead of "stream" its just another higher level project.

Any suggestions around best practices when trying to group projects that is intuitive and supports the items above?

Answer 1

I recommend determining what you are trying to measure first, and then look at how you are organizing your project data. The answer is very likely that you'll need different groupings for different purposes -- financial forecasting, resource planning, etc.

I've found people quickly tire of micro-categorizing and you'll discover everything in the "General" stream -- knowing what you're measuring can help build safe-guards against categorization fatigue, too.

Answer 2

My bias is to group them by "primary" target audience. So maybe you have projects that are Sales-centric that will be in one bucket (e.g. projects to develop and release a new product), others that are IT-centric (e.g. install a new server), etc. This results in the generation of multiple reports, which can be shared with whatever overall audience you want even though your primary target is a subset of that overall audience.

Answer 3

Doug has it right. A report is for the benefit of the audience. You need to structure it so they understand and can make decisions. All other priorities are second to that. This question does not belong here. Instead, ask your stakeholders.

Answer 4

The answer to your question is - YES. It totally makes sense to have a bucket for 'work streams'. Every project I have been on in the past 15 years has had a work stream construct. No need to split hairs on the name either. Workstream is pretty common.

My assumptions -

• You said you are working with "applications" so I am assuming this is IT related.

• I think you've told us the audience, it's the workstreams and the team(s) associated with them.

Regarding "general" and flavors of "other" my practice is to simply not put that on the list. I talk people down off the "other" ledge all the time.

If the sorting thing of choice has more than say 8 - 10 options, what @Marina Martin said becomes true.

In my experience buckets come and buckets go. As we all know communicating those changes is key ...

I hope that answers the question, if so, please mark is accordingly.