views:

132

answers:

4

we have an organization that has about 50 different software projects going on (about 90 developers). some big, some small. some are front to back solutions and some are building on top of existing solutions and technologies.

some of these projects are new initiative and some are incremental improvements over existing software that we built.

our senior management is looking for a sleek way to visualize all the projects going on including:

  1. Size of effort in time and resources
  2. ROI expected from the work
  3. Indicate incremental improvement versus new initiative.

the reason is that we probably want to move resources around to ensure top ROI but not all developer are fungible depending on their skill set.

in my head, this results in some type of heatmap or dashboard, but i wanted to see if there are any recommend solution or tools out there that attack this area.

right now we just have spreadsheets listing out each project and resources and somehow it doesn't really give a good visualization of whats actually happening.

any suggestions?

+1  A: 

G'day,

Have a read of Johanna Rothman's excellent book "Manage Your Project Portfolio" that addresses this very issue by providing an approach to evaluate multiple projects to determine a priority.

Edit: I forgot to say that I'm applying the technique myself across multiple work streams atm.

HTH

Rob Wells
+1  A: 

Agilefant is an open-source tool that "brings together the perspectives of long-term product and release planning and project portfolio management", and is being actively developed. I would try the 2.0-alpha release (accessible via the Downloads page) for improved visualization tools, but you can also try the live demo to get the idea of what Agilefant can do.

Eemeli Kantola
+2  A: 

A classic consultant's technique... I would start by plotting them on a 2x2 graph. Make the vertical axis the ROI, with high at the top, make the horizontal axis two partitions of incremental improvement on the left and new initiative on the right - and I bet there are some projects which are a bit of both, so maybe you have a continuum. Plot each project on those axes as a circle and make the area of the circle represent the number of man days.

Stuff in the top right is high return, new initiatives, stuff in the bottom left is low return maintenance/incremental improvements. If you do one chart for current resource deployment and another for planned resource deployment you'll get a strong feel for how you are spending your manpower.

There are many variations on this and you can choose what you want to plot where to best show your story. It is simple and powerful as a visual aid and you can get 90 circles on your chart without losing the woods for the trees.

HTH and good luck.

Simon
True, bubble diagrams makes the properties of the projects in the portfolio visible. Alignment with the product development strategy (if it exists) should also be assessed.
Kasper
+1  A: 

As I understand this question the solution is highly dependent on final goal which actually is unclear in most of similar cases.

Before doing some 'kanban-like diagrams' for this case especially having in mind declared goal (I suggest it is only mean, not a goal) to re-balance work force I'd recommend to think about next points:

  • Every single developer's efficiency highly depends on many factors individual to current projects. There are 'refactoring-aware' people / 'support-likers' / e.t.c. So being placed in another environment ... this could change anything.
  • Well, doing efforts re-balance. What happens to existing team structure? Good aligned teams with proper roles of every person are VERY RARE. Does it worth to break good team for some estimation (in the sky)?

So I'd recommend (instead or in addition to project efficiency tracking) to track developers efficiency / satisfaction / team efficiency / satisfaction and try to solve how to re-balance efforts not only because of ROI but to get most from people (at least unless projects are profitable not to put ROI estimations over all). Don't ruin successful (not so but yes) project just because someone needs one developer in other bright project.

OK, this is just my general opinion but it greatly helped me during last year. Hope it will help someone too.

Roman Nikitchenko