Ideas/Thoughts/Help requested on best way to run a (non-SW Development) Program of works in RTC (4.0)?

Firstly, let me just state, personally I like RTC a lot, love the intuitive look and feel and see the massive step in the right direction since the dark days of RPM. As an experienced PM running complex Systems Integration projects I see this being the future for ALL projects.

Next, let me qualify this, RTC appears to have some fairly basic shortcomings in managing these type of traditional programs / projects right now.

I am looking for anyone with similar experiences and how they managed to configure the RTC system for their needs, or anyone with some creative ideas on workarounds . I would also appreciate a view from the development team on how some of these may be dealt with along the roadmap?

Key Concerns/Issues at the moment:

  1. Program/Project structures impacted by team-area level queries/dashboards.

  2. Key Project management data not accounted for at all; ie status definition, budget, financials etc.

  3. Cross Project level queries/reporting (out of the box) is non-existent.

  These are all discussed in detail below

  1. Program/Project Structure.

This is the ideal setup that we would prefer to use, as it provides the ability to rollup information from all Projects (team areas) to the Program (project area) dashboard.

As a reference we are looking at around 6 key programs and around 60 medium/large projects over the next 4 years.

The key requirement for a ‘Project’ in this definition is that it needs to be a discrete and self contained unit that is (by default) not encumbered by information from other projects.

A) the data from the parent Program (project area) is excluded from the Project (team area) view

B) the data in the child Project (team area) is included/rolled-up in the parent Program (project area) view

C) the data from other Projects (project areas) in the same Program (project area) are excluded from the Project (team area) view

Basically, out of the box, all of these are OK except for A. This single deficiency caused us to revisit our complete project/team area strategy.

Explanation:

We have created a template which creates a Program (Project Area set of dashboards) template like the one below.

We require the Projects (Team Areas) to have exactly the same look and feel, so we created a Team Area template set of dashboards almost the same

The KEY issue has to do with the underlying Queries. At the Team-Area level, there does not currently appear to be a way to dynamically capture and set the current Team Area.

  What we did, was to create a new set of ‘Team Level’ queries for the master template which would be used by all team area level dashboards/widgets.

However, one of the underlying assumptions, appears to be broken, the following query, which we assume would take the context of the Team Area, that the user is navigating within and pass it through automatically to the query … does not do so.

The current workaround seems to be the creation of a new and complete set of copied queries (about 50 in total) tailored specifically for each project area. 

Given that we are expecting to create around 60 projects (Team Areas), this would mean the creation and maintenance of about 60x50 = 3000 individual queries, as well as the manual linking of these to each widget in each project dashboard.

This massive config/maintenance overhead has therefore caused us to change our approach and thus lose some of the best functionality of the tool, ie the ability to automatically roll up data to the Project Area.

Appreciate if anyone has any other ideas on how to deal with this issue?

  2. Key Project Management data

  Project Managers in traditional project environments need data to manage projects and  to escalate to sponsors etc, when necessary. While a tremendous amount of data is available around key work item types; such as risks, issues, dependencies, defects etc, some of the most basic project information is missing; basic financials, traffic light status reporting and PM commentary (items of interest; good/bad etc)

  Our approach has been to create a new Work Item type called a ‘Project Information record’, which basically captures all the information (manually) that is required for project status reporting.

Ideally, we would like these records to include some roll-up capability from the projects up to the program . Ie; financial summaries, at the Program level, but understand that this is probably wishful thinking.

Appreciate if anyone working on more traditional programs/projects have come up with alternate ways of dealing with this?

3. Cross Project level queries/reporting

Not much to say here; this seems to be just a missing feature.

We need to summarise data across Programs (Project Areas) and Projects (Team Areas) in so many ways, but are not able to do so at the moment. Cross program (Project Area) queries and dashboards, which highlight data at an executive level is seriously lacking.

Around 95% of the out of the box widgets and reports are simply not appropriate for traditional style projects and programs of works.

  Even looking at the options; writing tailored BIRT reports or using RRDI for more trending analysis; it is not straightforward and skills in this area are hard to come by.

  Again, any ideas in this area would be appreciated?

<Thanks for having the patience to read to this point>