CP flow-V16

Process Narrative
 
Created: 04/07/2008
Last Modified: 07/11/2008




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

Table of Contents

   1.0   CP Process Flow
1.1   Start CP Process
1.2   Requirements capture and rationalisation Sub Process
1.3   Project Approval Sub Process
1.4   Development phase Sub Process
1.5   Initial Deliverable Approval Sub Process
1.6   Project deliverable(s)
1.7   Approved Project deliverables
1.8   SPLC
1.9   TPC
1.10   Membership
1.11   Sector Interest Group
1.12   End of CP process
   2.0   Requirements capture and rationalisation Sub Process
2.1   Start requirements capture and rationalisation sub process
2.2   Requirements capture
2.3   Requirements Rationalisation and prioritisation
2.4   Requirement Analysis and Assignment Sub Process
2.5   Product plans
2.6   Development phase Sub Process
2.7   Sector Heads
2.8   The Industry
2.9   Sector Interest Group
2.10   Community
2.11   Technical Committee
2.12   Membership
2.13   Liaison Groups
2.14   TM Forum Board
2.15   End Requirements Capture and rationalisation sub process
   3.0   Requirement Analysis and Assignment Sub Process
3.1   Start Requirements Analysis and Assignment Sub Process
3.2   Review requirements
3.3   Identify Development Team Decision
3.4   Assign to existing team
3.5   New charter required Decision
3.6   Iniate new project Team
3.7   Prepare Charter
3.8   Project Approval Sub Process
3.9   Development phase Sub Process
3.10   Project Requirements
3.11   End Requirements Analysis and Assignment sub process
   4.0   Project Approval Sub Process
4.1   Start Project Approval process
4.2   Submit proposed charter
4.3   Charter distrubution
4.4   AC Approval Decision
4.5   Process and Post Deliverable
4.6   Archive Deliverable
4.7   Approved Project Charter
4.8   TMF413 Approvals Submission form
4.9   The Industry
4.10   Team Leader
4.11   End Project Approval process
   5.0   Development phase Sub Process
5.1   Start Development phase
5.2   Define format of deliverables
5.3   Develop Deliverables
5.4   Team reviews and updates
5.5   CCB process
5.6   End of development phase
   6.0   Initial Deliverable Approval Sub Process
6.1   Start Deliverable approval process
6.2   Project deliverable(s)
6.3   Submit for approval
6.4   Is deliverable a CCB Baseline Artifact
6.5   Deliverable Member Evaluation & Review Sub Process
6.6   AC Approval Decision
6.7   CCB process
6.8   Deliverable Posting
6.9   Deliverable to continue for TM Forum Approval decision
6.10   Formal 'TM Forum Approval' Sub Process
6.11   Archive Deliverable
6.12   TMF413 Approvals Submission form
6.13   Team Leader
6.14   Membership
6.15   Remain in member evaluated
6.16   End Deliverable Approval
   7.0   Deliverable Member Evaluation & Review Sub Process
7.1   Start Delierable review
7.2   Quality Assurance Check
7.3   Expert review
7.4   For Public Review decision
7.5   Post deliverable to the public domain
7.6   Public review
7.7   Post deliverable to member only domain
7.8   Member review
7.9   Capture comments
7.10   End AC Approval Process
   8.0   Formal 'TM Forum Approval' Sub Process
8.1   Start TM Forum Approval process
8.2   Invite members to vote
8.3   Gather cast votes
8.4   Process Votes
8.5   Result of Vote
8.6   Process deliverable to TM Forum Approved status
8.7   Process Unapproved Document
8.8   End TM Forum Approval Process
   9.0   CCB process
9.1   Start CCB process
9.2   Receipt of Request Sub Process
9.3   Determine if CR or Approvals Submission ( Base Artifact )
9.4   Pre-access CR
9.5   Determine type of CR being requested
9.6   Normal CR Sub process
9.7   Fast-Track CR Sub Process
9.8   Base Artifact Request Sub Process
9.9   End CCB Process
   10.0   Receipt of Request Sub Process
10.1   Start Receipt of Request sub process
10.2   Validate Request
10.3   A valid Request
10.4   Register Request
10.5   Reject Request
10.6   Pre Assess Request
10.7   End Receipt of Request Sub process
   11.0   Base Artifact Request Sub Process
11.1   Start Base Artifact Request Sub process
11.2   Decide on Course of action for Approvals Submission.
11.3   Defer Decision
11.4   Reject Decision
11.5   Esculation Option
11.6   Assess Approvals Submission
11.7   Vote on Approvals Submission
11.8   Close CR and Approvals Submission
11.9   End Base Artifact Request Sub Process
   12.0   Fast-Track CR Sub Process
12.1   Start Fast Track Sub Process
12.2   Determine course of action for CR
12.3   Defer Decision
12.4   Reject Decision
12.5   Esculation Option
12.6   CR Implementation
12.7   Base Artifact Request Sub Process
12.8   Normal CR Sub process
12.9   End of Fast Track Sub Process
   13.0   Normal CR Sub process
13.1   Start Normal CR Sub-Process
13.2   Determine course of action for CR
13.3   Defer Decision
13.4   Reject Decision
13.5   Esculation Option
13.6   Assess CR
13.7   Formal Vote on CR
13.8   CR Implementation
13.9   Base Artifact Request Sub Process
13.10   End Normal CR sub process


1.0  
CP Process Flow Process Narrative

CP Process Flow
CP Process Flow

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 document ‘ Using the Collaboration Workspace for Document Release’ be referenced as it gives useful information as to how to use the Collaboration workspace to assist with the document release process.


1.1   Start CP Process 

This process describes the Collaboration Program end to end process from the capture of requirements through to delivery of TMF material.  It includes such items as project initiation, review, approval stages etc.

Owner

Name Description Type
VP Collaboration Program Role


1.2   Requirements capture and rationalisation Sub Process 

New requirements may be captured from a number of different sources.  These requirements need to brought together into a single, consolidated requirements stream with an agreed priority level.

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

Owner

Name Description Type
Product manager Manages the development and delivery of products Role


1.3   Project Approval Sub Process 

The Project Approval sub-process describes the activities necessary for the approval of a new project.  A new project can take the form of 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
AC Coordinator Staff person supporting the Approval Committee and approval process Role


1.4   Development phase 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
Product manager Manages the development and delivery of products Role

Requirements

Name Description Type
Approved Project charter Project charter that has sucessfully completed the approval process and has been approved by the AC Requirement
Consolidated Requirements Requirements collected from various sources are collected into a set of consolidated requirements Requirement
Project management report Report against project plan and charter Requirement
Project plans Detailed projects plans identifying deliverables and projected delivery dates Requirement
Roadmaps User focussed roadmaps identify the furture funtionality for the product and projected delivery dates. Requirement
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement
TMF413 Approvals Submission form Form to be submitted with any request for approval, charter or deliverable Requirement


1.5   Initial Deliverable Approval Sub Process 

The purpose of this sub-process is to concentrate on the final phase of the Technical Project Lifecycle – namely evaluation and release of the project/Team deliverables. It is to clearly outline the various steps a typical project will go through. Exceptions will be mentioned but not addressed in any great detail.

Refer to the detailed 'Initial Deliverable Approval' Sub Process for complete details.

Owner

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role

Requirements

Name Description Type
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement
TMF413 Approvals Submission form Form to be submitted with any request for approval, charter or deliverable Requirement


1.6   Project deliverable(s) 

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

Owner

Name Description Type
Team Leader Individual responsible for managing the project team Role


1.7   Approved Project deliverables 

A suite of approved deliverables, documents model files etc, that satisfy the objectives of the project.  Deliverable can be identified as:

900 guidebooks

800 IIS

700 Definitions

600 I.A.

500 B.A.

400 templates

300 Release Notes

200 Contracts

100 T.R.

000 spec

Owner

Name Description Type
Product manager Manages the development and delivery of products Role


1.8   SPLC 

The Service Provider Leadership Council (SPLC) consists of a group of service providers from around the world who work together to create a unified voice for service providers’ needs from their OSS/BSS vendors.

The SPLC recommendations are used to drive TM Forum work, and as such drive development of industry standards for the telecom software community as a whole.


1.9   TPC 

The team leaders of all the standing technical teams are invited to join the Technical Program Steering Council. The objectives of the council 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 approvals committee

• 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 (such as NGOSS)

• To help in allocation of resources between projects where appropriate

• To help resolve conflict between teams and make recommendations to the technical committee/Approvals 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 approvals committee to help them in voting. The collated comments from the TPC and forward them to the Approvals Committee for their consideration

The council aims to

• meet by conference call once 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


1.10   Membership 

The TM Forum membership


1.11   Sector Interest Group 

The sector Heads can initiate the creation of sector interest groups to research and address specific areas of their industry.  These groups are made up from representatives from Member companies. These groups will in turn liase with other discussion forum, e.g. other project teams within the Collaboratin Program and/or other standards bodies through the Liaison process, to validate or indeed expand upon the existing requirements.


1.12   End of CP process 



2.0  
Requirements capture and rationalisation Sub Process Process Narrative

Requirements capture and rationalisation Sub Process
Requirements capture and rationalisation Sub Process

New requirements may be captured from a number of different sources.  These requirements need to brought together into a single, consolidated requirements stream with an agreed priority level.

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

Owner

Name Description Type
Product manager Manages the development and delivery of products Role


2.1   Start requirements capture and rationalisation sub process 

Requirements are captured, consolidated into a single requirements stream and prioritised.


2.2   Requirements capture 

Requirements are captured from various sources, which includes but not restricted to Sector Heads, Interest Groups, communities and the CCB. 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 if needs be.

