Different planning approaches - what have you tried?
Hi
I am seeing some different approaches to planning and managing projects from RTC - and wondered what other people's experiences are. If anyone has any comments or feedback on the following - I am sure this will be useful for everyone:
1) RTC with the tasks and the outcomes/artifacts
Projects hold or link to artifacts such as documents, models, code. etc - and then tasks to produce or modify the artifacts. This is a two-tier system - each task is a work item with duration, a lifecycle of varying complexity, and other attributes, and then a link to the artifact produced. That artifact has a review cycle in the workflow for that artifact work item.
2) RTC manages artifacts only.
The artifact is actually more a task - and the artifact is attached, or a URL is added into the description. The workflow for the artifact goes through stages such as Started, Working On, Internal Review, External Review, Approved. This approach can also make use of the Approvals capability but this is not then integrated into the work flow (unless I hav missed something)
3) RTC manages the tasks only.
Forget about the artifacts - just create tasks and show progress on the tasks. If you must relate to the artifacts, then just embed a URL in the description or the Comments field.
Anyone tried any other approaches?
Once you move to CLM - then some of the document or diagram-centrics artifacts have a natural home in RRC, The testing elements like test plans live in RQM, so RTC is really being used for code/build artifacts - and for overall task planning with traceability to the artifacts held in the other CLM tools.
Hoping to generate some discussion on this...
regards
anthony
I am seeing some different approaches to planning and managing projects from RTC - and wondered what other people's experiences are. If anyone has any comments or feedback on the following - I am sure this will be useful for everyone:
1) RTC with the tasks and the outcomes/artifacts
Projects hold or link to artifacts such as documents, models, code. etc - and then tasks to produce or modify the artifacts. This is a two-tier system - each task is a work item with duration, a lifecycle of varying complexity, and other attributes, and then a link to the artifact produced. That artifact has a review cycle in the workflow for that artifact work item.
2) RTC manages artifacts only.
The artifact is actually more a task - and the artifact is attached, or a URL is added into the description. The workflow for the artifact goes through stages such as Started, Working On, Internal Review, External Review, Approved. This approach can also make use of the Approvals capability but this is not then integrated into the work flow (unless I hav missed something)
3) RTC manages the tasks only.
Forget about the artifacts - just create tasks and show progress on the tasks. If you must relate to the artifacts, then just embed a URL in the description or the Comments field.
Anyone tried any other approaches?
Once you move to CLM - then some of the document or diagram-centrics artifacts have a natural home in RRC, The testing elements like test plans live in RQM, so RTC is really being used for code/build artifacts - and for overall task planning with traceability to the artifacts held in the other CLM tools.
Hoping to generate some discussion on this...
regards
anthony
4 answers
I wouldn't call these different planning approaches ... but rather
different approaches for managing documents. I wasn't sure, but it
sounded like option (1) was for artifacts under version control (my
personal preference). If you don't expect changes to the document, then
option (2) is simplest. If for some reason, the document must be stored
outside of the RTC repository, then you'd need to use option (3).
Cheers,
Geoff
On 11/14/2011 6:23 PM, kesterto wrote:
different approaches for managing documents. I wasn't sure, but it
sounded like option (1) was for artifacts under version control (my
personal preference). If you don't expect changes to the document, then
option (2) is simplest. If for some reason, the document must be stored
outside of the RTC repository, then you'd need to use option (3).
Cheers,
Geoff
On 11/14/2011 6:23 PM, kesterto wrote:
Hi
I am seeing some different approaches to planning and managing
projects from RTC - and wondered what other people's experiences are.
If anyone has any comments or feedback on the following - I am sure
this will be useful for everyone:
1) RTC with the tasks and the outcomes/artifacts
Projects hold or link to artifacts such as documents, models, code.
etc - and then tasks to produce or modify the artifacts. This is a
two-tier system - each task is a work item with duration, a lifecycle
of varying complexity, and other attributes, and then a link to the
artifact produced. That artifact has a review cycle in the workflow
for that artifact work item.
2) RTC manages artifacts only.
The artifact is actually more a task - and the artifact is attached,
or a URL is added into the description. The workflow for the
artifact goes through stages such as Started, Working On, Internal
Review, External Review, Approved. This approach can also make use
of the Approvals capability but this is not then integrated into the
work flow (unless I hav missed something)
3) RTC manages the tasks only.
Forget about the artifacts - just create tasks and show progress on
the tasks. If you must relate to the artifacts, then just embed a
URL in the description or the Comments field.
Anyone tried any other approaches?
Once you move to CLM - then some of the document or diagram-centrics
artifacts have a natural home in RRC, The testing elements like test
plans live in RQM, so RTC is really being used for code/build
artifacts - and for overall task planning with traceability to the
artifacts held in the other CLM tools.
Hoping to generate some discussion on this...
regards
anthony
I wouldn't call these different planning approaches ... but rather
different approaches for managing documents. I wasn't sure, but it
sounded like option (1) was for artifacts under version control (my
personal preference). If you don't expect changes to the document, then
option (2) is simplest. If for some reason, the document must be stored
outside of the RTC repository, then you'd need to use option (3).
Hi Geoff
Good point - this is is rather focused on the documents/artifacts but I think there is a generic idea here I want to try and capture.
I have long thought that the planning/artifact link in RTC (and CLM) was along the lines of plan the work, and store the outcome/deliverable of the work. So for code development - we have a task to add a feature or fix a defect - and the "deliverable" is the code. Extending that to CLM - the requirements people plan out their work (for example, "interview business stakeholder" or "update non-functional spec" and then the "deliverable" is the results of the interview or the revised non-functional spec. The plan for the QA team is to "prepare a test plan" or "run the regression suite on a new release", and the output is the test plan or the results of the run.
The artifacts may just exist (or not), or they may have a lifecycle of their own. The ones with a more complex lifecycle become work item types (if held in RTC only), or be handled by othr CLM tools (for example - a requirement has an implied lifecycle in RRC)
regards
anthony
It is common for many existing document management systems to assign a
"state" or "status" to a document. I personally believe that is usually
a mistake. If one believes in re-use (which I do :-), then an artifact
never has a "state". Instead, it is a given use of that artifact that
has a state (e.g. for internal use, for use by a particular customer,
for use in a given presentation). Each of these uses is assigned its
own work item, to track the state of that artifact for that particular
use (and the description of the work item identifies the particular use).
Cheers,
Geoff
On 11/15/2011 4:53 AM, kesterto wrote:
"state" or "status" to a document. I personally believe that is usually
a mistake. If one believes in re-use (which I do :-), then an artifact
never has a "state". Instead, it is a given use of that artifact that
has a state (e.g. for internal use, for use by a particular customer,
for use in a given presentation). Each of these uses is assigned its
own work item, to track the state of that artifact for that particular
use (and the description of the work item identifies the particular use).
Cheers,
Geoff
On 11/15/2011 4:53 AM, kesterto wrote:
gmclemmwrote:
I wouldn't call these different planning approaches ... but rather
different approaches for managing documents. I wasn't sure, but it
sounded like option (1) was for artifacts under version control (my
personal preference). If you don't expect changes to the document,
then
option (2) is simplest. If for some reason, the document must be
stored
outside of the RTC repository, then you'd need to use option (3).
Hi Geoff
Good point - this is is rather focused on the documents/artifacts but
I think there is a generic idea here I want to try and capture.
I have long thought that the planning/artifact link in RTC (and CLM)
was along the lines of plan the work, and store the
outcome/deliverable of the work. So for code development - we have a
task to add a feature or fix a defect - and the
"deliverable" is the code. Extending that to CLM - the
requirements people plan out their work (for example, "interview
business stakeholder" or "update non-functional spec"
and then the "deliverable" is the results of the interview
or the revised non-functional spec. The plan for the QA team is to
"prepare a test plan" or "run the regression suite on
a new release", and the output is the test plan or the results
of the run.
The artifacts may just exist (or not), or they may have a lifecycle of
their own. The ones with a more complex lifecycle become work item
types (if held in RTC only), or be handled by othr CLM tools (for
example - a requirement has an implied lifecycle in RRC)
regards
anthony
Hi Anthony,
Have you tried Agile@scale template? it scales well for larger enterprise.
Cheers,
Simon
Have you tried Agile@scale template? it scales well for larger enterprise.
Cheers,
Simon
Hi
I am seeing some different approaches to planning and managing projects from RTC - and wondered what other people's experiences are. If anyone has any comments or feedback on the following - I am sure this will be useful for everyone:
1) RTC with the tasks and the outcomes/artifacts
Projects hold or link to artifacts such as documents, models, code. etc - and then tasks to produce or modify the artifacts. This is a two-tier system - each task is a work item with duration, a lifecycle of varying complexity, and other attributes, and then a link to the artifact produced. That artifact has a review cycle in the workflow for that artifact work item.
2) RTC manages artifacts only.
The artifact is actually more a task - and the artifact is attached, or a URL is added into the description. The workflow for the artifact goes through stages such as Started, Working On, Internal Review, External Review, Approved. This approach can also make use of the Approvals capability but this is not then integrated into the work flow (unless I hav missed something)
3) RTC manages the tasks only.
Forget about the artifacts - just create tasks and show progress on the tasks. If you must relate to the artifacts, then just embed a URL in the description or the Comments field.
Anyone tried any other approaches?
Once you move to CLM - then some of the document or diagram-centrics artifacts have a natural home in RRC, The testing elements like test plans live in RQM, so RTC is really being used for code/build artifacts - and for overall task planning with traceability to the artifacts held in the other CLM tools.
Hoping to generate some discussion on this...
regards
anthony