3GPP
agreement
| Membership
| Organizational Partners
| Market Representation Partners
| Observers
Project
Coordination Group |
Technical Specification
Groups | Funding &
Finance Committee | Mobile Competence Centre
|
3GPP Working Procedures | Work Plan
| External liaisons |
Delegates corner
| OMA
dependencies
The Work Plan is a living document, aiming at providing co-operations between all the 3GPP TSGs and WGs to help them reaching common targets.
These targets are called “Features”, and are new or substantially enhanced functionality which represents added value to the existing system. A feature should normally embody an improved service to the customer and / or increased revenue generation potential to the supplier. The features are divided into “Building Blocks”, a BB being a set of technical functionality which would generally be expected to reside in a single system element, i.e. a single physical or logical entity or a single protocol. The Building Blocks are divided into “Work Tasks”, a WT being by definition handled by a single Working Group. The output of a work task is the creation of one or more new Technical Specifications (or Reports) and / or Change Requests to existing TSs / TRs. (These definitions are extracted from SP-000109 and were later embodied in 3GPP TR 21.900.)
This tree structure is established to ease the monitoring of the 3GPP work progress, and to make explicit the scope of the work assigned to each Working Group.
A Work item is a generic term to refer to a feature, building block or work task, i.e. all the lines of the Work Plan are work items. A full description of the a work item can be found in the 3GPP Working Procedures.
The Work Plan is provided in the form of a Gantt chart: the left part contains the names and attributes of the Work Items, the right part contains a calendar view reflecting the work progress (blue and grey lines apply to foreseen tasks, black lines for completed tasks). The indentation of WI names reflects the hierarchical level in the tree structure (Features, Building Blocks, and Work Tasks). The Work Plan is maintained in Microsoft Project™. For a wider audience, an image is also available in HTML.
From the Work Plan perspective, a WI is fully characterized by the following set of attributes:
Although the "Unique_ID" numeric value is essential for managing the work plan and the Specs, a pure number is not very memorable for humans. Therefore each WI has a textual code or acronym chosen either by the WI proponents or by the Support Team. It is this code which must be used on Change Request cover sheets, and anywhere else where a human-oriented brief identification of a Work Item is required.
All top-level WIs need to be assigned such a code; it will be convenient for most building block level WIs also to have a unique code; it may sometimes be useful for lower level WIs also to have their own codes: it depends on the granularity with which a Change Request (etc) needs to be associated with a particular WI. Often, a CR need only be associated with a building block or even with a feature, so subordinate WIs do not need their own codes.
Guidelines for the allocation of codes to Work Items:
The code should be an abbreviation of the full title of the work item, insofar as that is possible in a reasonable number of characters.
The code should not contain punctuation (except for decimal separators where necessary) other than hyphens to separate its fields (see below)..
The code should be separated into three fields:
with the fields separated by hyphens. Thus a Feature will have only one field; a Building Block will have a code composed of the code of its parent Feature followed by a hyphen followed by a field unique to that Building Block; a Work Task will have a code composed of the code of its parent Building Block (two fields) followed by a hyphen followed by a field unique to that Work Task.
Thus the hierarchical level of a WI can be determined by looking at its code: Features and Study Items have single text strings with no hyphens. Building Blocks have codes separated into two fields with a hyphen; and Work Tasks have codes separated into three fields with two hypens.
For ease of manipulation, it is recommended that WI codes be limited to no more than seven characters per field, though it is recognized that there will be cases where a longer string is desirable.
Last update
2007-01-05: link to new, simplified Work Plan view added; redundant text
removed
2006-10-16: explanatory text on code/acronym structure added
2006-04-05: update Technical Specification Groups Chart
2005-04-12: general tidy up
2004-01-07: link to Gantt chart from near top of this page made less obscure in
its wording
2003-11-25: link to OMA dependencies page added in header
2003-03-28: link to Work Item Description page added:
2002-01-22