Collaboration Program Process 2010 -V6

Process Narrative
 
Created: 07/29/2009
Last Modified: 01/19/2010




Document Preferences 
  View Optimized
  Portrait View
  Include People
  Show Link Info
  Expand / Collapse

Table of Contents

   1.0   Collaboration Program Process
1.1   CP Process Start
1.2   Work Request Capture and Rationalisation Sub Process
1.3   Development Sub Process
1.4   Deliverable Approval Sub Process
1.5   Approved Deliverables
1.6   CP Process End
   2.0   Work Request Capture and Rationalisation Sub Process
2.1   Start Work Request capture & Rationalisation sub-process
2.2   Work Request Capture
2.3   Work Request Rationalisation sub-process
2.4   Work Request analysis & Assignment sub-process
2.5   End Work Request capture & Rationalisation sub-process
   3.0   Work Request Capture
3.1   Start Work request Capture Sub-Process
3.2   Work Request on-line form
3.3   Request Submission Tracker
3.4   Collect Work requests
3.5   Sanity check
3.6   Valid Submission
3.7   Pre-assess request
3.8   Candiate for Fast track
3.9   Fast track request Sub Process
3.10   Work Request Rationalisation sub-process
3.11   TM Forum Board
3.12   Technical Committee
3.13   Non TMF Members (Public)
3.14   Change Control Group
3.15   TM Forum Membership
3.16   CP Working Team
3.17   Liaison Group
3.18   The Industry
3.19   Team Leaders Group
3.20   End Work Request Capture Sub-Process
   4.0   Work Request Rationalisation sub-process
4.1   Start Work Request Rationalisation Sub-Process
4.2   Initial CCG assessment
4.3   Route Work Request
4.4   Call for RFP/Prospectes
4.5   Delay Decision
4.6   Progress Work Request
4.7   Reject Request
4.8   Escalation Process
4.9   Fast track request
4.10   Fast track request Sub Process
4.11   Work Request analysis & Assignment sub-process
4.12   End of Work request rationalisation sub process
   5.0   Work Request analysis & Assignment sub-process
5.1   Start Work Request Analysis & Assignment Sub-Process
5.2   Access Work Request
5.3   Assign to correct analysis team
5.4   Task team creation and Assessment
5.5   Validation of Request
5.6   Complete Assessment Report
5.7   Formal Vote on work request
5.8   Vote decision
5.9   delay item
5.10   Reject Request
5.11   Escalation Process
5.12   Assign to working group(s)
5.13   New working Team required?
5.14   Make recommendation to the Technical Committee
5.15   Conduct Member Survey
5.16   Plan & Schedule
5.17   Charter required?
5.18   Generate Charter
5.19   Project Approval Sub-Process
5.20   End Work Request analysis & Assignment sub-process
5.21   Returning to Work Request Rationalization sub-process
   6.0   Fast track request Sub Process
6.1   Start Fast track sub process
6.2   Assign to team
6.3   Plan & Schedule
6.4   Development Sub Process
6.5   Work Request Rationalisation sub-process
6.6   End Fast track sub-process
   7.0   Call for RFP/Prospectes
7.1   Start Call for RFP/Prospectes sub-process
7.2   ID Key Participants
7.3   Brainstorm content
7.4   Construct and Publish RFP
7.5   Monitor & stimulate responses
7.6   Collate results & distribute
7.7   Work Request Capture
   8.0   Task team creation and Assessment
8.1   Start Task Creation & Assessment sub-process
8.2   Establish task team
8.3   Plan and Schedule
8.4   Generate Charter
8.5   Project Approval Sub-Process
8.6   End Task Team creation & Assessment sub process
8.7   Perform Assessment and return final report
   9.0   Project Approval Sub-Process
9.1   Start Project Approval Sub-Process
9.2   Create Charter Approval Submission
9.3   On-line submission form
9.4   Distribute for expert review
9.5   Collate Review Comments
9.6   Charter Type
9.7   Approval Decision
9.8   Approval Result
9.9   Process, post & include in roadmap
9.10   Roadmap
9.11   Posted Charter Details
9.12   Director of Demonstration Projects
9.13   Submitter/Requestor
9.14   Program Management
9.15   TM Forum Membership
9.16   Document Release Manager
9.17   SVP Collaboration Program
9.18   Expert Reviewer(s)
9.19   Technical Committee
9.20   End Project Approval sub process
   10.0   Escalation Process
