What is the best project status dashboard widget?

[James Barwick]

I need a project status dashboard widget that accurately (?!?) lists all projects that I have access to with a gauge for their risk factors. Yes I see a cross project widget exists, I have it up, but is it good enough? What is everyone using? The last time I demo'd jirga to management I got yawns and no buy-in based on what I came up with from a management reporting perspective. Any ideas?

[Norman Abramovitz]

Take a look at the eazyBI Jira if management reporting will get you over the hump.

https://docs.eazybi.com/display/EAZYBIJIRA/eazyBI%20JIRA%20Plugin%20Documentation

[James Barwick]

I tried easyBI before. Perhaps I need to learn a bit more, but I found the interface confusing for users to use and a little messy. But perhaps this was just the build screens. I will look at it again.

[Norman Abramovitz]

In my opinion, EazyBI is not meant for the end user to design their own reports, but for engineers to design their reports for end users to use. Its data model is quite powerful as long as you have good data to work with.

You would not expect your management to actually build the workflow, but they would use it and provide input for the workflow.

[Nic Brough -Adaptavist-]

That depends entirely on how you are recording risk factors and what you want to see in your management reporting.

There's a lot of variation in what I've seen in a lot of client sites, but it really does start with asking the managers "what do you want?".

[James Barwick]

I want to see a list of projects and get a good visual of if a project is at risk of not being completed on time (Version release date target).

Also, if I have a set of n requirements, I would like to know if the tasks for those n requirements along with the test plans for those n requirements have been completed or will be completed or are at risk of not being completed on time.

Standard stuff guys. I can't believe we have to recreate the wheel over and over and over. But, I would love to know about the variations you have seen. Can you describe them (briefly)?

[Nic Brough -Adaptavist-]

Mmm, a lot of it depends on how you're recording it. If, for example, you're using time tracking and estimates, it's a doddle to get out "we expect to get this much progress done", but you might be doing it with the Agile plugins, or you're only using parts of it.

When looking at requirements, are you doing them as stories? Main tasks with subtasks? The RMsis requirements plugin is quite good for a couple of my clients, but you need to think how you're estimating/planning those too.

It's not so much a case of re-inventing anything, it's more the case of what you're currently doing (whether it's in Jira already or you want to map existing human process into Jira) and how to make Jira fit your needs.

[Norman Abramovitz]

Actually, it is not standard stuff since Jira allows you to do things in multiple ways.

You can use a gnatt chart, but someone needs to setup the relationships between the tasks. Are these tasks issues, sub-issues, hierarchical structure of issues?

How are your requirements defined in Jira?

Are your engineers reporting their times correctly? Have you accounted for their overhead in your estimations or not? Have you built in checkpoints to verify the engineer's progress?

Are you using the 'Agile' approach? Are you using the peer programming approach? Are you using a different approach?

How and what your numbers mean changes based upon the data model?

You don't need to recreate the wheel, but we need to know which type of wheel and its structure (wheels spokes can have different number and style) to give you a better definition.