In-depth understanding of the concept behind plan items and execution items

Jürgen,

I tried to summarize some of the fundamentals here: https://jazz.net/wiki/bin/view/Deployment/RTCProcessFundamentals#Planning_Fundamentals
That is my understanding, not necessarily that of all.

I would like to approach this a bit different. If you are planning you will have goals, things you want to achieve on a higher level. Then there are things you have to do to achieve the goals.

Plan items are basically to express the higher level achievements, goals, features, stories whatever you call them. In planning you want to have an overview what the major contributions to the plan are. You often don't want to be distracted by all the details. Such a goal should be planned on a level that can be done in an iteration. You can use a breakdown e.g. Epic->Story->Story to break a huge plan item down into smaller pieces you can actually do in such an iteration.

(Agile) Effort estimation has the idea that humans are really good at estimating a rough ballpark number 1 point, 2 pint, 3 point, 5, 10, ... but for a lot of things they are bad at estimating 1 hour, two hours etc. The bigger the numbr the bigger the estimation error. Will this work take 100 hours or 120? So the idea is to have such a complexity at the plan level with fewer choics the higher the numbers to account for the fuzziness of estimating. You can use an enumeration or an integer. If you use an integer you should be aware of how bad humans are estimating at that high level for big numbers.


Execution items is the details what you have to do to get the plan items done. In the execution items you want to track the details. You want to be able to split the plan items in many tasks you have to do to finish them. Tasks should be small enough to be done by one person and ideally you should be able to estimate how long they take.

As far as I can tell, in RTC you flag the plan items in the planning configuration. All other item types are considered execution items. You can change the decision any time. There are some reasonable decisions already taken in the process templates.

Roll up using parent child only works within one project area.

On Plan item level the complexity is rolled up. If you have a very abstract level such as Epic, that item can be specified as top level item with no complexity on its own, so that the complexity of the child plan item (stories) is the collective complexity. Plan items usually don't have an estimate, corrected estimate  etc.

Execution items don't have a complexity, they may have an estimate, corrected estimate, time spent,... The roll up (within a project area) allows to roll estimations and tracked time up to the plan item level.

There is cross project planning using tracks/contributes To links, where the link allows to track plan items in this plan to plan items in other project areas. Too much for here.

There is a bunch of stuff I don't know that I don't know. So I can't tell you if you are missing something. I would suggest to have some small systems with the JKA Banking/Money that matter example to play around with. It has some data to start with and some plans. There are also various articles in the library. I think I put some into the fundamentals article.

I personally think the differentiation in plan items and execution items is useful. It allows to filter out details or focus on details. I also like the complexity versus the real effort tracking (says one of the worst planners and estimators on the planet).

If you play around with this, be aware that adding attributes can not be really reversed. But RTC should give you some flexibility to change things back and forth.

Jürgen,

I have supported many clients in terms of deployments for RTC  planning;

Traditional (FPM) and Agile...

Starting simple with the FPM (formal Project Management) using work item and getting the understanding of how the plan works takes time. Start Simple and review the Iterations and goals your project wants to achieve.

The My Stuff (user option) and new "Quick Planner" give users a great view of their tasks and work allocations. 

It takes time to understand planning (8 years for me)  that if your users are split across teams and projects then this complicates planning; as % allocations are split by the system individuals can change allocations.. Tasks take longer if their allocation are split.  Microsoft Project let's you over allocate etc. but RTC is not as flexible.

I prefer to start simple and then add some additional functions with Dashboards / Plan views etc. the biggest benefits are the collaborative Task working; Links and approvals and reviews to help the project meet it's requirements and to keep track of "RAID" or other key elements.  The plan is then just the best way to view the complete picture.  Making plan views and adding filters, colours and other columns supports teams and users - so lots of good tips there. 

I also prefer the simplicity of Agile within the RTC Template; and this meets with agile/scrum principles ..  and drops a lot of the complexity of the Traditional planner.

Also many of the reports are more towards the Agile or Scaled Agile (SAFE) Templates.

Good Luck