10.1   Start Escalation sub-process
10.2   Receive escalation request
10.3   Technical Committee review and decide
10.4   Technical Committee decision
10.5   Submitter/Requestor
10.6   Reject Escalation
10.7   Approved for Implementation
10.8   Further CR Assessment
10.9   CCG Admin
10.10   Work Request analysis & Assignment sub-process
   11.0   Development Sub Process
11.1   Start of Development Sub-Process
11.2   Scope and detail planning
11.3   Meeting Minutes
11.4   Detailed Development Cycle
11.5   Ready for release?
11.6   Release Deliverable into the Approval Process
11.7   Review Comments
11.8   Change Requests
11.9   Team contributions
11.10   Deliverable Template
11.11   End of Development Sub-Process
11.12   Open Call & Member Survey
   12.0   Deliverable Approval Sub Process
12.1   Start Deliverable Approval Process
12.2   Submit Approval Request
12.3   On-line approval Submission form
12.4   Team Approved Deliverable(s)
12.5   Process Approval Submission
12.6   Review and evaluation
12.7   Technical Committee Approval
12.8   Approval Result
12.9   Archive rejected Artifact
12.10   Advance Approval Process
12.11   Make Public Available
12.12   Process & Post for Public
12.13   Corporate Vote required
12.14   TM Forum Corporate Vote Sub-Process
12.15   Corporate Vote received
12.16   Final Approval Processing
12.17   TM Forum Membership
12.18   Technical Committee
12.19   Expert Reviewer(s)
12.20   Non TMF Members (Public)
12.21   End Deliverable Approval Sub-Process
   13.0   TM Forum Corporate Vote Sub-Process
13.1   Start Corporate Vote Sub-Process
13.2   Prepare for Corporate Vote
13.3   On-Line voting form
13.4   Invite to submit Vote
13.5   Collate & process returned Votes
13.6   TMF Corporate Members
13.7   End Corporate Vote Sub-Process


1.0  
Collaboration Program Process Process Narrative

Collaboration Program Process
Description Looking to start from scratch.
Collaboration Program Process

This process document outlines the main processes related to the Collaboration Program.  Through the use of sub-process it will branch into the various aspects.

In each case the 'Owner' for the sub-process and/or activity will be identified.  Required inputs and outputs of the sub-process/activity will be document under the section titled 'Requirements' (limitation placed by the tool).  Finally, the 'Performed By' section will identify the key stakeholders.

In addition to this document, it is strongly recommended that the guideline documents and help text for the various tools provided be consulted. These are availalble from the community area.


1.1   CP Process Start 

This process describes the Collaboration Program end to end process from the capture of work requests through to delivery of TM Forum material.  It includes such items as project initiation, Deliverable development, review & approval stages etc.


1.2   Work Request Capture and Rationalisation Sub Process 

