Cross Project Planning with Rational Team Concert – the good, the bad and the ugly

Creativity is not one of my strong suits so coming up with catchy blog titles is a challenge for me.  I could incorporate some Clint Eastwood references throughout but as I said, creativity is in short supply.  What I want to convey in this entry is more than just the concepts of the Cross Project Planning capability of Rational Team Concert (RTC) but get into some of its good while also some of its bad/ugly parts too.

I recently gave a talk at an enablement event for some of our field technical resources. My goal was to give them the ‘skinny’ on some of its fundamentals but also its limitations, uses and best practices.  What follows is a summary of what I presented.

I’ll say from the outset that I had high hopes for Cross Project Planning when it first came out in v4.0.  I remember working with a customer in Australia just after the 4.0 release came out who was a perfect fit for Cross Project Planning.  I naively made some assumptions about what you would be able to do with these plans.  After proceeding down the path to position use of these plans by that customer, I soon ran into one of its glaring omissions – they don’t roll up progress across all the projects/plans it is tracking.  Despite that missing feature, I do find good uses for Cross Project Plans which I’ll note below.

Cross Project Plan Fundamentals

Often times development projects involve multiple teams whose progress and completion must be tracked and visible at a comprehensive level.  The Rational CLM project is like this. High level plan items for CLM are carried out often by two or more of the CLM application teams: RRC, RTC, RQM, RRDI, etc.  This program of projects approach is quite common today.  Rather than being limited to a single team/iteration, starting in RTC 4.0, plans support a ‘tracks’ link type for work items, enabling plans to track high-level items that belong to different projects.

Components of a Cross Project Plan

Top level project area tracking effort by one or more other projects

  • Contains one or more Cross Project Plans
  • Work items to ‘track’ the development/execution of work done by other project teams

One project area for each project team contributing to the larger effort

  • Contains Plan level work items and their execution level work items
  • Contains one or more Iteration plans with at least one planned snapshot that are linked to the top level project’s Cross Project Plan

Example:  The Diagnostic Tool Project Plan tracks work carried out in the Web UI, Repository and Hardware projects that contribute to a larger, perhaps cross-project effort

image

Setting up a Cross Project Plan

  1. Create Project Areas for the top level project and each of the project teams contributing to the overall effort managed by the top level project
  2. Configure associations between the projects.
  3. Create plan and execution level work items for each of the project teams in their individual project areas
  4. Create Iteration plans, e.g. Sprint Backlog for each of the project teams for the iteration to be tracked/rolled up
  5. Take a planned snapshot for each of the iteration plans
  6. Create a Cross Project Plan
    • A cross-project plan shows all items that belong to it locally (matching the plan query) and the items that are tracked by them.
  7. Create tracking work items in the top level project and use the ‘tracks’ relationship to link them to the project team area plan items that will contribute to/implement them

Using a Cross Project Plan

Once the Cross Project Plan is in place you can view

  • Schedule roll up of the entire plan
  • Schedule roll up of each contributing plan item (based on snapshot)
  • Open schedule to the plan containing the tracked work items

image

Note if no planned snapshot exists, the iteration start/end dates are used

The default view is Project Schedule.  Create custom views to show:

  • Owned By to show resource assignments
  • Link Types (e.g. Tracks, Children) to show other relationships of interest
  • Status to view progress across the projects at a lifecycle state view
  • Change Tree configuration to show other valid link types and change the depth of links followed

image

Assess the health of a Cross Project Plan by adding the Cross-Project Planning Problems Check plan check.

  • The rolled-up schedule for an item on the plan exceeds the end date of the iteration that the cross project plan is associated with.
  • The “planned for” date of a plan item exceeds the cross project plan’s iteration end date.
  • The rolled-up schedule for an item on the plan exceeds the due date specified on the item.

image

Limitations of Cross Project Plans

What I find customers want from a Cross Project Plan, perhaps planning in general, are schedule consolidation, progress roll-up, common resource allocation and a broad view of status across projects.

Cross Project Plans do roll up schedules based on the planned snaphots of the tracked plans.  Unfortunately, progress isn’t rolled up but can be by reporting.  Resource allocation is limited and only with Traditional Planning though Cross Project Plans can give a visualization of all resources assigned across all projects. As for the broad view of project/plan status, Cross Project Plans can give a visualization of the status of each plan level item and those development items contributing to it across all projects.

Below is an itemized list of limitations I’ve collected.

  1. Plans roll up schedule but not progress
  2. Cross Project Plans limit what attributes from work items in other CCMs can be included in their plan views as the plan snapshots used include limited data
  3. Schedule roll up is only based on snapshot and not live data
  4. Plan snapshots do not save work items included by the tracks link
  5. Some performance issues when loading a plan with a tree view and pulling data across CCMs associated with different JTSes
  6. Cross project plan checks look for violations of all (currently 3) related rules.
    • No ability to turn off those that may not be of interest
    • Also, these are only visible in a plan view; would be nice to highlight these specifically on a dashboard widget. Plan View dashboard widget can render a plan view on the dashboard but won’t show the plan check errors (also, this widget can be slow)
  7. Cross-project linking supports the use of any OSLC-based link type supported in RTC, in addition to the Tracks link type specifically designated for cross-project planning.
    • Cross-Project Link Types in RTC:
      • Tracks – com.ibm.team.workitem.linktype.tracksworkitem
      • Contributes To – com.ibm.team.workitem.linktype.trackedworkitem
    • List of OSLC work item link types
      • Related Change Management – com.ibm.team.workitem.linktype.relatedChangeManagement
      • Affects Plan Item – com.ibm.team.workitem.linktype.cm.affectsPlanItem
      • Affected By Defect – com.ibm.team.workitem.linktype.cm.affectedByDefect
    • Other link types can be specified in Cross-Project Plans to create the tree view, but you may not see all elements in the tree, depending upon where the target Project Area lives. In this case, target work items that exist in Project Areas on other Jazz Team Servers will not be displayed, leading to insufficient information in your plan view.

Cross Project Planning Best Practices

  1. Programs of Projects
    • Track Business driven demands/changes/features in a Program level project
      • include both Roadmap and Release plans (cross project)
    • Track Team level execution/delivery on those business functions in one or more projects
      • Include Release and Sprint/Iteration plans
  2. Ensure that the plans which are being tracked have up-to-date “Planned” snapshots.
  3. Normalize unit of measurement for effort between projects, even if following different process
  4. A best-practice for what to use as the tracking work item types has not yet been codified.
    • use whatever makes best sense in the context of the types of items you will be rolling up
  5. Work items in the Cross Project Plan aren’t just those that track work in other projects
    • Consider what other work items would be of interest at a program level, e.g. risks, interface adoptions
  6. Limit tracking of work in projects in a different CCM to avoid potential performance issues loading data across CCM repositories (architect CCMs to have related projects together)
  7. Create additional plan views to show other non-schedule focused perspectives of the cross project plan
  8. Continue to limit the size of your plans to reduce plan load time

Key Planning References

Conclusion

Cross Project Plans may not be everything I wanted originally, but they do have some good uses and are providing value to customers.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s