| 1.1 |
Start Work Request Analysis & Assignment Sub-Process
|
| 1.2 |
Access Work Request
The CR Manager and assessment body, (i.e. made up of area experts and
appropriate teams), reviews the work request(s) and assesses them in
detail during the allotted timescale. The CR Manager must notify the
appropriate teams of any CRs which affect their area. Where the CR will
involve a significant change, the project team, (domain team etc. ),
must be included in the assessment of the CR and should provide their
recommendation on whether the CR should or how it could be implemented,
indicating approximate timeframe, priority, resource load etc.
Once the assessment body has completed their initial assessment and
based on the results the CR will find itself taking a further forking.
The majoity will be forwarded for validation and implementation
estimation.
While those of the larger or more complex nature may require a more
indepth analysis. In these cases, as a task team study requires much
effort and resource, it would be prudent to verify that it is of
interest to the Membership to invest in this study. A membership survey
could be initiated to resource and enable the study to commence.
The CR Manager must ensure that a status update is inlcuded in the CR
entry to ensure people are aware of progress.
Maturity level at this point will typically be a level 1.
Owner
|
| 1.3 |
Assign to correct analysis team
At this point the CCG have determined if a short validation is required
or a more indepth analysis by a single of group of experts.
Depending on the complexity of the work request, it may have to be
assigned to a task team which will draw from other groups such as the
Team Leaders Group, SPLC, etc.for further breakdown & analysis. Or
directly to the most likely implementing teams for validation and rough
estimate of required work & realistic timeframes.
Incoming Links
Outgoing Links
|
| 1.4 |
Task team creation and Assessment
Work requests which are of an extreme complexity or have far yielding
implications on the TM Forum standards will normally be addressed within
a task team.
The task team could be generated by a predefined group of people or work
as an ordinary development team, putting an open call for participation
and setting a Team Leader. In either case, they should conduct minuted
meetings etc.
The team has the freedom to address this item as best fits the problem
at hand. HOWEVER .... The team have a timeframe of 3 months in which to
complete the assessment and return their final report, which should at a
minimum have broken down the issue into manageable bits and indicate the
expected implementation effort, priority and urgency.
Maturity Level will typically be a level 1 at this point.
|
| 1.5 |
Validation of Request
Work Requests which are of a mid-level complexity, where by the problem
is clearly understood, but potiental implementations require validation
across one or muliple teams. A quick resource validation is conducted
with the appropriate team leaders at this point to assist the CCG in
their vote decisions.
A maximum timeframe of 2 weeks to conduct & complete this exercise is
set, but it expected that far less time is required.
Maturity Level will typically be a level 1 at this point.
Owner
|
| 1.6 |
Complete Assessment Report
The CR Manager completes a report, (which contains an impact statement
and a next step proposal), and saves this along with all other related
materials in the work request system entry, thus making it visible to
all. The status is set to Assessment Complete so that it can be included
for review and Vote in the next CCG meeting.
For the more complex assessments a detailed word assessment report would
be more approporate, the template can be found <link>
For the more straight forward or fast track items, then it would be
approprite to complete the on line form assessment slot.
Maturity level will typically move to a level 2 at this point as the
assessment has complete.
Owner
|
| 1.7 |
Formal Vote on work request
CCG review the assessment report and if further discussion is required,
this can be conducted during the CCG meeting or via community discussion
thread.
Once all concerns have been addressed a Consensus is called for, this
can be by means of an informal or formal vote against the results of the
assessment report or CCG may choose to use a member survey as a
mechanism to reach consensus if deemed appropriate.
The Assessment report must make one of the following recommendations.
a. Approve the CR,
b. Reject the CR,
c. Delay the CR as it is presently at a premature level, (giving reasons
as to why)
If the recommendation outlined in the assessment report is not accepted,
then the CCG need to determine the next appropriate step. These could
include conduct further assessment or close the CR.
Consensus result is recorded, (highlighting mechanism used), within the
work request system entry and the process proceeds appropriately.
Maturity Level will typically be a level 2 at this point.
Owner
|
| 1.8 |
Vote decision
At this point the work request is progressed appropriately.
Incoming Links
Outgoing Links
|
| 1.9 |
delay item
In this case, the CCG has some reason to delay a decision and this could
be that they require further information from either the requestor or
the assessors or an other party. Types of reasons and associated
timeframes are outlined below.
1. More information from Requestor. (1 day to a max of 1 month
depending on complexity of data - if a response is not received within
the allocated timeframe the CR can be rejected.)
2. Request is premature at this moment in time (Depending on the level
of prematureness, (and based upon strategic plan), the CCG will assign a
wait-loop for it. This can be a month, 6 months, a year etc. ....).
3. The work request is appropriate for immediate implementation, but
there just aren't resources to work on the request.
In cases 2 and 3 above, the CCG may feel it appropriate to conduct a
member survey to confirm that they have
1. made the correct call
2. or identify resources to work on the work request.
The assigned CR Manager is responsible to ensure the information is
received and keeps the CCG and the Requestor updated on progress.
All transactions and information relating to the CR are to be recorded
in the system artifact by the CR Manager.
Maturity Level will typically be a level 2 at this point.
Owner
|
| 1.10 |
Reject Request
The CR can be rejected for many reasons. Examples of which include: IPR
issues, Goes against the TM Forum Strategy, unacceptably worded, etc.
The CR Manager will inform the Requestor of the CCG decision, stating
the reasons. the status of the CR will be updated in the tracking tool
to have a status of 'Closed -rejected'.
Note: In the event that a requestor of a CR is not satisfied with the
decisions made by the CCG, an escalation process is available to them.
Maturity level will typically be a level 2 as assessment will have been
complete.
Owner
|
| 1.11 |
Escalation Process
In the event that a requestor of a CR is not satisfied with the
decisions made by the CCG, an escalation process is available to them,
.by submitting their request and reasons for their dissatisfaction to
the Technical Committee, no later than 1 month after notification of the
decision. The Technical Committee will review the request in light of
all the facts and make its decision, which could be one of the following:
1. Agree with CCG
2. Reassess with new information which had not previously been available
3. Technical Committee provide an alternative interpretation of the
material already provided so as to assist the CCG in the assessment of
the request.
(Note: It is possible that the further information may be required from
the requestor, so the submission could iterate around this phase).
|
| 1.12 |
Assign to working group(s)
work request to be assigned to the designated team for implementation.
The CCG need to determine if a team or set of teams currently exist to
address the issue.
If not, then a recommendation is put forward to the
Technical Committee to set-up a new team, who will be required to
generate a charter. ( Setting up a new team will be addressed in a
separate process)
If appropriate teams exist and multiple teams are required to interact
to implement the CR then the CCG must determine the appropriate
orchestration.
Orchestration across teams can fall into 4 categories namely:
(1) Complete independence - which will require orchestration only at the
delivery stage.
(2) Simple Serial type orchestration - which requires one team to
complete their activity before the next team starts.
(3) A single team implementing the request, with representation from
other teams
(4) Parallel team activity which have mulitple tirggers for interaction.
A priority is set against the work order to determine if required for
immediate implementation within a fix release or to be included in next
or future release.
Decision results are recorded within the work request artifact entry by
either the CR Manager or CCG Admin staff.
It should be noted, that an open call to the membership maybe required
to request resources to work on these items.
Maturity Level will typically be a level 2 at this point.
Owner
|
| 1.13 |
New working Team required?
Incoming Links
Outgoing Links
|
| 1.14 |
Make recommendation to the Technical Committee
If a new team is required to conduct this work, then the CCG need to
bring this to the attention of the Technical Committee with a
justification as to why they should consider setting this team up. It
should be noted that the justification would detailed enough to form the
basis of a charter if the proposed team were to proceed.
Maturity Level will typically be a level 2 at this point.
|
| 1.15 |
Conduct Member Survey
A Survey can be established, using such tools as Survey Monkey etc. and
put before the membership for their thoughts on topics as necessary for
the phase of the process. These survies could be set up to address such
considerations as:
1. Confirming the priority of work items as per what is important for
the industry in general
2. Verifying that it is correct to delay certain work items as premature
for the industry at the current moment in time.
3. Poll to see how important a piece of work is for the industry, and if
they are willing to supply resources to address it.
Results of the survey will be fed back and adressed by the CCG.
Maturity Level will typically be a level 2 at this point.
Owner
|
| 1.16 |
Plan & Schedule
1. The agreed urgency and priority is set against the work request. This
is used to determine if the change is required for immediate
implementation within a fix release or to be included in the next or a
future release. If work is required now, then the team charters are
examined to determine if an ammendment is required. If so, then all
ammendments are made and approved prior to commecment of the work.
2. A scheduled delivery timeframe and release are agreed and a plan
created using the provided tools as appropriate. (e.g. Trackers, task
manager etc. )
3. The request then enters the development process.
4.As a default the CR Manager manages the requested change though out
the process. However, It is intended that once assigned to a team, the
Team Leader will take up ownership of the work request and reiodically,
report progress back to the CCG.
Note: Once the change is implemented and verified by the implementing
team, it will enter the deliverable approval process - where the CCG as
part of the expert reviewers team will verify that it has been
implemented correctly.
Maturity Level will typically be a level 2 at this point.
Owner
|
| 1.17 |
Charter required?
Incoming Links
Outgoing Links
|
| 1.18 |
Generate Charter
If there was an existing charter, then this should be updated and
resubmitted for approval.
If the team was in the process of starting a new phase of work, then the
latest charter template (TMF405) should be downloaded and completed and
then submitted for approval.
The charter should clearly idenfity if it is new development or
maintenance work and in the case of New Development if it is intended to
go through the entire development cycle or stop at some earlier point
e.g. Business Agreement stage.
To submit a charter for approval. The completed word document must be
placed in the 'Submitted Documents folder' of the teams project
workspace and an entry made in the 'Project Charter Submission' tracker,
linking both together via the associations tab of the tracker entry.
Maturity Level will typically be a level 2 at this point.
Owner
|
| 1.19 |
Project Approval Sub-Process
The Project Approval sub-process describes the activities necessary for
the approval of a new project. A new project could require a new team
or a new phase of an existing team.
Refer to the detailed 'Project Approval Sub-process' for complete
details.
Owner
|
| 1.20 |
End Work Request analysis & Assignment sub-process
|
| 1.21 |
Returning to Work Request Rationalization sub-process
|
|
Expand / Collapse