New work and change requests may be captured from a number of different sources using a common on-line entry point, (http://www.tmforum.org/Community/groups/collaboration_program_center/changerequest.aspx) .  These work requests are brought together into a single, consolidated list, indicating a priority level. Thes eare then filtered and assigned to an appropriate working group.

By default items entered here will be of a Maturity level 0 (not set) or 1.

Refer to detailed 'Work Request capture and rationalisation' sub process for complete details.

Owner

Name Description Type
Change Control Group Group


1.3   Development Sub Process 

During this phase of the project, the project team must operate within the scope of the approved project charter and according to the TM Forum by-laws and IPR rules as defined in the Operating Guide.

This section focuses on agreeing to the exact format of the deliverables, creating the deliverables and ensuring initial quality assurance is completed.

Refer to the detailed 'Development Phase' sub process for complete details

Owner

Name Description Type
SVP Collaboration Program Person heading up the Collaboration Program of the TM Forum. Role
Team Leaders Group Group


1.4   Deliverable Approval Sub Process 

Once Collaboration Project artefacts are submitted for approval, this process flow outlines the steps which it must undergo in order to achieve approval and it identifies the roles & groups who are required to part take in those steps.

Refer to the 'Deliverable Approval Sub Process' for details.

Owner

Name Description Type
Program Management Person who manages and maintains the Collaboration Program roadmap. Role
Technical Committee Sub-committee of the board that provides the detailed technical strategy and guidance for technical projects Group


1.5   Approved Deliverables 

Documents, model files etc. required to meet the project deliverables


1.6   CP Process End 



2.0  
Work Request Capture and Rationalisation Sub Process Process Narrative

Work Request Capture and Rationalisation Sub Process
Work Request Capture and Rationalisation Sub Process

New work and change requests may be captured from a number of different sources using a common on-line entry point, (http://www.tmforum.org/Community/groups/collaboration_program_center/changerequest.aspx) .  These work requests are brought together into a single, consolidated list, indicating a priority level. Thes eare then filtered and assigned to an appropriate working group.

By default items entered here will be of a Maturity level 0 (not set) or 1.

Refer to detailed 'Work Request capture and rationalisation' sub process for complete details.

Owner

Name Description Type
Change Control Group Group


2.1   Start Work Request capture & Rationalisation sub-process 

Work requests are captured, consolidated into a single stream and sanity checked.


2.2   Work Request Capture 

Work requests entered via the online form are automatically stored in a central repository. From here it is sanity checked by TM Forum staff and the appropriate Maturity level, (default 1) is set.  It is then assigned and forwarded to a CR Manager who will manage it through the remainder of its life.  

A quick pre-assessment is conducted by the CR Manager to ensure straightforward items can be addressed quickly and more complex ones are sent for more detailed analysis.  Approx 10% of the requests will complete its assessment at this phase of the process.

The duration of this phase should be a 1 to 2 days.

Maturity level for items in this phase would typically be of a level 1 (IPR and other sanity checks having been completed).

Refer to the Work Request sub-process for more details.

Owner

Name Description Type
CCG Admin Role


2.3   Work Request Rationalisation sub-process 

Within this sub-process the more complex work requests are put forward for initial assessment by the complete CCG and from here it will get routed down the most appropriate path. This could be to be deferred, rejected or continue on for further analysis/investigation, and assigned to the appropriate investigating body.  At this point the bulk of work requests will go for further assessment.

This phase should be completed by 2 weeks of request submission.

Maturity level of work requests at this phase would typically be of a level 1,  Request such as Fast track items, which would have completed their assessment phase would be upgraded to maturity level 2.

Refer to the Work Request Rationalisation Sub-process for complete details.

Owner

Name Description Type
CR Manager Role


2.4   Work Request analysis & Assignment sub-process 

Within this phase, The stakeholders, (who could be a single person or a team of people depending on complexity of the request), review the work requests and provide an assessment, (which can be a single line in the requestor tracker or a detailed report - once again, depending on complexity of request), on their findings & recommendations. These return to the CCG where they are rejected or allocated to existing projects or a proposal to start the procedure to initate a new project.

Duration of this phase can take from 1 day to 3 months depending on completxity.

Once work request have completed their assessment, they will have progressed to a Maturity level 2.

Refer to the detailed 'Requirements Analysis and Assignment' Sub Process for complete details.

Owner

Name Description Type
Change Control Group Group


2.5   End Work Request capture & Rationalisation sub-process 



3.0  
Work Request Capture Process Narrative

Work Request Capture
Work Request Capture

Work requests entered via the online form are automatically stored in a central repository. From here it is sanity checked by TM Forum staff and the appropriate Maturity level, (default 1) is set.  It is then assigned and forwarded to a CR Manager who will manage it through the remainder of its life.  

A quick pre-assessment is conducted by the CR Manager to ensure straightforward items can be addressed quickly and more complex ones are sent for more detailed analysis.  Approx 10% of the requests will complete its assessment at this phase of the process.

The duration of this phase should be a 1 to 2 days.

Maturity level for items in this phase would typically be of a level 1 (IPR and other sanity checks having been completed).

Refer to the Work Request sub-process for more details.

Owner

Name Description Type
CCG Admin Role


3.1   Start Work request Capture Sub-Process 

3.2   Work Request on-line form 

Hyperlink

URL / File Path
http://www.tmforum.org/Community/groups/collaboration_program_cen ...  

When & Who:

This level of work request entry is usually used to capture:

1. General work requests which cross a number of programs

2. Work items for teams that are not being addressed within the current team scope.

3. Team submissions for change reflecting next body of work and collation of internal submissions etc.

4. Strategic planning

5. Or if in doubt as to where to submit the request.

Note:  Active team members who wish to submit requests of change/submssions that are within the scope of a body of work which is currently being addressed by their working team, should submit them directly into the team in question.

How:

To enter change requests or requests for work within the Collaboration program, select the Change Requests tab of the community and then Submit New Change Request. In the change request form you can either list the changes as text directly into the form, or upload a documented list or a revised word version of the particular TM Forum document (change tracking on) as an attachment.      

Owner

Name Description Type
Change Control Group Group


3.3   Request Submission Tracker 

Central database where all the changes are recorded, stored and tracked.

Owner

Name Description Type
Program Management Person who manages and maintains the Collaboration Program roadmap. Role


3.4   Collect Work requests 

Work requests, (which can take the form of:  requirements, change Requsts, deliverable review comments, solution proposals, catalyst results & examples, analyst reports, etc. ) are captured from various sources, (which include but not restricted to Technical Committee, Sector Heads, Interest Groups, communities, TMF Membership and the CCG).  It should be noted that Sector inputs will be treated in the same manner as other Collaboration Program Working Teams.

From here they will be entered and tracked within the Request tracking system, which can track Change requests or new requirements.  This allows easy tranfer of information through out the process as needs be.

To submit a Work request, details are entered into the relevant on-line Request Submission Form which is available from the community area.  The main entry forms include: Change Request and Deliverable Review comments.

Other mechanisms for the submission of work requests can be via the TM Forum Strategic plan. These requests need to be extracted from the plan and entered into the on-line tracking system. (It should be noted that the Strategic plan also provides prioritization information).

Note:  An active participant of a team should submit requests against work currently being addressed within their team, directly to that team.

Owner

Name Description Type
CCG Admin Role


3.5   Sanity check 

Once received, the administrator will do a quick sanity check to ensure it is completed correctly, organise the submissions into the correct categories, (e.g. discipline, domain, ,feature, solution etc.), and assign to the appropriate member of the CCG to act as CR Manager.

Work requests may include:

1. A formal submission of a problem; for example an error in the documentation, requesting that it be corrected, (e.g. a Deliverable Review Comment)

2. A request to make changes submitted as a marked solution; for example a new Artifact or revision to an existing Artifact to be included in the next release of an existing Baseline, (can be a Change Requests)

3. A request to address an identified problem in an existing baseline with no marked solution, (e.g. known as Change request)

4. A request for work in an area which is currently not being addressed, this may or may not have a marked solution and generally known as a new requirement.

During the sanity check the following items need to be considered:

** Is there enough information available with in the request to be able to address it

** Is the request related to material baselined within the remit of the CCG or should it go to the Team Leaders Group for more detailed analysis

** Does the request fall under one of the allowable types of request

** Is the request submitted by a TM Forum member or public.

** Are there obvious IPR implications

In instances where it is an obvious 'fast track' item, like deliverable review comments against a particular document of a cosmetic nature, the CCG admin can forward directly to the team (assigning it to an appropriate CR Manager, who will automatically get notified) and set the status to 'Fast Track'.

Duration of this phase would typically be a day.  Maturity level will default to 0 (not set) and upgraded to a level 1 after intial sanity check.  Note, any items set to fast track will be of a maturity level 2 as assessment has been complete.

Owner

Name Description Type
CCG Admin Role


3.6   Valid Submission 

If submission is not valid, it is closed from the system and a response sent to the requestor where appropriate.

Incoming Links

Name Description Link Label
Sanity check Sanatised Work Request

Outgoing Links

Name Description Decision
End Work Request Capture Sub-Process No
Fast track request Sub Process Obvious fast track
Pre-assess request Yes


3.7   Pre-assess request 

The assigned request is then pre-assessed by the CR Manager.  Focusing on:

a. Technical Completeness

b. Duplication to other requests or part requests

c. Conflicts to other requests

d. Conformance with product scope, standards, TM Forum strategy etc.

e. Whether the proposer has offered resources (Which can result in requests being put on hold)

Where possible, complex requests are broken down into components which relate to the technical program operations structure. Separate child change requests need to be created to accomodate this, linking back to the parent (original) request. After initial breakdown and as appropriate, these will route to the CCG for discussion.  To enable this, the CR Manger sets the status of the request to 'discussion required'.

At the discression of the CR Manager, clearly defined requests can be fast tracked through the system at this point, with its status being set to 'Fast track' .

Candiates for fast track will usually be:

a) An urgent fix for some major problem in the field" even where this may cause a change in other priorities

b) A clearly defined, simple body of work for a single team or existing orchestrated set of teams

