Monthly Archives: May 2014

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

Setting up a Cross Project Plan

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

Configure associations between the projects.

Minimally establish Provides > Related Change Requests associations between the top level project and each of the project team project areas

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.

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.

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)

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.

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

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

Ensure that the plans which are being tracked have up-to-date “Planned” snapshots.

Normalize unit of measurement for effort between projects, even if following different process

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

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

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)

Create additional plan views to show other non-schedule focused perspectives of the cross project plan

Archives

These are my PERSONAL views and observations

The postings on this site are my own and don't necessarily represent IBM's position, strategies or opinions. Anyone is free to use, copy, distribute, modify or sell the source code and other materials directly linked from trfeeney.wordpress.com and is provided "as is" without warranties. I am not responsible for any harm or damage caused to your computer, software or anything else caused by the material.