How best to organise an RTC Traditional Project?
I'm a little confused about some of the terminology and steps to get to a working plan in RTC when applying Traditional planning methods.
I'm also using Global Config Management and Lifecycle Projects.
Typically, in a single Project Area, we will have a Systems team and a number of platform teams (switchboards, drives, motors, generators, etc.) executing work on the project. The platform work feeds up into the System work but the platforms are relatively independent. Each team's development will go through a number of phases or design reviews.
So in terms of "Timelines", "Releases", "Iteration Types", "Iterations", "Release Plans", "Phase Plans", how do these all come together to make a plan?
Also, how can I best manage unplanned work for each team? i.e. actions, queries, issues, defects, etc. Typically we handle these in a Kanban style.
For the planned work, a typically structure might be:
And so on.
What should I define in the timeline? Should I have multiple timelines? How about releases (for GCM)? As iteration types/iterations? What's the difference between a phase plan and a release plan? What sort of work should go where?
What has to be created for every new project and what can be defined and inherited from the shared process PA?
If a schedule was defined as a single MS Project Plan initially, and I import it, how would these various levels map to timelines/iterations/releases/phases/plans, etc.
Thanks!
Glyn
|
2 answers
Hi Glyn, It does sound like you are on a journey; Normally as Ralph mentioned you would benefit from some services and experience of someone who's been there before to help support your questions. It sounds like you have work items in mind but do you have a custom RTC Traditional Template? A combination of Plans, Plan views and Dashboards can be very powerful. The exact use of the Traditional planner can become complicated based on recourse usage / management so start simple... Also If you are using Global config I assume you are also talking about Requirements and Test Plans and this may also need to be scoped in terms of reporting etc. Have you spoken to IBM or have support? Regards Matt Muller |
Ralph Schoon (63.1k●3●36●46)
| answered Aug 16 '19, 2:19 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER You are asking for weeks of consulting in an answer. I would suggest to check the following: https://jazz.net/wiki/bin/view/Deployment/RTCProcessFundamentals
Some hints.
Comments Hi. Firstly I do have IBM support but our budget limits the amount so I want to do the exploration and options ready to discuss and validate with them.
This link was useful, it might be better for me to start with a simple Agile template and customise it to suit the terminology that non-SW engineers are familiar with. Our factory plans are waterfall style which results in dependencies on Eng and that’s normally as far as the Eng plan goes from the business. Eng teams then use their own ways to manage the work. The Eng work is concurrent and would lend itself well to a more Agile approach with “releases” at the phase gates.
The issue I see is the limitation on having only 1 active iteration in a TL. Typically the motor, converter and switchboard teams in a system would work concurrently and reach their gates at different times. If the motor team reached their phase 1 gw before the converters, the motor team wouldn’t stop whilst the converter team finished their phase 1. Motors would start phase 2.
What’s the impact of having multiple TLs in a System Project Area?
Support is for product errors and not for consulting.
You confuse the iteration of a timeline with a release date. That is dangerous, reread the link. You can consider the end of an iteration as a date where something is available, but this analogy goes only so far. You can not create nested iterations with overlapping intervals and hope for any useful progress calculation.
You have to use multiple teams and timelines if the teams have different schedules.
You can use work items as a delivery and planning vehicle (e.g. "Release") to track related work using tracks or other work item links. Within limits. Especially Parent child are only supported within project areas.
Cross project planning can help but is again limited.
Multiple TL's mean multiple teams and each team can only work against one TL. More complexity and dependencies harder to track.
Glyn, The planning for Agile and Waterfall in RTC work in different ways - nothing like a pilot/project to help you understand. The traditional scheduler (waterfall) can be inflexible if you want to do detailed task management with resource planning... How your projects are structure and reported will challenge your tool setup/configuration. To be very honest I only use very basic parts of the Traditional scheduler as Plan snapshots and detailed resource allocation and time reporting is complex and time sheets are normally done outside of RTC in another system. I would also not be to concerned about the "Active Iteration" as it really depends on the project. Some clients I've work with more Agile use this in the Agile Template but Waterfall teams or traditional project management can be across gateways/milestones at the same time. I would be happy to discuss more or you want (think I sent you a linkedin request)? Lots of good articles and advise to trial in some demo projects. Good luck Matt |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.