c) Obvious that it is linked to an existing body of work which is being implemented and is in scope of that work

d) Natural extension to a current body of work, that appears to have no significant change to work load.

e) Bug fix to current release, (which may fast track the assessment process, but trickle through the development process)

f) Review comments of a cometic or straight forward nature.

Note: Work requests can only be fast tracked to a single team or an existing orchestrated set of teams which are currently working on 'the' or a closely related activity.

Pre-assessment can take anything from 1 day to a max of 2 weeks, with the Maturity Level ranging from 1 for those currently being assessed and a level 2 for the fast track items as assessment has been complete.

Owner

Name Description Type
CR Manager Role


3.8   Candiate for Fast track 

 Rule of Thumb - if in doubt DO NOT FAST TRACK a work request.

Work requests can only be fast tracked to a single team or an existing orchastrated set of teams which are currently working on 'the' or highly related activity.

Note:  No CCG vote required for fast track, but tagging allows the CCG to be aware and review those items.

Incoming Links

Name Description Link Label
Pre-assess request Work request item

Outgoing Links

Name Description Decision
Work Request Rationalisation sub-process No
Fast track request Sub Process Yes


3.9   Fast track request Sub Process 

The fast track mechanism allows for the quick turn around for work requests which are straight forward in nature and/or are of an urgent nature.

