In any complex engineering venture, it is necessary to plan the project, to monitor its progress, and to be able to determine whether it is being completed on schedule and within budget. In many ways, the concepts and constraints which apply to an engineering project can also be applied to system standardization activity.

Any project needs to have its goals defined. It is then possible to analyse the steps needed to achieve each goal, starting from the status quo. It will often be desirable to first produce a feasibility report, which is to be undertaken in the context of a Study Item. A feasibility study may include commercial as well as technical considerations. This analysis will naturally lead to defining the new features which it is wished to add to the existing system. A feature should be more or less self-contained - that is, each feature can be viewed as an optional extra, which can be added or not as a function of market demand. Network operators and equipment manufacturers can decide using commercial considerations whether or not to implement a feature. The description of a feature need not be technically precise, but should represent a concept which can be understood at a service level. It should answer the question: what do I get for my money?

A feature should normally embody an improved service to the customer and / or increased revenue generation potential to the supplier. This being the case, most features would be the responsibility of TSG-SA WG1. The ensemble of the features of a particular release of the system represents the difference between that release and the previous release. A feature can be considered as a high-level goal for project management purposes. But most features will be quite complex, and will need to be broken down into simpler elements or building blocks for the purpose of specifying precise functionality. Work on a study item or feature may be carried out by multiple working groups spanning one or more TSGs. In the case of multi-TSG study items and features, all such TSGs should be shown in the work plan as being responsible for the study item or feature; this should be refined as soon as possible into an identification of the individual working groups responsible. To allow work to progress, the Work Item Descriptions (see clause 6.1) may be approved by one TSG before formal contribution has been received by other involved TSGs and WGs, which should review the Work Item Description in a timely manner, and provide their own input as soon as possible. A building block shall be defined in technical terms, and its description will require an understanding of the architecture of the overall system. A building block should generally be restricted to a single physical or logical entity or a single protocol such as "terminal" or "call control". This implies a generic or object-oriented approach. A building block should normally be the responsibility of a single TSG. In the case of very simple features, a single building block may suffice, in which case the feature and its building block are synonymous. To implement a building block it will generally be necessary further to subdivide the functionality into smaller tasks, each representing a closely specified and easily comprehended activity. Such work tasks may not only be divided by technical content, but potentially by phase. So, for example, it is necessary to define service aspects fully (one or more work tasks) before considering functional information flows (one or more work tasks) which in turn will be followed by detailed protocol specification (one or more work tasks). It is at this lowest hierarchical level of breakdown that estimations of work content and thus time scales can be calculated. From the estimated schedules of all work tasks which comprise a building block, and from their inter-dependences, can be derived the overall schedule for the "parent" building block. From the schedules of all component building blocks, the time-to-completion of the parent feature can be estimated. A work task will almost certainly be the responsibility of a single Working Group. The output of a work task shall be:

• One or more new Technical Specifications (or Reports); and / or
• Change Requests to existing TSs / TRs.

Features, building blocks and work tasks are the three specific types of "Work Item". In the case of very simple building blocks, a single work task may suffice, in which case the building block and its work task are synonymous. All Work Items, whatever their class (feature, building block or work task) require:

• A precise definition of content ("scope");
• An estimated schedule, with milestones to track progress if possible; (in the case of building blocks and features, the schedule can be derived from those of the component work tasks);
• A named person to act as rapporteur (in effect, the manager of the Work Item);
• At least four Member Organizations supporting the Work Item and willing to offer active participation in its realization.

The possible modifications of the specifications are basically of different natures:

• Error corrections: modifications which correct overlooked errors or inconsistencies in the specifications.
• Enhancements: modifications that enhance the system, e.g. by new services or features, or by improving performance or decreasing costs.