To submit a requirement, the TMF416, Request Submission Form is completed and emailed to ccb@tmforum.org. The form can be sourced from the templates & forms section of the Document Library on the TM Forum web page.

Once received, the administrator will sort the submissions into the correct categories, ( i.e. Change Request or New Requirement), and enter it into the tracking tool appropriately.

Owner

Name Description Type
Product manager Manages the development and delivery of products Role

Requirements

Name Description Type
Business Strategy TM Forum business strategy Requirement
CCB Requirements Requirements captured from the CCB (Change Requests) Requirement
Consolidated Requirements Requirements collected from various sources are collected into a set of consolidated requirements Requirement
Detailed technical strategy Provides an in-depth strategy to steer the Collaboration Program. It is derived from the Board strategy document. Requirement
Sector requirements Requiremets collected by the sector heads and sector interest groups Requirement

Performed By

Name Description Type
CCB Change Control Board Group
Community Communities representing specific industry sectors Group
Sector Heads Sector Czars are specialists in the sector that they represent and drive the participation of companies in their market sector in the TM Forum Role
Sector Interest Group Sector Interest Groups represent the interest of their industry sector within the Collaboration Program Group
The Industry The communications industry Group
TPC Chair Chair of the Technical Program Council Role


2.3   Requirements Rationalisation and prioritisation 

The TM Forum staff Senior Product Manager will call regular review meetings, initially once per month, where the key stakeholders will be asked to review the captured requirements against the TM Forum strategy developed by the Board of Directors and and agree their priority.

The required attendees for this meeting include:  Product Managers, Sector Heads, TPC Chair, Technical Committee Chair.

The format of the meeting will broadly follow that of a CCB meeting where:

** Meeting agenda will be issued in advance of the Requirements meeting

** Requirements will be broken out into their states and discuss appropriately i.e.

       *** New - Just entered onto the system

       *** Investigation - Assigned to a Requirements Manager who will Project Manage it through the lifecycle until implementation

       *** Approved  - By the requirements Board for implementation and assigned to the appropriate teams.

       *** Closed - This can be closed implemented, closed rejected, closed withdrawn.

** Key points of dicussions, and all decisions will be recored on the tracking tool.

The overall process will enable each requirement to be tracked throughout it lifecycle i.e. from capture to implementation (or rejection).

Owner

Name Description Type
Product manager Manages the development and delivery of products Role

Requirements

Name Description Type
Business Strategy TM Forum business strategy Requirement
CCB Requirements Requirements captured from the CCB (Change Requests) Requirement
Consolidated Requirements Requirements collected from various sources are collected into a set of consolidated requirements Requirement
Detailed technical strategy Provides an in-depth strategy to steer the Collaboration Program. It is derived from the Board strategy document. Requirement
Sector requirements Requiremets collected by the sector heads and sector interest groups Requirement

Performed By

Name Description Type
Product manager Manages the development and delivery of products Role
Sector Heads Sector Czars are specialists in the sector that they represent and drive the participation of companies in their market sector in the TM Forum Role
Technical Committee Chair Chairperson for the Technical Committee Role
TPC Chair Chair of the Technical Program Council Role


2.4   Requirement Analysis and Assignment Sub Process 

Within this phase, The stakeholders review new requirements and either allocates to existing projects or start the procedure to initate a new project.

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

Owner

Name Description Type
Product manager Manages the development and delivery of products Role

Requirements

Name Description Type
Detailed project / product requirements that are used for developing the product. Requirement
Business Strategy TM Forum business strategy Requirement
Consolidated Requirements Requirements collected from various sources are collected into a set of consolidated requirements Requirement
Detailed technical strategy Provides an in-depth strategy to steer the Collaboration Program. It is derived from the Board strategy document. Requirement
Project management data 'Real time' data on project progress Requirement
Project plans Detailed projects plans identifying deliverables and projected delivery dates Requirement
Roadmaps User focussed roadmaps identify the furture funtionality for the product and projected delivery dates. Requirement
TMF415 Product plans detailed product plans indcluding roadmaps and go to market plans Requirement

Performed By

Name Description Type
Product manager Manages the development and delivery of products Role
SPLC Service Provider Leadership Council Group
Team Leader Individual responsible for managing the project team Role
Technical Committee Sub-committee of the board that provides the detailed technical strategy and guidance for technical projects Group
TPC Technical Program Council Group


2.5   Product plans 

Product plans are produced for each product area.  

For each product identified within the roadmap, a Product Plan should be created. These documents are created by the Product Manager using the TMF415, Product Plan template which is available on the TMF Web page in the Document Library under templates & forms section. The Product Plan provides more detailed information about the product, its contents and how it will be delivered into the industry. It also highlights any dependencies across other product lines. These are published to the membership and provided to the TM Forum board and sub committees including the Technical Committee.

Owner

Name Description Type
Product manager Manages the development and delivery of products Role


2.6   Development phase 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
Product manager Manages the development and delivery of products Role

Requirements

Name Description Type
Approved Project charter Project charter that has sucessfully completed the approval process and has been approved by the AC Requirement
Consolidated Requirements Requirements collected from various sources are collected into a set of consolidated requirements Requirement
Project management report Report against project plan and charter Requirement
Project plans Detailed projects plans identifying deliverables and projected delivery dates Requirement
Roadmaps User focussed roadmaps identify the furture funtionality for the product and projected delivery dates. Requirement
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement
TMF413 Approvals Submission form Form to be submitted with any request for approval, charter or deliverable Requirement


2.7   Sector Heads 

The Sector Head is a role which is perfomed by an individual person.

This role, which focuses on an individual industry sector, is to represent it in an effort to drive the TM Forum work to statisfy the needs of that particular sector.

This position is held by a TM Forum staff person.

Owner

Name Description Type
TM Forum Board The TM Forum board elected by the membership Group

Assigned Personnel

Name Description Type
Sector Interest Group Sector Interest Groups represent the interest of their industry sector within the Collaboration Program Group


2.8   The Industry 

The great and vast mass which makes up the communications industry.


2.9   Sector Interest Group 

The sector Heads can initiate the creation of sector interest groups to research and address specific areas of their industry.  These groups are made up from representatives from Member companies. These groups will in turn liase with other discussion forum, e.g. other project teams within the Collaboratin Program and/or other standards bodies through the Liaison process, to validate or indeed expand upon the existing requirements.


2.10   Community 

These are like minded people who come together to discuss a particular issue, e.g. web communitites.


2.11   Technical Committee 

The chief duties of this committee are to develop the technical strategy for the TMF collaboration program. It also provides advice and guidance to the board, participates in the review and approval of project charters and documents as well as input to the Strategic Operating Plan

Owner

Name Description Type
TM Forum Board The TM Forum board elected by the membership Group

Requirements

Name Description Type
Technical Strategy Detailed techical strategy derived from the Board strategy Requirement


2.12   Membership 

Members of the TM Forum


2.13   Liaison Groups 

2.14   TM Forum Board 

2.15   End Requirements Capture and rationalisation sub process 



3.0  
Requirement Analysis and Assignment Sub Process Process Narrative

Requirement Analysis and Assignment Sub Process
Description Review new requirements and allocate to projects
Requirement Analysis and Assignment Sub Process

Within this phase, The stakeholders review new requirements and either allocates to existing projects or start the procedure to initate a new project.

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

Owner

Name Description Type
Product manager Manages the development and delivery of products Role

Requirements

Name Description Type
Detailed project / product requirements that are used for developing the product. Requirement
Business Strategy TM Forum business strategy Requirement
Consolidated Requirements Requirements collected from various sources are collected into a set of consolidated requirements Requirement
Detailed technical strategy Provides an in-depth strategy to steer the Collaboration Program. It is derived from the Board strategy document. Requirement
Project management data 'Real time' data on project progress Requirement
Project plans Detailed projects plans identifying deliverables and projected delivery dates Requirement
Roadmaps User focussed roadmaps identify the furture funtionality for the product and projected delivery dates. Requirement
TMF415 Product plans detailed product plans indcluding roadmaps and go to market plans Requirement

Performed By

Name Description Type
Product manager Manages the development and delivery of products Role
SPLC Service Provider Leadership Council Group
Team Leader Individual responsible for managing the project team Role
Technical Committee Sub-committee of the board that provides the detailed technical strategy and guidance for technical projects Group
TPC Technical Program Council Group


3.1   Start Requirements Analysis and Assignment Sub Process 

3.2   Review requirements 

The stakeholders (or Requirements Board), review each new requirement to determine the priority of the requirement against need to deliver to the industry and any linkages to other requirements.

This task will be conducted via a quarterly meeting or as required. A meeting notice will be forwarded in advance outlining the list of requirements up for discussion.  This list will be generated from the tracking tool.

A dedicated collaboration workspace area and exploder will be available to support this effort.

Owner

Name Description Type
Product manager Manages the development and delivery of products Role

Performed By

Name Description Type
Product manager Manages the development and delivery of products Role
SPLC Service Provider Leadership Council Group
Technical Committee Sub-committee of the board that provides the detailed technical strategy and guidance for technical projects Group
TPC Technical Program Council Group


3.3   Identify Development Team Decision 

The Requirements team review the list of teams to determine the best possible fit for the requirements.  Previously closed teams maybe considered with a view to rescurrecting them once more.

Where possible the Requirements Team will identify if there are impacts across a number of teams and will assign it to the most appropriate team to take ownership. The team assigned ownership of the requirement will ensure that it is co-ordinated with all other effected teams until it is implementated completely.

Incoming Links

Name Description Link Label
Review requirements Each requirement is reviewed with a view to implementation. List of Requirements

Outgoing Links

