Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 2 down vote favorite
1

I'm attempting to create a dashboard so that people not intimately involved with the project can get an indication of project's health. I'm struggling with determining what to put on said dashboard. I think it needs to be brief to be useful, yet complete. The project I'm working on depends on both 3rd party contractors, external hardware and of course my team's effort. Are there any suggestions or guidelines on how to encapsulate it all in a relatively easy manner?

Mods, I believe this question falls squarely between development methodologies and business concerns as outlined in the faq.

Thank you!

share|improve this question
While it might "fall squarely between development methodologies and business concerns", it is fairly broad and vauge. Can you expand your question and provide more detail? – Walter Nov 27 '12 at 0:09
Walter, I feel like I gave a decent overview in my opening sentence. My comment was meant to indicate that I read the FAQ and I still felt like this question was fit for programmer.stackexchange. Even though this is is not a technical programming question, it's still very related to what we do. I want something other than a velocity/burndown chart to show the customers and my boss the current status of the project. – EightyEight Nov 27 '12 at 0:57
1  
@EightyEight When you say "external hardware" do you meant that you would also like to track project status for hardware designers as well? What project management software are you using now (if any)? – maple_shaft♦ Nov 27 '12 at 1:18
1  
@maple_shaft well the hardware for the project is supplied in stages, test hardware then revision, then final hardware. It's a major piece of the overall functionality. We are not really using any PM software right now. We use JIRA to track defects and outstanding remaining features (similar to agile stories) that my team is responsible for. Dependencies are tough to track though and the business has a tough time understanding what's going on. – EightyEight Nov 27 '12 at 4:46
2  
If you want, you can expose your problem @ pm.stackexchange.com. I wouldn't suggest you to ask directly for a tool as tool recommendation is actually considered offtopic to the site, but if you put it in a way your present a problem that may be solved by a tool, then I consider it as a valid question... – Tiago Cardoso Nov 27 '12 at 17:09
show 5 more comments

2 Answers

up vote 4 down vote

I like a chart presenting planned completion date over time. I cannot find a good example right now, so I will describe it.

Both X and Y axis are dates. For each date on X axis we put on Y axis the project completion date as estimated on that day. The Y values will raise when tasks or milestones slip, or when we realize there's additional work (usually just discovered) that was not included in previous estimates. The Y values go down as we cut scope. Whenever there is a significant bump I would add a short comment explaining it (like "feature X slipping by 2 weeks" or "cut feature X" or "updated estimates for localization work"). This assumes you have a way of tracking the progress daily (in automated way) and you're honest about the data.

The chart works because it shows the thing that stakeholders are most interested in: when are we going to be done! It's value is in how it paints a dynamic view of how the team makes progress and how the team finds out hidden dependencies, surface issues, etc.

I would also think about having another line with known risks as of each day. If this line is not going down it will indicate, well that the projected completion date line is at more and more risk :-)

share|improve this answer
1  
Wow, that's a great idea. I can see how the expectation would be for the graph to have a negative slope, indicating that a project trending towards completion. Anything else would indicate potential issues... My only trouble with this approach is that it's too high level. There's no indication of which components are increasing time estimates and there's no indications of which components have been completed. – EightyEight Nov 27 '12 at 1:02
1  
To clarify - ideally the graph would be level, which means the completion date is not slipping. Negative slope would mean we're making progress faster than we estimated, which is possible but rare :-) The troublemakers are indicated by the labels put on bumps in the completion estimate - in my experience these things work best when highlighted intentionally, instead of auto-generated, as this is human-to-human communication after all. You could get fancy and have a bar-chart instead of line chart, and play with splitting the bar into "work done", "estimated work left for component 1", etc. – Krzysztof Kozielczyk Nov 27 '12 at 1:08
up vote 1 down vote

Managers here use an issue report which shows a graph of how many issues of each priority group there are over time, ideally this graph should be decreasing at a gradient in proportion to the amount of developers. A gantt chart may be worth looking into too.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.