Modifications of the correction category (i.e. Category F) are ongoing maintenance tasks and are handled with CRs bearing the code of the Work Item that was used to introduce the affected feature, for the original Release in which it was introduced. Corresponding mirror CRs (i.e. Category A) may be produced for subsequent releases as applicable, using the same Work Item code. See also clause 6.2 covering the case where such a CR is not introduced into the TS or TR at the Release with which that Work Item is associated. Modifications of the enhancement category (i.e. Category B or C) are handled within the concept of Work Items or as "technical enhancements". (See clause 6.2.) Note that prior approval of the WID by the TSG is needed before any substantial work is launched. If that work can be completed within one TSG cycle, the new WID may be approved at the same TSG meeting at which the enhancement CRs are presented. See clause 6.1 for the creation of Work Items.

An early task when elaborating a Work Item is to identify the tasks related to the WI and to allocate them to the TSGs and TSG Sub-Groups. In most cases the tasks from a WI can be split immediately into the following areas:

• Service requirements
• System/Architectural requirements and implications
• Protocol specifications

Service requirements: The responsibility of the service requirements can usually be allocated immediately at the creation/adoption of the WI. Occasionally another Group may be given responsibility for the service requirements. In any case, however, it should be a single group and one that reports directly to the TSG. System/Architectural requirements and implications: Protocol specifications:

Every Work Item shall have a rapporteur. The rapporteur should be selected from regular attendees of the primary responsible Group and shall be selected from supporting companies. The role of the rapporteur is to:

• Monitor the progress of the work in all WGs for the WI.
• Report to the responsible WG and produce a report to the WG plenary on progress.
• Provide feedback to allow the work plan to be updated.
• Keep the WI sheet up-to-date.
• Identify the completion of the WI.

Planning: Categorization: Unless the above aspects are sorted out at the beginning of (or prior to) the work, the risk of getting inefficient and non-optimal specifications increases and the control of the work becomes difficult and unmanageable.

The SI will be realized as a new Technical Report ("feasibility study report"). The WI will be realized as new specifications and/or amendments to existing specifications; the exact structure lies with the individual TSG Sub-Groups and the TSG. Typically, a new feature may result in at least three completely new specifications (stages 1, 2 and 3) but may also cause amendments to the major protocol specifications.

The responsible TSG may decide that a particular Work Item is a candidate for "early implementation". If a feature is a candidate for early implementation this shall be indicated in the 3GPP work plan. Where a feature is a candidate for early implementation the deliverables shall include an early implementation Technical Report. The Technical Report shall give guidance on how to perform early implementation of a Work Item. This report shall not define any new technical requirements. It is there to help implementers identify which parts of the specifications are relevant to the Work Item and how they should be handled when early implementation is performed. The early implementation Technical Report shall be identified in the list of impacted documents in the WID. The early implementation Technical Report is part of the same release as the feature to which is relates. Where a single early implementation feature consists of several Work Items then the number of different TRs should be minimised. The aim shall be for a single report to be written for the appropriate highest level Work Item (typically the feature level). However, flexibility should be left to take account of different ways Work Items may be structured Work on the early implementation Technical Report shall begin with the identification of the requirements for early implementation. The contents of the early implementation Technical Report shall be developed in parallel to the overall progress on standardisation of the Work Item. The responsible Working Groups shall keep the report up to date - particularly the clauses "specification impacts" and "Early Implementation Status" which must be completed before finalisation of the WI and maintained if they are subsequently impacted by any essential corrections.

If a Feature cannot be completed by the freeze date for a Release, two options are available:

1. If the functionality covered by the late-running work item is considered by the TSG not to be vital to the overall Feature, it may be abandoned, or form part of a later Release. It may be necessary to raise CRs to remove modifications from specifications which have already been implemented, so as not to leave unworking stubs of functionality and to ensure that stages 1, 2 and 3 are harmonized.
2. If the foreseen likely overrun is thought to be only a matter of a few months - generally no more than two TSG plenary meeting cycles - the responsible WG may raise an "exception sheet" to request a delay in completion until the next or next-but-one TSG meeting. In this case, the responsible WG undertakes to give high priority to completing the work within that time frame, while recognizing that progress can only be made on the basis of contributions to the work.

In the first case, where the delayed work is moved to a later Release, the responsible WG shall make appropriate changes to the 3GPP work plan. In the second case, the exception sheet should contain enough information to enable the TSG to make a reasoned assessment of the case, and to accept or reject the proposal.