Refer to the Fast Track Request sub-process for details.

Owner

Name Description Type
CR Manager Role


3.10   Work Request Rationalisation sub-process 

Within this sub-process the more complex work requests are put forward for initial assessment by the complete CCG and from here it will get routed down the most appropriate path. This could be to be deferred, rejected or continue on for further analysis/investigation, and assigned to the appropriate investigating body.  At this point the bulk of work requests will go for further assessment.

This phase should be completed by 2 weeks of request submission.

Maturity level of work requests at this phase would typically be of a level 1,  Request such as Fast track items, which would have completed their assessment phase would be upgraded to maturity level 2.

Refer to the Work Request Rationalisation Sub-process for complete details.

Owner

Name Description Type
CR Manager Role


3.11   TM Forum Board 

The TM Forum board elected by the membership


3.12   Technical Committee 

The chief duties of this committee are to develop the strategic plan in collaboration with the members. It also provides advice and guidance to the board, participates in the review and approval of project charters and deliverables as well as input to the Strategic Operating Plan


3.13   Non TMF Members (Public) 

Denotes requests from other organisation or suggestions from outside the TM Forum Membership


3.14   Change Control Group 

The Change Control Group (CCG) will provide a single body for the review, analysis and approval of changes to an existing product baseline. Initially the baseline will focus on documentation sets. This will be expanded to include models and other product types in due course.

The Change Control Group will report to the Technical Committee and is tasked with responsibility for ensuring that the change control process as documented in TECH-07, Change Control Process, is adhered to by the TMF Technical Program.


3.15   TM Forum Membership 

Members of the TM Forum


3.16   CP Working Team 

Current list of Collaboration Program Working teams available from the communities at: http://www.tmforum.org/Community/groups/


