For reasons "above my pay grade", we're developing an issue/project tracking system where I work (similar to Trac, FogBugz, etc). The managers want a useful tool to be able to track the overall health of the project (e.g. How much time left, how are we performing vs estimates) and one of the features that has been requested is some type of critical path support and visualization.

The logic explained to me is that they want to be sure that at least the most important pieces of the project are currently being worked on. The initial idea was that we would create task-based dependencies. My understanding of project management tells me that this kind of granular approach is unnecessary - having milestones with specific deadlines/dependencies is much more useful.

I would like to know what are the most useful techniques and "pretty pictures" you've seen/used for project development. Having objective data would be best, but somewhat subjective data is helpful too.

  • 1
    This might be offtopic here because as worded this could apply to any IT project. Perhaps you would get better answers at pm.stackexchange.com – maple_shaft Nov 14 '11 at 20:16
  • 1
    Odd... why not just write a data visualization for your existing project tracking system? – Steven Evers Nov 14 '11 at 20:39
  • Ah, I forgot that the pm exchange exists. I'd migrate it if I could (and I checked the vote to close and the option wasn't there) – Wayne Werner Nov 14 '11 at 22:05

To be successful in this task, I would proceed as follows: (1) Specify KPIs to be presented for each type of management level (I guess in your case, you will have 1)

(2) Distill KPIs (e.g. LOC is to be avoided as indicated by bethlakshmi's post). Also, you need to ensure that the data reported is something you can produce or calculate accurately using the tools you have.

(3) Determine how you plan to collect, calculate and accumulate the data up-to-date and make sure this process is counted for in your project plan (sounds like a data-mart work)

(4) Specify the best representation to use to present the information (this is what your question is about) and do a prototype the looks to be approved by managers.

I would recommend a dashboard style presentation (see sample image below - I know it is not fancy!) enter image description here

A better one can be found at Telerik-TeamPlus Tool

Now as per (4), you have already identified some KPIs. Next thing is to categorized the KPIs in groups (e.g. Overall Status, Financial Status, Staffing Status, Task Status) Each group could be represented by a screen/page/Excel tab, etc.

In addition to Burndown charts mentioned by other responders, you may want to Use 1 or more Gantt Charts to show: 1 - Overall very high level project dependency 2 - Milestones for the on-going reporting period and its neighborhood (say current month and 1 month before and after)

Software to use and visualization capabilities greatly depends on what you have, what you can afford, where your current data is, how do you plan to publish the information, etc.

The list to choose from is long (Telerik-TeamPlus Product, MS-Project, Zoho Reports, Zoho Projects, Project Dashboard, among others of course)

|improve this answer|||||
  • I accepted this one because it detailed specific steps to accomplish my task at hand, plus gave several examples of other projects. Thanks! – Wayne Werner Nov 15 '11 at 16:13
  • @Wayne Werner: Thanks. If its not too much to ask, I am very interested in this topic. If you get to find a good solution, it would be great if you'd let us know about it. – NoChance Nov 16 '11 at 0:30
  • Presuming that I remember, I'll come back and update this with what we've learned. If I haven't posted anything in a month or so you can assume I've forgot - just comment on this post and I'm sure I'll see it in my SE inbox. – Wayne Werner Nov 16 '11 at 14:12

I'd say some of this relates to your corporate culture and the aspects of development that you need to measure most. No one can measure everything, so you have to find and monitor the sweet spots that are most likely to benefit your business.

Here's a few I've found helpful at various times:

  • Burndown charts - for Agile project especially - requires that developers are constantly evaluating and reporting their status, how long tasks will take to complete and the entirety of tasks in a short cycle. If you are doing a waterfall development process, burndown for a phase can still be helpful, but only if the status reporting is really accurate - often waterfall projects are so burdened with paperwork that getting a straight status-related answer is painful and even impossible, which greatly reduces the value of this type of chart.

  • Bugs found/fixed per unit of time - useful especially in situations where high quality is needed - usually a chart with # bugs on the horizontal access and time in units (like weeks) from left to right. There are two lines - # of bugs found each week, # of bugs resolved each week. In a typical waterfall process, this will show - a steady and then a sharp rise in bugs found per week, which eventually tapers off as testers start hitting diminishing returns (in other words, they have to get more and more creative to find those last few bugs). Then the # of bugs fixed line will at first keep pace a bit behind the # bugs found. Eventually it will lag as a backlog is accumulated and the fixers are slammed with work. As the testers slow down, the fixers catch up, and the two start to asymptotically approach some final point. Somewhere around that flattening is when the product can be released - different companies have different metrics for what level of this is alpha, beta, etc. This works well in a waterfall, tradtionally driven process, where quality expectations are high and the requirements are considered sacred. Gets harder in sprints where you are changing the requirements every time.

  • SLA type metrics - how fast is the team responding to issues? I know less about this type of monitoring, but in a QA of a live system with actual users, this is king - no matter what your development process is, the nature of how you support customers will define the perception of your product's quality, so responding to, communicating with, and fixing problems for customers in a timely manner with a minimum of cost is a big deal.

As an anti-recommendation - if I had my druthers, I'd avoid anything having to do with "lines of code" (LOC) - such as SLOC (source LOC), ELOC (estimated LOC) and other horrible acronyms. Some companies are stuck to this form of metric, because 20 years ago, it was the way it was done and they have a huge historical repository. These days, the meaning of 1 LOC and the work required to develop and sustain it can change radically and constantly - not just as programming languages evolve, but also as APIs change, how auto-generated code is created and maintained and other aspects of programming work. Every time I see a system of metrics with LOC at it's base, I shudder, because I never see it yield accurate results and I see an unbearable amount of time expended trying to justify this lack of accuracy. Most LOC related systems focus on the turn around between the accuracy of predictions (how big? How hard to make?) in comparison to the actual outcome. I think there's better, less formal, ways to do this -- like story points -- that will yeild good results. The key to any prediction-accuracy tracking system is that the people making the predictions need to have a palpable way of experiencing the accuracy of those predictions if they are to be better estimators in the future. For me, estimation in man-weeks or story points has been just as useful...

Note - I don't disagree with metrics about prediction accuracy - I think those can be incredibly helpful - especially in a constracting environment where prediction and customer expectation setting are a big part of the project's success.

|improve this answer|||||

Personally I think the different kind of burn-down charts used in agile projects are incredibly powerful as they answer the basic question of "if the project continues to run as it has, when are we done?". In projects I usually use burn-downs for the current sprint and for the entire release. Estimates used to produce the release burn-down are of course less exact but all in all they tend to predict the delivery pretty well.

|improve this answer|||||

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