Name Description Decision
Iniate new project Team Create a New team or rescurrect a previously closed team. No
Assign to existing team requirements assigned to current teams in the appropriate manner Yes


3.4   Assign to existing team 

A project requirements document is created which lists the requirements which are being assigned and the implenting team(s). In the case of multiple teams, the team who is assigned ownership will be highlighted.

Requirements targeted for exisiting teams can take 2 forms.

 a: Teams whose output are baselined and managed by the CCB. These requirements will take the form of a CR and follow the CCB process.

 b. For teams who work outside of the CCB, then these requirments will be sent directly to the Team Leader and associated TMF Staff support. Who will address them via the charter process.

Each requirement will be analysed by the team to determine if it 'fits' with the current phase of the project and that there are suitable resources available, or that it should be carried over to the next phase of work.

Owner

Name Description Type
TPC Technical Program Council Group

Performed By

Name Description Type
Product manager Manages the development and delivery of products Role
TPC Technical Program Council Group


3.5   New charter required Decision 

Eventhough the ultimate decision lies with the Approval Committee, other involved parties to this stage may include: Product Manager and Team Leader

Owner

Name Description Type
Approval Committee The Approval Committee is the operational body that approves technical work projects and the release of technical team deliverables Group

Incoming Links

Name Description Link Label
Assign to existing team requirements assigned to current teams in the appropriate manner

Outgoing Links

Name Description Decision
Prepare Charter Create or update an existing charter. Yes
Development phase Sub Process Develolment of project deliverables in line with the project charter No


3.6   Iniate new project Team 

Project Champion(s) is identified and the process for creating a team is initated.  An assigned Technical Staff Member will provide support to the Project Champion for the creation of a team through one or a combination of ways, namely:

1. Through the creation of an interest group,i.e. a pre-charter group.

2. Through emailing the various TMF mail aliases

3. Conduct an “open call for participation” via the TM Forum Central newsletter, webinar sessions, Booth presentations at Management worlds, direct calling etc.

(Initializing a team this way usually requires more planning upfront by 2 or more companies. The notice should include a description of the project, target objectives, and team leader contact information.)

Once the team is established, a Team Leader is selected by the team and this person will take the overall responsibility for running the team. TM Forum Staff members are not candidates for the Team Leader position.

New projects must support the detailed technical strategy provided by the Technical Committee.

The assigned Staff Person starts setting up the Team Infrastructure e.g. team space on Collaboration Workspace and set correct folders, create required exploders, request TPC leader to add the new Team Leader to the TPC list. The staff support should also ensure that the new Team Leader is aware of and equipped with a copy of the 'Team Leaders Handbook'.

Owner

Name Description Type
VP Collaboration Program Role

Requirements

Name Description Type
Consolidated Requirements Requirements collected from various sources are collected into a set of consolidated requirements Requirement

Performed By

Name Description Type
Project Champions(s) If necessary, identify a project champion for the new project(s) Role
Team Leader Individual responsible for managing the project team Role
TM Forum Staff Support TM Forum staff support person allocated to the project Role
TPC Technical Program Council Group


3.7   Prepare Charter 

1 Determine the scope and duration of the project and the most appropriate format the project deliverables should take, e.g. Guide Book, Technical Report, Model, other machine readable artifacts, etc.

2 Complete Charter (ref: TMF 405 Template) indicating which phase the Charter is referring to (if appropriate).Ensure Charter is completed fully, including physical format of deliverables e.g. Guide Book, Technical Specification, Model, executable etc.  

3 Send document, to TMF Team Members for review and/or request for additional team members, with a date for comments to be returned by.

4 Collate review comments and incorporate into the Charter as appropriate.

5 Ensure the project is properly resourced and all critical roles are filled, including team leader, project sponsor, and editor

6 Complete initial version of the TMF413 Approvals Submission form. Post Charter and initial Approvals form to the ‘Submitted Documents Folder on the CWS and inform TM Forum staff member that it is ready for submission into the AC review process.

7. TMF staff support  person supporting the team reviews the material for any errors, cosmetic or template issues and when ready informs the AC co-ordinator that the document is available for approval, providing 'premalink' details for each of the documents.  If the team is operating as a closed team then the staff person must makes sure a copy of all material is placed in the appropriate directory on the TPC workspace and use those permalinks provided.


3.8   Project Approval Sub Process 

The Project Approval sub-process describes the activities necessary for the approval of a new project.  A new project can take the form of 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
AC Coordinator Staff person supporting the Approval Committee and approval process Role


3.9   Development phase 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
Product manager Manages the development and delivery of products Role

Requirements

Name Description Type
Approved Project charter Project charter that has sucessfully completed the approval process and has been approved by the AC Requirement
Consolidated Requirements Requirements collected from various sources are collected into a set of consolidated requirements Requirement
Project management report Report against project plan and charter Requirement
Project plans Detailed projects plans identifying deliverables and projected delivery dates Requirement
Roadmaps User focussed roadmaps identify the furture funtionality for the product and projected delivery dates. Requirement
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement
TMF413 Approvals Submission form Form to be submitted with any request for approval, charter or deliverable Requirement


3.10   Project Requirements 

Requirements against exisiting projects are documented and sent to the CCB or directly to the project team as appropriate

Owner

Name Description Type
Product manager Manages the development and delivery of products Role

Requirements

Name Description Type
Consolidated Requirements Requirements collected from various sources are collected into a set of consolidated requirements Requirement


3.11   End Requirements Analysis and Assignment sub process 



4.0  
Project Approval Sub Process Process Narrative

Project Approval Sub Process
Description Project Approval sub -process
Project Approval Sub Process

The Project Approval sub-process describes the activities necessary for the approval of a new project.  A new project can take the form of 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
AC Coordinator Staff person supporting the Approval Committee and approval process Role


4.1   Start Project Approval process 

Owner

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role


4.2   Submit proposed charter 

1TMF staff support  person supporting the team reviews the material for any errors, cosmetic or template issues. The deliverables and completed AC Approval Form should be stored in the 'Submitted Documents' folder of the teams CWS. The Staff person should ensure that the correct version numbering is applied both in the document and in the CWS, (refer to the document numbering process).

2. Once it is ready the Staff person informs the AC co-ordinator that the documents are available for approval, providing 'premalink' details for each of the documents.

3.If the team is operating as a closed team then the staff person must makes sure a copy of all material is placed in the appropriate directory on the TPC workspace and those permalinks provided.

Owner

Name Description Type
Team Leader Individual responsible for managing the project team Role

Requirements

Name Description Type
Charter Project charter identify the scope and keyt components of the project Requirement
TMF413 Approvals Submission form Approval Committe Submission Form Requirement

Performed By

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role
Team Leader Individual responsible for managing the project team Role
TMF Staff Support Person Person assigned to assist a particular team Role


4.3   Charter distrubution 

The AC Coordinator takes the charter, checks the current amount of material out for review and forwards it to the Approval Committee with review instructions and timeframe. The charter is also sent to Subject Matter Experts, the SPLC and the TPC for comment.

SPLC and TPC are notified of the cut off date for comments which will provide time for the AC to review the comments before making the final approval decision

Owner

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role

Requirements

Name Description Type
Charter Project charter identify the scope and keyt components of the project Requirement
TMF413 Approvals Submission form Form to be submitted with any request for approval, charter or deliverable Requirement

Performed By

Name Description Type
Approval Committee The Approval Committee is the operational body that approves technical work projects and the release of technical team deliverables Group
SPLC Service Provider Leadership Council Group
Subject Matter Expert Individuals with detailed knowledge in a specific domain area Role
TPC Technical Program Council Group


4.4   AC Approval Decision 

The AC reviews deliverables and considers the comments from the SPLC, TPC and other subject matter experts and either accpets or rejects the submission.

Note:  It is at this point that the CTO would have reflected on any requests to

      1. not put a document forward for Formal TM Forum Approval

      2. To make documents available to the public for purchase or otherwise

and inform the AC co-ordinator of the decision results, who will record it in the Approvals Submission form.

Owner

Name Description Type
Approval Committee The Approval Committee is the operational body that approves technical work projects and the release of technical team deliverables Group

Requirements

Name Description Type
Approved Deliverables Deliverables that have completed the approval process Requirement
Charter Project charter identify the scope and keyt components of the project Requirement
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement

Incoming Links

Name Description Link Label
Charter distrubution The charter is distributed to the Approval committee for approval along with review end date

Outgoing Links

Name Description Decision
Process and Post Deliverable Final processing is conducted on the Deliverable and it is posted to the TM Forum Web page. Approved
Archive Deliverable Rejected or out of date material is archieved on the system. Rejected


4.5   Process and Post Deliverable 

Once approved, any comments or actions are sent by the AC Cordinator to the team leader.  Depending on the level of comments the team may be required to update the deliverables to reflect the comments and up-version them in the 'submitted folder' on the CWS and the AC Coordinator is informed of its completion.

The Document Release Manager is then informed by the AC Co-ordinator that the deliverable has been approved with or without comments and ready for final processing.

The Document Release Manager will make any final adjustments required and post the updated deliverable to the exisiting team web page or request a web page for a new team if one does not already exsit.

If not already available an email exploder, collaboration workspace and web community are setup for the team.

The deliverable is baselined in the 'approved documents folder' of the teams CWS area.


4.6   Archive Deliverable 

The AC Coordinator informs the Team Leader and Document Release Manager that the deliverable has been rejected and if material is rejected by an approvals committee - it cannot be posted to the TM Forum web page.

The Document Release Manager archives the deliverable on the CWS or the team may decide to restart the work again.


4.7   Approved Project Charter 

Approved project chater - review after 6 months

Owner

Name Description Type
Document Release Manager Responsible for processing and posting documents Role