3.17   Liaison Group 

Deals with interactions between TM Forum and other standards organizations where there are areas of common interest.


3.18   The Industry 

Groups of individuals and companies representing the communications Industry


3.19   Team Leaders Group 

The Team Leaders of all the standing technical teams are invited to join the Team Leaders Group, (TLG). The objectives of this group are:

• To maintain an oversight of the overall progress of the technical program

• To help review project charters and technical documents prior to submission to the Technical Committee for vote

• To identify complimentary areas between programs which may help to accelerate work

• To identify possible areas where programs are creating duplication or divergent approaches from strategic TMF directions

• To help in allocation of resources between projects where appropriate

• To help resolve conflict between teams and make recommendations to the Technical Committee

This team represents a broad constituency and have a good spread of technical knowledge. This team will get sight of project charters and technical documents so that comments and recommendations can be made to the Technical Committee to help them in voting.

The TLG aims to

• meet by conference call twice a month and at TAW to share progress in work and to discuss any points of conflict or overlap

have a significant impact on the direction of the TMF Technical Program


3.20   End Work Request Capture Sub-Process 



4.0  
Work Request Rationalisation sub-process Process Narrative

Work Request Rationalisation sub-process
Work Request Rationalisation sub-process

Within this sub-process the more complex work requests are put forward for initial assessment by the complete CCG and from here it will get routed down the most appropriate path. This could be to be deferred, rejected or continue on for further analysis/investigation, and assigned to the appropriate investigating body.  At this point the bulk of work requests will go for further assessment.

This phase should be completed by 2 weeks of request submission.

Maturity level of work requests at this phase would typically be of a level 1,  Request such as Fast track items, which would have completed their assessment phase would be upgraded to maturity level 2.

Refer to the Work Request Rationalisation Sub-process for complete details.

Owner

Name Description Type
CR Manager Role


4.1   Start Work Request Rationalisation Sub-Process 

4.2   Initial CCG assessment 

The pre-assessment of the work request, including any breakdown, (child CR), that may have been created can be presented to the CCG,

The CCG will quickly review the items to see if there are any underlying cross program, IPR or other implications.

It will then be agreed which route it, or the child requests should take.

If after discussion it is agreed that the request requires no further analysis it can be fast tracked to the assignment & implementation phase.

The work request entry is updated by either the CCG admin or CR Manager to record any key items of discussion & decisions made.

Duration of this will be 1 day, (discussed during meeting), Maturity level at this point will typically be a level 1.

Owner

Name Description Type
Change Control Group Group


4.3   Route Work Request 

The individual work request can fork at this point

1. If further clarification is required,  or perhaps a related activitiy needs to be completed before progressing with this item, the decision can be defered.  Note: Request should only go into the defered decision loop once.

2. If obvious conflicts or IPR issues etc. arise, then the work request can be rejected.

3. It is a valid request and should progress down the normal path.

Incoming Links

Name Description Link Label
Initial CCG assessment Work request

Outgoing Links

Name Description Decision
Call for RFP/Prospectes
Progress Work Request work request
Reject Request reject
Delay Decision Clarification Required


4.4   Call for RFP/Prospectes 

4.5   Delay Decision 

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. More assessment by CR Manager and Expert reviewers  (an additional week can be alloted in expection cases)

3. 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. ....).

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 as assessment will have been complete.

Owner

Name Description Type
Change Control Group Group


4.6   Progress Work Request 

The CCG will decide if this work request is obvious enough that it can be assigned to a team for implementation without further assessment. If yes then it can be fast tracked. I.e. if the request requires no further analysis

otherwise, the CCG and CR Manager must determine which teams and experts are required to complete an assessment of the request. Note: the experts could include other groups like the Team Leaders Group, Technical committee or SPLC.

Maturity level will typically be a level 1 as assessment would not be complete.

Owner

Name Description Type
Change Control Group Group


4.7   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

Name Description Type
Change Control Group Group


4.8   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).


4.9   Fast track request 

Did the CCG agree the request was a fast track item?

Incoming Links

Name Description Link Label
Progress Work Request valid Work Request

