6.0.2 How to manage a project?

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.

Study Item: An initial study, resulting in a Technical Report, which typically performs a feasibility study for additional functionality. If the results of the study are positive, one or more subsequent Feature-type Work Items may follow.

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.

Feature: New, or substantially enhanced functionality which represents added value 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.

Building block:A sub-division of a feature, representing a coherent set of technical functionality which would generally be expected to reside in a single system element.

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

Work task:A sub-division of a building block, representing a self-contained, well-scoped and well-scheduled item of work.

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.

Work Item:A generic term used to encompass study item, feature, building block and work task.

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.