4.8   TMF413 Approvals Submission form 

Hyperlink

URL / File Path
http://www.tmforum.org/page33676.aspx  

This form is to be used when submitting a project charter or project deliverable for approval by the Approvals Committee (AC) or Change Control Board (CCB) prior to Member Evaluation and/or TMF web posting

Owner

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role


4.9   The Industry 

The great and vast mass which makes up the communications industry.


4.10   Team Leader 

Individual responsible for managing the project team


4.11   End Project Approval process 

If the project has been approved it then enters the devlopment phase.

If rejected the team may modify their proposal and resubmit or disband




5.0  
Development phase Sub Process Process Narrative

Development phase Sub Process
Description Develolment of project deliverables in line with the project charter
Development phase 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
Product manager Manages the development and delivery of products Role

Requirements

Name Description Type
Approved Project charter Project charter that has sucessfully completed the approval process and has been approved by the AC Requirement
Consolidated Requirements Requirements collected from various sources are collected into a set of consolidated requirements Requirement
Project management report Report against project plan and charter Requirement
Project plans Detailed projects plans identifying deliverables and projected delivery dates Requirement
Roadmaps User focussed roadmaps identify the furture funtionality for the product and projected delivery dates. Requirement
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement
TMF413 Approvals Submission form Form to be submitted with any request for approval, charter or deliverable Requirement


5.1   Start Development phase 

Development of the project deliverables as defined in the approved project charter

Owner

Name Description Type
Team Leader Individual responsible for managing the project team Role

Requirements

Name Description Type
Detailed project / product requirements that are used for developing the product. Requirement
Approved Project charter Project charter that has sucessfully completed the approval process and has been approved by the AC Requirement
Detailed technical strategy Provides an in-depth strategy to steer the Collaboration Program. It is derived from the Board strategy document. Requirement
Project plans Detailed projects plans identifying deliverables and projected delivery dates Requirement
Roadmaps User focussed roadmaps identify the furture funtionality for the product and projected delivery dates. Requirement


5.2   Define format of deliverables 

** The deliverables may be developed by one or more development teams and documented using the appropriate document template for the deliverable (as defined in the charter).

** Download the appropriate template from the template area of the Document Catalog sub-section of the ‘Document Library’ area of www.tmforum.org

** If a new document, the Assigned TM Forum Staff member request a document number from the Document Release Manager, providing the team name, document type and title of the proposed document.

** If a continuation to an existing document, then the document version is updated as outlined in the Document Release Numbering Process

** Choose an editor for each deliverable.  By default the Team Leader accepts the role of Editor until assigned to another team participant. This information is then advertised in the document and the Document Release Manager is informed.

Owner

Name Description Type
Team Leader Individual responsible for managing the project team Role

Performed By

Name Description Type
Document Release Manager Responsible for processing and posting documents Role
Product manager Manages the development and delivery of products Role
Project Team Project team(s) chartered to develop the products and deliverables Group


5.3   Develop Deliverables 

1 The team meet regularly (via conference call, or in person as appropriate) to solve the issue at hand and document as part of project deliverables.Team Leader reminds their team of the IPR agreement at the beginning of each meeting and calls for any IPR items.

2 Meeting minutes are documented and distributed by the Team Leader or assigned person and stored on the Team Collaboration Workspace (CWS).

3 Any contributions by members to the project deliverable development must follow the submissions and Patent Disclosure processes as outlined in the Operating Guide and the Submission Form (TMF412) should be completed,. Details should be stored on the CWS where possible.

Note: it is possible for any member to record any patent information relating to the TMF material via a link from the TMF web page.

4 Change Requests (CR) may be received from the Change Control Board (CCB) and the team must address them appropriately.

5 In the course of normal team work, the team itself may identify CRs (against their own team or other teams) to be passed to the CCB for consideration.  CRs may be captured and managed through the gForge tool.

6 Available tools, such as the. CWS, email exploders must be used by the team to assist with the storage and sharing of all work in progress material. It is the responsibility of the Editors to ensure the correct versions are available.

Linked Resources

Name Description Type
Team Leader Individual responsible for managing the project team Role

Performed By

Name Description Type
Project Team Project team(s) chartered to develop the products and deliverables Group


5.4   Team reviews and updates 

1 Team Leader/Editor releases Project Deliverable to the team and/or other Peer Teams and informs them of where to find document(s) on CWS along with any other review details, i.e. comment period and review meeting date, comment method e.g. web communities etc..

2 Reviewing Team(s) return comments via the requesting team exploder within the allotted time.

3 Team agrees on acceptance/rejection of comments. If comment is accepted, then Editor includes the contributors name in the Contribution List section of the document and Team Leader ensures the contribution process is followed, (see Operating Guide).

4 The Editor updates the deliverables and once complete, posts it in the ‘Submitted Documents’ folder on the CWS. A set of release notes for the document/suite must be completed for and packaged with each new release of the work to the AC or CCB, (template TMF409)

5 The Approval Submission form (TMF413) should be downloaded from the template section of the TMF web page, completed and stored in the Submitted Document folder of the CWS along with the associated deliverables. If approval is being sought by the CCB, then the CCB should be informed when the documents are posted by sending an email to ccb@tmforum.org

6 Team agreement on submitting the deliverable for approval must be recorded as either a separate activity or in the minutes of the team meeting where agreement was reached.

7 The Team Leader or Editor informs the TM Forum Staff member that it is ready to proceed to the next stage.

Owner

Name Description Type
Team Leader Individual responsible for managing the project team Role

Performed By

Name Description Type
Project Team Project team(s) chartered to develop the products and deliverables Group


5.5   CCB process 

Change Control Board (CCB) will provide a single body for the approval of changes to the existing NGOSS baseline.

The NGOSS Change Control Board will report to the TMF Approvals Board and is chartered with responsibility for ensuring that the change control process as documented, is adhered to by the TMF Collaboration Program.

In addition to the process description outlined here, CCB definition and Terms of Reference are documented in the Word document Tech-07, Change Control Board definitions and terms of reference.

Linked Resources

Name Description Type
Hyperlink


5.6   End of development phase 

On completion of development, the team submits its deliverables for review.  It may then start an other phase of development by submitting a new project charter.




6.0  
Initial Deliverable Approval Sub Process Process Narrative

Initial Deliverable Approval Sub Process
Initial Deliverable Approval Sub Process

The purpose of this sub-process is to concentrate on the final phase of the Technical Project Lifecycle – namely evaluation and release of the project/Team deliverables. It is to clearly outline the various steps a typical project will go through. Exceptions will be mentioned but not addressed in any great detail.

Refer to the detailed 'Initial Deliverable Approval' Sub Process for complete details.

Owner

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role

Requirements

Name Description Type
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement
TMF413 Approvals Submission form Form to be submitted with any request for approval, charter or deliverable Requirement


6.1   Start Deliverable approval process 

Owner

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role


6.2   Project deliverable(s) 

All submitted artifacts must be located in the team CWS 'submitted documents' folder

The submission must be accompanied by a completed TMF413 Approval Submission form .  The form (TMF413) should be completed and stored in the Submitted Document folder of the CWS along with the associated deliverables.(if appropriate the CCB should be notified of all posted documents via an email to ccb@tmforum.org)

Owner

Name Description Type
Team Leader Individual responsible for managing the project team Role

Requirements

Name Description Type
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement


6.3   Submit for approval 

When the deliverble(s) is ready for release, the TMF staff support  person supporting the team reviews the material for any errors, cosmetic or template issues and informs the AC co-ordinator or CCB Admin as appropriate when ready, that the document is available for approval, providing 'premalink' details for each of the documents.  

If the team is operating as a closed team then the staff person must makes sure a copy of all material is placed in the appropriate directory on the TPC workspace and use those permalinks provided.

For CCB related items refer to the CCB Sub Process, otherwise the AC Coordinator ensures that the AC Submission form contains all the necessary information, and sends the request along with the review period to the Approvals Committee and other interested parties.

NOTE:  Permalinks can be found under the document posting on the Collaboraration Workspace.  Click the permalink button, to open a window which dispays the URL text. Copy this URL text and include in all notifications.

Owner

Name Description Type
Product manager Manages the development and delivery of products Role
Team Leader Individual responsible for managing the project team Role

Requirements

Name Description Type
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement
TMF413 Approvals Submission form Form to be submitted with any request for approval, charter or deliverable Requirement


6.4   Is deliverable a CCB Baseline Artifact 

If the submitted artifact has been CCB baselined, it is sent to the CCB for approval, not the AC.

Incoming Links

Name Description Link Label
Submit for approval

Outgoing Links

Name Description Decision
Deliverable Member Evaluation & Review Sub Process This sub-process describes the process for reviewing deliverables submitted for approval No
CCB process Change Control Board Process Yes


6.5   Deliverable Member Evaluation & Review Sub Process 

This sub-process describes the process for reviewing deliverables submitted for approval by the Approvals Committee.

Refer to the detailed 'Deliverable Review' Sub Process for complete details.


6.6   AC Approval Decision 

The AC reviews deliverables and considers the comments from the SPLC, TPC and other subject matter experts and either accpets or rejects the submission.

Note:  It is at this point that the CTO would have reflected on any requests to

      1. not put a document forward for Formal TM Forum Approval

      2. To make documents available to the public for purchase or otherwise

and inform the AC co-ordinator of the decision results, who will record it in the Approvals Submission form.

Owner

Name Description Type
Approval Committee The Approval Committee is the operational body that approves technical work projects and the release of technical team deliverables Group

Requirements

Name Description Type
Approved Deliverables Deliverables that have completed the approval process Requirement
Charter Project charter identify the scope and keyt components of the project Requirement
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement

Incoming Links

Name Description Link Label
Deliverable Member Evaluation & Review Sub Process This sub-process describes the process for reviewing deliverables submitted for approval

Outgoing Links

Name Description Decision
Archive Deliverable Rejected or out of date material is archieved on the system. Rejected
Deliverable Posting Approved


6.7   CCB process 

Change Control Board (CCB) will provide a single body for the approval of changes to the existing NGOSS baseline.

The NGOSS Change Control Board will report to the TMF Approvals Board and is chartered with responsibility for ensuring that the change control process as documented, is adhered to by the TMF Collaboration Program.

In addition to the process description outlined here, CCB definition and Terms of Reference are documented in the Word document Tech-07, Change Control Board definitions and terms of reference.

Linked Resources

Name Description Type
Hyperlink


6.8   Deliverable Posting 

Once approved, any comments or actions are sent to the team leader.  Depending on the level of comments the team may be required to update the deliverables to reflect the comments and up-version them in the 'submitted folder' on the CWS and the AC Coordinator is informed of its completion.

The Document Release Manager is then informed by the AC Co-ordinator that the deliverable has been approved with or without comments and ready for final processing.

Note: At this point of the process, a Approvals Submission form may be presented to the Document Release Manager from the CCB along with the updated baselined deliverables for final processing and distribution.(Refer to the Change Control Board Process).

Document Release Manager conducts final processing on the deliverables and posts up-versioned deliverables to the appropriate areas of the web page and CWS. Deliverables are moved from the Submitted Documents folder to the ‘Approved Documents’ folder. This version becomes the baseline for future work.

The Document Release Manager then notifies (via the proper chanels) the principle contacts and all teams when the deliverable(s) has been processed and posted.  A standard email temaplate is completed to provide the appropriate information.

Refer to Document Release Management Process for further details.

Throughout the life of a deliverable comments can be returned via a link on the web page.

Owner

Name Description Type
Product manager Manages the development and delivery of products Role
Team Leader Individual responsible for managing the project team Role

Performed By

Name Description Type
Document Release Manager Responsible for processing and posting documents Role


6.9   Deliverable to continue for TM Forum Approval decision 

It is the intention that all documents (other than the exceptions listed below) are put forward for TM Forum Approval.  

A Team or Product Manager or the AC may request, (via the Approvals Submissin form), that a particular deliverable be not put forward with given reasons. The CTO, determine the outcome of that request and inform the AC-Cordinator/CCB Admin who will update the Approvals form appropriately.

The following document types are not submitted for TM Forum approval:

Charters:

The Charter Documents do not follow the complete lifecycle. Instead the following is conducted:

(A) After successfully completing the AC review and processing by the Document Release Manager, the Charter will be posted as a public, (registered user) available document.

(B) These will display the ‘Notice Statment’ type 1, (Notice 1, reference 14 of the Operating Guide).

(C) Charters tend to have a minimum 6-month life span after which time they are updated.

Catalyst Projects

(A) The Catalyst projects are specific implementations usually demonstrating some aspect of the NGOSS Program, and are demonstrated at a TM Forum Management World Conference. The Project Deliverables tend to be:

a. An Interface Implementation Specification documenting the implementation and results of the project,

b. and may include demo code/model .

(B) After processing, the deliverables can be posted as Member Only status, as deemed appropriate by the CTO.

(C) The IIS tend to have a specified life span of ‘Valid until further notice’ and so remains posted on the web indefinitely.

(D) Note: Catalyst Deliverables are not sent for Member Evaluation or TMF Approval status and comments are not accepted.

Technical Reports

These documents will only ever be posted as Member Evaluated versions and as such will not be put forward for TMF Approval or Member Vote.

Owner

Name Description Type
Product manager Manages the development and delivery of products Role

Incoming Links

Name Description Link Label
Deliverable Posting

Outgoing Links

Name Description Decision
Remain in member evaluated No
Formal 'TM Forum Approval' Sub Process The process which is undertaken to achieve TM Forum Approval status for a deliverable. Yes


6.10   Formal 'TM Forum Approval' Sub Process 

The process which is undertaken to achieve formal TM Forum Approval status for a deliverable.

Refer to the detailed 'Formal TM Forum Approval' sub process for complete details.

Owner

Name Description Type
Product manager Manages the development and delivery of products Role

Requirements

Name Description Type
Approved Deliverables Deliverables that have completed the approval process Requirement

Performed By

Name Description Type
Membership The TM Forum membership Group


6.11   Archive Deliverable 

The AC Coordinator informs the Team Leader and Document Release Manager that the deliverable has been rejected and if material is rejected by an approvals committee - it cannot be posted to the TM Forum web page.

The Document Release Manager archives the deliverable on the CWS or the team may decide to restart the work again.


6.12   TMF413 Approvals Submission form 

Hyperlink

URL / File Path
http://www.tmforum.org/page33676.aspx  

This form is to be used when submitting a project charter or project deliverable for approval by the Approvals Committee (AC) or Change Control Board (CCB) prior to Member Evaluation and/or TMF web posting

Owner

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role


6.13   Team Leader 

Individual responsible for managing the project team


6.14   Membership 

Members of the TM Forum


6.15   Remain in member evaluated 

Normally a deliverable will proceed to full TM Forum approval but under special circumstances, it may remain in the Member Evaluated status until it is time to archieve from the system.

Owner

Name Description Type
Document Release Manager Responsible for processing and posting documents Role


6.16   End Deliverable Approval 



7.0  
Deliverable Member Evaluation & Review Sub Process Process Narrative

Deliverable Member Evaluation & Review Sub Process
Description This sub-process describes the process for reviewing deliverables submitted for approval
Deliverable Member Evaluation & Review Sub Process

This sub-process describes the process for reviewing deliverables submitted for approval by the Approvals Committee.

Refer to the detailed 'Deliverable Review' Sub Process for complete details.


7.1   Start Delierable review 

This outlines the various steps which are undertaken to collect review comments.


7.2   Quality Assurance Check 

Ensure that the correct template is used and version number policy is correctly applied. Check that the deliverables meet the required quality levels prior to posting. If not, the material will be returned to the team via the staff support person for correction.

Owner

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role

Requirements

Name Description Type
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement
TMF413 Approvals Submission form Form to be submitted with any request for approval, charter or deliverable Requirement

Performed By

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role
TMF Staff Support Person Person assigned to assist a particular team Role


7.3   Expert review 

As part of the AC approval phase, Subject matter experts (SMEs) are requested to review the submission and to provide feedback to the AC to assist them with their approval review.  The SMEs may be drawn from any appropriate  area and will normally be identified by the TPC, SPLC or sector interest groups.

The AC Co-odinator will have provided them with the deliverable(s) and the end of comment period.

Owner

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role

Requirements

Name Description Type
Review comments Comments raised by reviewers Requirement
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement

Performed By

Name Description Type
Approval Committee The Approval Committee is the operational body that approves technical work projects and the release of technical team deliverables Group
Product manager Manages the development and delivery of products Role
Sector Heads Sector Czars are specialists in the sector that they represent and drive the participation of companies in their market sector in the TM Forum Role
SPLC Service Provider Leadership Council Group
Subject Matter Expert Individuals with detailed knowledge in a specific domain area Role
Technical Committee Sub-committee of the board that provides the detailed technical strategy and guidance for technical projects Group
TPC Technical Program Council Group


7.4   For Public Review decision 

Deliverables will by default be submitted for member only review.  A team may request that a wider public review take place, via the Approvals form, but  Permission for public review must be obtained from the TM Forum CTO. The AC-cordinator will seek a decision to the request via email.

If the CTO agrees, the deliverable is posted into the public domain, if the request is rejected, the review is restricted to members only.

tThe AC cordinator will update the Approvals Submission form with the outcome of the decision.

Owner

Name Description Type
Chief Technology Officer (CTO) Role

Incoming Links

Name Description Link Label
Quality Assurance Check Check that the deliverables meet the required quality levels prior to posting.

Outgoing Links

Name Description Decision
Post deliverable to the public domain Deliverable is posted such that it is availbale to the public. Public available
Post deliverable to member only domain Deliverable is posted such that it is available to members only Member only


7.5   Post deliverable to the public domain 

Deliverables enter a period of 90 day Public Evaluation. (This evaluation period may be changed by request of the team via the approval form and final decision made by the AC-Coordinator based upon complexity of material and amount of other material currently out for review.)

Deliverables posted to the public may encur a charge for non-members, details of will be posted on the web.  This is determined by the VP for Collaboration Program.

The AC Coordinator informs the Document Release Manager that is deliverable is to go to the public domain, who will organise it with the assistance of the TM Forum IT department.

Note: Once evaluation has completed the document will be removed from the public domain once more.  It will only be returned on the explicit instruction of the CTO.

Owner

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role

Requirements

Name Description Type
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement

Performed By

Name Description Type
Document Release Manager Responsible for processing and posting documents Role


7.6   Public review 

Public reviewers review the deliverable and provide feedback via a comment collection link on the TMF web page.  It is important that on returning comment, the reviewer indicates if there is an IPR issue to be considered. A link to the Patentable Disclosure entry form will be provided on the web page also.

The AC Coordinator will collate all the comments.

Owner

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role

Requirements

Name Description Type
Review comments Comments raised by reviewers Requirement
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement

Performed By

Name Description Type
Public reviewers Public reviewing the deliverables Group


7.7   Post deliverable to member only domain 

The AC Coordinator informs the Document Release Manager that there is material available for processing and posting.

Deliverables enter a default period of 90 day Member Evaluation. This evaluation period may be changed by request of the team via the approval form and final decision made by the AC-Coordinator based upon complexity of material and amount of other material currently out for review.