Outgoing Links

Name Description Decision
Fast track request Sub Process Yes
Work Request analysis & Assignment sub-process No


4.10   Fast track request Sub Process 

The fast track mechanism allows for the quick turn around for work requests which are straight forward in nature and/or are of an urgent nature.

Refer to the Fast Track Request sub-process for details.

Owner

Name Description Type
CR Manager Role


4.11   Work Request analysis & Assignment sub-process 

Within this phase, The stakeholders, (who could be a single person or a team of people depending on complexity of the request), review the work requests and provide an assessment, (which can be a single line in the requestor tracker or a detailed report - once again, depending on complexity of request), on their findings & recommendations. These return to the CCG where they are rejected or allocated to existing projects or a proposal to start the procedure to initate a new project.

Duration of this phase can take from 1 day to 3 months depending on completxity.

Once work request have completed their assessment, they will have progressed to a Maturity level 2.

Refer to the detailed 'Requirements Analysis and Assignment' Sub Process for complete details.

Owner

Name Description Type
Change Control Group Group


4.12   End of Work request rationalisation sub process 



5.0  
Work Request analysis & Assignment sub-process Process Narrative

Work Request analysis & Assignment sub-process
Work Request analysis & Assignment sub-process

Within this phase, The stakeholders, (who could be a single person or a team of people depending on complexity of the request), review the work requests and provide an assessment, (which can be a single line in the requestor tracker or a detailed report - once again, depending on complexity of request), on their findings & recommendations. These return to the CCG where they are rejected or allocated to existing projects or a proposal to start the procedure to initate a new project.

Duration of this phase can take from 1 day to 3 months depending on completxity.

Once work request have completed their assessment, they will have progressed to a Maturity level 2.

Refer to the detailed 'Requirements Analysis and Assignment' Sub Process for complete details.

Owner

Name Description Type
Change Control Group Group


5.1   Start Work Request Analysis & Assignment Sub-Process 

5.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

Name Description Type
CR Manager Role


5.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

Name Description Link Label
Access Work Request Work request

Outgoing Links

Name Description Decision
Validation of Request Straight forward items
Task team creation and Assessment highly complex work


5.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.


5.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

Name Description Type
CR Manager Role


5.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

Name Description Type
CR Manager Role


5.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

Name Description Type
Change Control Group Group


5.8   Vote decision 

At this point the work request is progressed appropriately.

Incoming Links

Name Description Link Label
Formal Vote on work request

Outgoing Links

Name Description Decision
Returning to Work Request Rationalization sub-process Further Assessment
Reject Request
Assign to working group(s)
delay item


5.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

Name Description Type
Change Control Group Group


5.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

Name Description Type
Change Control Group Group


5.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).


5.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

Name Description Type
Change Control Group Group


5.13   New working Team required? 

Incoming Links

Name Description Link Label
Assign to working group(s)

Outgoing Links

Name Description Decision
Plan & Schedule No
Make recommendation to the Technical Committee Yes


5.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.


5.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

Name Description Type
Change Control Group Group


5.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

Name Description Type
Team Leader Role


5.17   Charter required? 

Incoming Links

Name Description Link Label
Plan & Schedule

Outgoing Links

Name Description Decision
End Work Request analysis & Assignment sub-process No
Generate Charter Create a charter to reflect the work items for consideration and approval Yes


5.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

Name Description Type
Team Leader Role


5.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

Name Description Type
SVP Collaboration Program Person heading up the Collaboration Program of the TM Forum. Role


5.20   End Work Request analysis & Assignment sub-process 

5.21   Returning to Work Request Rationalization sub-process 



6.0  
Fast track request Sub Process Process Narrative

Fast track request Sub Process
Fast track request Sub Process

The fast track mechanism allows for the quick turn around for work requests which are straight forward in nature and/or are of an urgent nature.

Refer to the Fast Track Request sub-process for details.

Owner

Name Description Type
CR Manager Role


6.1   Start Fast track sub process 

6.2   Assign to team 

Work requests can only be fast tracked to a single team or an existing orchastrated set of teams which are currently working on