Depending on the Deliverables, they will normally be posted to the following areas of the TMF Web -

** Appropriate Document Catalog section of the document library

** Team web page

** Member Evaluation area

** Solutions Suites page if appropriate.

Owner

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role

Requirements

Name Description Type
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement

Performed By

Name Description Type
Document Release Manager Responsible for processing and posting documents Role


7.8   Member review 

TM Forum Members review the deliverable and provide feedback via a link from the TM Forum web page. The ability for a member to identify any patent or IPR they have against the material will be available from the web page. The AC Coordinator will access and manage these review comments.

Owner

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role

Requirements

Name Description Type
Review comments Comments raised by reviewers Requirement
Team draft deliverables for approval The team deliverables developed by the team in final draft form ready to be submitted to the AC for approval Requirement

Performed By

Name Description Type
Membership Members of the TM Forum Group


7.9   Capture comments 

The AC Coordinator collates the comments from the various possible reviewer groups and provides the consolidated feedback to the AC to assist them with their approval decision.

It is possible that new requirements are generated from the review period, these are forwarded to Product Management for consideration and entry into the requirements tracking system.

Owner

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role

Requirements

Name Description Type
Review comments Comments raised by reviewers Requirement

Performed By

Name Description Type
AC Coordinator Staff person supporting the Approval Committee and approval process Role


7.10   End AC Approval Process 

Requirements

Name Description Type
Review comments Comments raised by reviewers Requirement




8.0  
Formal 'TM Forum Approval' Sub Process Process Narrative

Formal 'TM Forum Approval' Sub Process
Description The process which is undertaken to achieve TM Forum Approval status for a deliverable.
Formal 'TM Forum Approval' Sub Process

The process which is undertaken to achieve formal TM Forum Approval status for a deliverable.

Refer to the detailed 'Formal TM Forum Approval' sub process for complete details.

Owner

Name Description Type
Product manager Manages the development and delivery of products Role

Requirements

Name Description Type
Approved Deliverables Deliverables that have completed the approval process Requirement

Performed By

Name Description Type
Membership The TM Forum membership Group


8.1   Start TM Forum Approval process 

All documents, with the exception of those listed below should be put forward for TMF Approval vote. Other exceptions should be highlighted by the CTO at the interanl approval process stage

Deliverables which do not undergo the TMF Approval include:

• Catalyst Interface Implementation Specifications: do not undergo evaluation or approval, since they reflect what was demonstrated at a specific time.

• Project Charters: these are project plans and reflect the intentions and timescales of a project team. These undergo evaluation and AC approval only.

• Deliverables (Guide books etc.) which are not recommended for TMF Approval: These will become either a Member or Public version and will reside in the Document Catalog under the Document Library tab of www.tmforum.org

All Deliverables must undergo the Patent Disclosure Process.


8.2   Invite members to vote 

*) The Document Release Manager ensures that the principle contacts and team are informed via email when a particular deliverable is being put forward for Corporate Member Vote/Formal TM Forum Approval. The notification to the principle contacts will use the approriate sections of the template outlined in Reference 15, Document Voting letter of the Operating Guide, (GB919).

*) in addition the principle contacts of all non-corporate members are notified of the upcoming vote, even though they have no voting rights but are invited to submit a patent disclosure form.

*) The voting period is between 45- 60 days

*) The notification will identify the date when the voting period closes.

Owner

Name Description Type
Document Release Manager Responsible for processing and posting documents Role

Requirements

Name Description Type
Member Evaluated Deliverables Requirement
Voting notification forms Requirement

Performed By

Name Description Type
Document Release Manager Responsible for processing and posting documents Role
TM Forum IT support Role


8.3   Gather cast votes 

Once notified the Principle Contacts should:

a. Review deliverable in light of receiving ‘TM Forum Approval’ Status

b. indicate their vote via a web link available in the notification email

c. forward completed Patent Disclosure Form to Member Services in the New Jersey Office by one of the following means:

  i. Fax.

   ii. Scanned imaged emailed directly to Member Services in NJ office

  iii. Scanned image attached to vote on Web page.

Member Services will take these Patent Disclosure forms and file appropriately.

d. if members have additional comments on the material, these can be captured via the 'comment' feature on the web page.

Owner

Name Description Type
Document Release Manager Responsible for processing and posting documents Role

Requirements

Name Description Type
Cast Votes Requirement
Completed Patent Disclosure forms. Requirement

Performed By

Name Description Type
Document Release Manager Responsible for processing and posting documents Role
Member Services Support Role
TM Forum IT support Role


8.4   Process Votes 

a. The votes are stored in a database and vote status automatically determined. At the end of the voting period the results are forwarded to the Document Release Manager.

b. The Patent Disclosure forms are stored on the system and also manually filed in the New Jersey office in the appropriate areas.

c. A reminder is automatically sent to the Principle Contacts 10 days before the end of the voting period.

d. A document is considered a Forum Approved document by a simple majority vote at the end of the voting period, once a quorum of 15 Corporate Members have cast their vote.

Note: “Abstain” is considered an exercise of voting privilege and counted as a cast vote.

e. Any additional comments are retrived and sent directly to the Team Leader and Staff support person.

Owner

Name Description Type
Document Release Manager Responsible for processing and posting documents Role

Requirements

Name Description Type
Cast Vote Totals Requirement
Cast Votes Requirement

Performed By

Name Description Type
Document Release Manager Responsible for processing and posting documents Role
TM Forum IT support Role


8.5   Result of Vote 

Once the closing date for the voting period has passed, the voting totals are automatically generated and forwarded to the Document Release Manager.

If a simple majority (more than one half of those voting, where at least 15 of the Corporate Members vote) vote in favor of approval, then such document shall become a “TM Forum Approved Document”.

The Document Release Manager will issue the results of the vote to all concerned parties.

Owner

Name Description Type
Document Release Manager Responsible for processing and posting documents Role

Requirements

Name Description Type
Cast Vote Totals Requirement

Incoming Links

Name Description Link Label
Process Votes Voting totals

Outgoing Links

Name Description Decision
Process deliverable to TM Forum Approved status upgrade the document status and process. Approved
Process Unapproved Document Not Approved


8.6   Process deliverable to TM Forum Approved status 

once approved the document is process as follows:

** determine if comments received, then Project Team may incorporates them in this release or agree to carry forward to next release. If changes are made, then updated document is returned to the submitted document folder and Document Release Manager is notified.

** the Document Release Manager updates the deliverable to reflect ‘Notice’ type 2, Forum Approved Document, (reference 14 of the Operating Guide).

** If patent interests are noted,(refer to Process TECH-01 TM Forum Patent Disclosure Policy and Operating Guide) a sentence is added to the document Notice Statement to indicate that patent interests have been identified.

** The Document Release Manager finalizes the processing of the deliverables and update itsTM Forum web posting and baseline in the approved documents folder on the CWS.

** The Marketing Department announces the approved deliverable as appropriate.

Owner

Name Description Type
Document Release Manager Responsible for processing and posting documents Role

Requirements

Name Description Type
Approved Deliverables Deliverables that have completed the approval process Requirement
Review comments Requirement

Performed By

Name Description Type
Document Release Manager Responsible for processing and posting documents Role
Product manager Manages the development and delivery of products Role
Team Leader Individual responsible for managing the project team Role


8.7   Process Unapproved Document 

If the document does not receive TMF Approval, the CTO can decide to continue the deliverable in Member or Public available with a status of 'Member Evaluated', or retire it, whereby it is removed from the web and archived.

Owner

Name Description Type
Document Release Manager Responsible for processing and posting documents Role

Performed By

Name Description Type
Chief Technical Officer The TM Forum CTO Role
Document Release Manager Responsible for processing and posting documents Role


8.8   End TM Forum Approval Process 



9.0  
CCB process Process Narrative

CCB process
Description Change Control Board Process
CCB process

Change Control Board (CCB) will provide a single body for the approval of changes to the existing NGOSS baseline.

The NGOSS Change Control Board will report to the TMF Approvals Board and is chartered with responsibility for ensuring that the change control process as documented, is adhered to by the TMF Collaboration Program.

In addition to the process description outlined here, CCB definition and Terms of Reference are documented in the Word document Tech-07, Change Control Board definitions and terms of reference.

Linked Resources

Name Description Type
Hyperlink


9.1   Start CCB process 

The Change Control process is managed by the Change Control Board (CCB), which is comprised of a committee of a maximum of 10 people who play one or more roles during the life of a Change Request (CR).

The Change Control Process manages all changes to the Artifacts making up the NGOSS Baseline, for example a TM Forum document or SID ABE. New Artifacts created as part of a NGOSS team project charter must be added to the NGOSS Baseline on their release to the Approvals Committee and from then on will go under the umbrella of the CCB.

There are a number of different types of requests which can be made

1. A formal submission of a problem; for example an error in the documentation, requesting that it be corrected. (CR Form used)

2. A request to make changes submitted as a marked solution; for example a new NGOSS Artifact or revision to an existing NGOSS Artifact to be included in the NGOSS Baseline. (CR Form Used)

3. A request that an NGOSS Artifact Version (an update to the current approved version), submitted by a NGOSS team be made the Base Artifact. (New documents being added to the Baseline are covered by a separate process; where they are reviewed by the Technical Program Council and approved the Approvals Committee of the Board and Member vote. (BA Submission Form Used)

4. A request to the teams to investigate and address an area - no marked solution provided. (CR Form Used)

It should be noted that at any stage in the process a request can be withdrawn, by either the requestor or the CCB if it is superceed by another request etc.  In such cases the CCB Admin will update the request to have a status of 'Closed - Withdrawn' and archieve on the system.


9.2   Receipt of Request Sub Process 

The CCB process starts with the receipt of a request by the CCB. Registration and Initial assessment of the CR decides on the appropriate process for the request.

Refer to the Receipt of CR Submission Sub process for complete details.

Owner

Name Description Type
CCB Admin Role

Requirements

Name Description Type
New Request for CCB Requirement
Request or Approvals Submission Form Requirement


9.3   Determine if CR or Approvals Submission ( Base Artifact ) 

There are a number of different types of requests which can be made

1. A formal submission of a problem; for example an error in the documentation, requesting that it be corrected. (CR Form used)

2. A request to make changes submitted as a marked solution; for example a new NGOSS Artifact or revision to an existing NGOSS Artifact to be included in the NGOSS Baseline. (CR Form Used)

3. A request that an NGOSS Artifact Version (an update to the current approved version), submitted by a NGOSS team be made the Base Artifact. (New documents being added to the Baseline are covered by a separate process; where they are reviewed by the Technical Program Council and approved the Approvals Committee of the Board and Member vote. (BA Submission Form Used)

4. A request to the teams to investigate and address an area - no marked solution provided. (CR Form Used)

Depending on which type (form) has been use the request will flow to the appropriate sub-process.

Incoming Links

Name Description Link Label
Receipt of Request Sub Process New Request

Outgoing Links

Name Description Decision
Base Artifact Request Sub Process Base Artificat Submission
Pre-access CR Investigate the nature of the change request Change Request


9.4   Pre-access CR 

The CCB will review the Change Requests to determine if it is a candaite for the 'Fast-Track' Sub process or if detailed investigation is required and the Normal CR Process must be followed.

Formal Team submissions and marked solutions can go through the normal process or be fast-tracked at the discretion of the CCB.

Owner

Name Description Type
CCB Chairperson Role

Performed By

Name Description Type
CCB Change Control Board Group


9.5   Determine type of CR being requested 

Is CR a candiate for Fast Track or Normal CR Processing.

Owner

Name Description Type
CCB Change Control Board Group

Incoming Links

Name Description Link Label
Pre-access CR Investigate the nature of the change request Change Request

Outgoing Links

Name Description Decision
Normal CR Sub process Change Request
Fast-Track CR Sub Process A shorter process for CR's to follow. Team Submission CR


9.6   Normal CR Sub process 

The process steps which the majority of Change Requests will follow.

Refer to the 'Normal CR' Sub process for complete details.

Owner

Name Description Type
CCB Chairperson Role


9.7   Fast-Track CR Sub Process 

To avoid spending a large amount of effort on many small changes, the CCB, at its discretion, may vote to use a fast-track option for small changes & corrections that have no expected wider impact, or Team Submissions.

Refer to the 'Fast Track' Sub Process for complete details.

Owner

Name Description Type
CCB Chairperson Role


9.8   Base Artifact Request Sub Process 

An NGOSS team, with a current approved charter, can submit NGOSS Base Artifacts (NGOSS documents or models) to the CCB for approval.

Refer to the detailed 'Base Artifact Request' Sub process for more details.

Owner

Name Description Type
CCB Chairperson Role


9.9   End CCB Process 



10.0  
Receipt of Request Sub Process Process Narrative

Receipt of Request Sub Process
Receipt of Request Sub Process

The CCB process starts with the receipt of a request by the CCB. Registration and Initial assessment of the CR decides on the appropriate process for the request.

Refer to the Receipt of CR Submission Sub process for complete details.

Owner

Name Description Type
CCB Admin Role

Requirements

Name Description Type
New Request for CCB Requirement
Request or Approvals Submission Form Requirement


10.1   Start Receipt of Request sub process 

(TMF416)Request or (TMF413) Approvals Submission form is completed by the Requestor plus appropriate attachments and submitted (through emailed) to CCB Admin via the following email address: ccb@tmforum.org for processing.

Any Member of the TM Forum can submit a Request to the CCB.

In the event that the request is coming from a member of the CCB or other party who has access to the CCB tracking system, (gForge and/or CCB Collaboration Workspace), may enter the request directly into the sytem and inform via email both the CCB Admin and CCB once the Request has been entered.


10.2   Validate Request 

CCB Admin assesses the request to ensure it is valid, i.e. the correct form has been used and it follows rules set down to ensure that all required information is included.

There are four types of requests that can be made to the CCB;

1. A formal submission of a problem; for example an error in the documentation, requesting that it be corrected.

2. A request to make changes submitted as a marked solution; for example a new NGOSS Artifact or revision to an existing NGOSS Artifact to be included in the NGOSS Baseline.

3. A request that an NGOSS Artifact Version (an update to the current approved version), submitted by a NGOSS team be made the Base Artifact. (New documents being added to the Baseline are covered by a separate process; where they are reviewed by the Technical Program Council and approved the Approvals Committee of the Board and Member vote.

4. A request to address a problem with no marked solution.

Formal submissions and marked solutions can go through the normal process or be fast-tracked at the discretion of the CCB.

Owner

Name Description Type
CCB Admin Role

Performed By

Name Description Type
CCB Admin Role


10.3   A valid Request 

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 CCB

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

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

Owner

Name Description Type
CCB Admin Role

Requirements

Name Description Type
New Request for CCB Requirement

Incoming Links

Name Description Link Label
Validate Request New Request

Outgoing Links

Name Description Decision
Register Request Yes
Reject Request No


10.4   Register Request 

Once validated the request is entered into the tracking tool, currently gForge, where the tool automatically assigned it a unique tracking number. The CR will be assigned a status of 'New'

All associated documents/materials are attached to the tracking instance, to ensure a complete story is available in one place.

The request is then included in the next periodic notification to the CCB

Owner

Name Description Type
CCB Admin Role

Requirements

Name Description Type
New Request for CCB Requirement

Performed By

Name Description Type
CCB Admin Role


10.5   Reject Request 

The request may be rejected and communicated with reasons to the Requestor

Or it may be entered into the system and put in the ‘Registered’ state with a request for further information sent to the Requestor


10.6   Pre Assess Request 

The CCB will discuss the request at it's next meeting focusing on:

a. Completeness

b. Duplication

c. Conflicts to other requests

d. Conformance with product scope, standards, etc.

If the request passes the above review a CR Manager is assigned to Manage the request through the remainder of the it's life within the CCB process.

The CCB Admin, will update the request entry in the tracking tool to have a status of 'assigned'  and note the name of the CR Manager and any other key items of discussion.

Owner

Name Description Type
CCB Admin Role

Requirements

Name Description Type
New Request for CCB Requirement

Performed By

Name Description Type
CCB Admin Role
Change Control Board Group


10.7   End Receipt of Request Sub process 



11.0  
Base Artifact Request Sub Process Process Narrative

Base Artifact Request Sub Process
Base Artifact Request Sub Process

An NGOSS team, with a current approved charter, can submit NGOSS Base Artifacts (NGOSS documents or models) to the CCB for approval.

Refer to the detailed 'Base Artifact Request' Sub process for more details.

Owner

Name Description Type
CCB Chairperson Role


11.1   Start Base Artifact Request Sub process 

If the CCB decides that the submission can be processed as an ‘Base Artifact Request’, the CCB then makes one of the following decisions:

a. Reject the request

b. Refer back to the author for more information, clarification or modification to the Base Artifact Submission form

c. Assess and Approve the request


11.2   Decide on Course of action for Approvals Submission. 

Voting is conducted as follows.

The vote must be passed by a simple majority of a voting quorum of the CCB, without any votes against (abstentions are allowed). The CCB may, at its discretion, may vote on the change without needing a Domain Expert.

Incoming Links

Name Description Link Label
Start Base Artifact Request Sub process

Outgoing Links

Name Description Decision
Assess Approvals Submission Review the implemented material to ensure all is OK Approvals Submission
Reject Decision CCB have reviewed the CR and agreed to reject it. Approvals Submission
Defer Decision Unable to make a decision at this point due to various reasons. Approvals Submission


11.3   Defer Decision 

In this case, the CCB requires further information from either the requestor or the assessors or an other party. In this event the request may remain in a dormant state until such time as the information is available.

The assigned CR Manager is responsible to ensure the information is received and keeps the CCB updated on progress.

Owner

Name Description Type
CR Manager Role


11.4   Reject Decision 

The CR can be rejected for many reasons.  Examples of which include: IPR issues, Goes against the TM Forum Strategey, Does not belong in the CCB area and should be addressed else where (TPC, etc.) etc.

The CR Manager will inform the Requestor of the CCB decision, stating reasons. The CCB Admin will update the status of the CR 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 CCB, an escalation process is available to them.

Owner

Name Description Type
CCB Chairperson Role

Performed By

Name Description Type
CCB Change Control Board Group


11.5   Esculation Option 

In the event that a requestor of a CR is not satisfied with the decisions made by the CCB, an escalation process is available to them, .by submitting their request and reasons for their dissatisfaction to the Approvals Committee, no later than 1 week after notification of the decision. The Approvals Board will review the request in light of all the facts and make its decision.

(Note: It is possible that the further information may be required from the requestor, so the submission could iterate around this phase).

Owner

Name Description Type
CR Manager Role

Performed By

Name Description Type
Approval Committee The Approval Committee is the operational body that approves technical work projects and the release of technical team deliverables Group
CCB Admin Role
CR Manager Role
Requestor Role


11.6   Assess Approvals Submission 

The CCB will review theApprovals Submission form to identify the CR's which are being put forward for closure.  The Base Artificat documents/models (links provided with the BA Submission form) are reviewed to ensure implementation is conducted correctly and that no unexpected impacts have been introduced.

An known error/ impact section should be included in each Base Artifact outlining any known issues. This will also be taken into account in the final CCB decision.

The CR Manager and/or member of the implementing team(s) may be requested to join a CCB meeting to discuss the implementation and provide further information.

Once the CCB feel that they are happy to make a decision the CCB Chairperson will call for a vote on the request.


11.7   Vote on Approvals Submission 

Incoming Links

Name Description Link Label
Assess Approvals Submission Review the implemented material to ensure all is OK

Outgoing Links

Name Description Decision
Close CR and Approvals Submission CRs are closed out of the system. Approve
Reject Decision CCB have reviewed the CR and agreed to reject it. Reject


11.8   Close CR and Approvals Submission 

The CCB Admin updates the submission status in the tracking system.

The status of all CRs identified as included in the new Base Artifact (i.e. those listed on the ‘Base Artifact Request’) have their status changed to ‘Closed - Implemented’ and are then archived.


11.9   End Base Artifact Request Sub Process 



12.0  
Fast-Track CR Sub Process Process Narrative

Fast-Track CR Sub Process
Description A shorter process for CR's to follow.
Fast-Track CR Sub Process

To avoid spending a large amount of effort on many small changes, the CCB, at its discretion, may vote to use a fast-track option for small changes & corrections that have no expected wider impact, or Team Submissions.

Refer to the 'Fast Track' Sub Process for complete details.

Owner

Name Description Type
CCB Chairperson Role


12.1   Start Fast Track Sub Process 

If the CCB decides that the CR can be ‘fast tracked’, the CCB then makes one of the following decisions:

a. Reject the CR

b. Referred back to the Team for more information, clarification or modification to the CR

c. Approve the CR


12.2   Determine course of action for CR 

Voting is conducted as follows.

The vote must be passed by a simple majority of a voting quorum of the CCB, without any votes against (abstentions are allowed). The CCB can vote on the Change Request without needing a Domain Expert.

The CCB Admin updates the CR status in the tracking system.

Owner

Name Description Type
CCB Chairperson Role

Incoming Links

Name Description Link Label
Start Fast Track Sub Process Change Request

Outgoing Links

Name Description Decision
Reject Decision CCB have reviewed the CR and agreed to reject it. Change Request
Defer Decision Unable to make a decision at this point due to various reasons. Change Request
CR Implementation Change Request


12.3   Defer Decision 

In this case, the CCB requires further information from either the requestor or the assessors or an other party. In this event the request may remain in a dormant state until such time as the information is available.

The assigned CR Manager is responsible to ensure the information is received and keeps the CCB updated on progress.

Owner

Name Description Type
CR Manager Role


12.4   Reject Decision 

The CR can be rejected for many reasons.  Examples of which include: IPR issues, Goes against the TM Forum Strategey, Does not belong in the CCB area and should be addressed else where (TPC, etc.) etc.

The CR Manager will inform the Requestor of the CCB decision, stating reasons. The CCB Admin will update the status of the CR 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 CCB, an escalation process is available to them.

Owner

Name Description Type
CCB Chairperson Role

Performed By

Name Description Type
CCB Change Control Board Group


12.5   Esculation Option 

In the event that a requestor of a CR is not satisfied with the decisions made by the CCB, an escalation process is available to them, .by submitting their request and reasons for their dissatisfaction to the Approvals Committee, no later than 1 week after notification of the decision. The Approvals Board will review the request in light of all the facts and make its decision.

(Note: It is possible that the further information may be required from the requestor, so the submission could iterate around this phase).

Owner

Name Description Type
CR Manager Role

Performed By

Name Description Type
Approval Committee The Approval Committee is the operational body that approves technical work projects and the release of technical team deliverables Group
CCB Admin Role
CR Manager Role
Requestor Role


12.6   CR Implementation 

1. The CR Manager takes the CR and manages the requested change with the appropriate Project Teams, using the appropriate tools.

2. Once the change is verified by the implementing team, it will return to the CCB included in an Approvals Submission form, for validation that it has been implemented correctly and no unexpected impacts introduced. Refer to the ‘Base Artifact Request’ sub process for more details.

Owner

Name Description Type
CR Manager Role

Performed By

Name Description Type
CR Manager Role
Project Team Group


12.7   Base Artifact Request Sub Process 

An NGOSS team, with a current approved charter, can submit NGOSS Base Artifacts (NGOSS documents or models) to the CCB for approval.

Refer to the detailed 'Base Artifact Request' Sub process for more details.

Owner

Name Description Type
CCB Chairperson Role


12.8   Normal CR Sub process 

The process steps which the majority of Change Requests will follow.

Refer to the 'Normal CR' Sub process for complete details.

Owner

Name Description Type
CCB Chairperson Role


12.9   End of Fast Track Sub Process 



13.0  
Normal CR Sub process Process Narrative

Normal CR Sub process
Normal CR Sub process

The process steps which the majority of Change Requests will follow.

Refer to the 'Normal CR' Sub process for complete details.

Owner

Name Description Type
CCB Chairperson Role


13.1   Start Normal CR Sub-Process 

If the CCB decides that the CR should follow the ‘Normal CR’ process, then it will make one of the following decisions.

a. Confirm assignment of the CR Manager and set an Assessment Due date by which the results of the investigation should be returned and a vote called for.

b. Reject the CR with reasons which the CR Manager should communicate to the Requestor, (copying the CCB)

c. or the CR may be left in the Registered state, and a request for further information will be communicated to the Requestor

The CCB Admin updates the CR status in the tracking system and notes any key decisions made.

Owner

Name Description Type
CCB Chairperson Role


13.2   Determine course of action for CR 

Owner

Name Description Type
CCB Chairperson Role

Incoming Links

Name Description Link Label
Start Normal CR Sub-Process Change Request

Outgoing Links

Name Description Decision
Reject Decision CCB have reviewed the CR and agreed to reject it. Change Request
Assess CR Chagne Request
Defer Decision Unable to make a decision at this point due to various reasons. Change Request


13.3   Defer Decision 

In this case, the CCB requires further information from either the requestor or the assessors or an other party. In this event the request may remain in a dormant state until such time as the information is available.

The assigned CR Manager is responsible to ensure the information is received and keeps the CCB updated on progress.

Owner

Name Description Type
CR Manager Role


13.4   Reject Decision 

The CR can be rejected for many reasons.  Examples of which include: IPR issues, Goes against the TM Forum Strategey, Does not belong in the CCB area and should be addressed else where (TPC, etc.) etc.

The CR Manager will inform the Requestor of the CCB decision, stating reasons. The CCB Admin will update the status of the CR 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 CCB, an escalation process is available to them.

Owner

Name Description Type
CCB Chairperson Role

Performed By

Name Description Type
CCB Change Control Board Group


13.5   Esculation Option 

In the event that a requestor of a CR is not satisfied with the decisions made by the CCB, an escalation process is available to them, .by submitting their request and reasons for their dissatisfaction to the Approvals Committee, no later than 1 week after notification of the decision. The Approvals Board will review the request in light of all the facts and make its decision.

(Note: It is possible that the further information may be required from the requestor, so the submission could iterate around this phase).

Owner

Name Description Type
CR Manager Role

Performed By

Name Description Type
Approval Committee The Approval Committee is the operational body that approves technical work projects and the release of technical team deliverables Group
CCB Admin Role
CR Manager Role
Requestor Role


13.6   Assess CR 

1. The CR Manager reviews the CR(s) and assesses them in detail, with the help of Domain Experts as appropriate. 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 under the CR within the tracking tool (gForge). The CR Manager notifies the CCB Admin that the CR can be included for review and Vote in the next meeting.

2. 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 must be included in the assessment of the CR and should provide their recommendation on whether it should or how the CR could be implemented, indicating a timeframe.

3. The CCB Admin updates the CR status in the tracking system and ensures it is on the agenda for the next CCB meeting.

(Note: It is possible that the further information may be required from the Requestor, so the CR could iterate around this phase)

Owner

Name Description Type
CR Manager Role

Performed By

Name Description Type
CCB Admin Role
CR Manager Role
Domain Expert Role


13.7   Formal Vote on CR 

1. During the CCB meeting the CR reports are discussed to ensure all attendees understand the impacts.

2. The CCB then makes one of the following decisions:

a. Reject the CR

b. Approve the CR,

c. Leave the CR with an Assigned status

Voting is conducted as outlined in the CCB Process document Tech-07 Change Control Board definitions and terms of reference. document.

3. The CCB Admin updates the CR status in the tracking system.

Owner

Name Description Type
CCB Chairperson Role

Incoming Links

Name Description Link Label
Assess CR CR Assessment Report

Outgoing Links

Name Description Decision
Reject Decision CCB have reviewed the CR and agreed to reject it. reject
CR Implementation Approved
Defer Decision Unable to make a decision at this point due to various reasons. More Information


13.8   CR Implementation 

1. The CR Manager takes the CR and manages the requested change with the appropriate Project Teams, using the appropriate tools.

2. Once the change is verified by the implementing team, it will return to the CCB included in an Approvals Submission form, for validation that it has been implemented correctly and no unexpected impacts introduced. Refer to the ‘Base Artifact Request’ sub process for more details.

Owner

Name Description Type
CR Manager Role

Performed By

Name Description Type
CR Manager Role
Project Team Group


13.9   Base Artifact Request Sub Process 

An NGOSS team, with a current approved charter, can submit NGOSS Base Artifacts (NGOSS documents or models) to the CCB for approval.

Refer to the detailed 'Base Artifact Request' Sub process for more details.

Owner

Name Description Type
CCB Chairperson Role


13.10   End Normal CR sub process