project management glossary

Acceptance Criteria.
Acceptance criteria, or quality criteria, are those characteristics of a product against which it can be objectively measured in order to determine whether it meets the
specified requirements. These criteria therefore define 'quality' in the context of that product and are specified in the appropriate product description.
ACWP.

ACWP - Actual Cost for Work Performed
This is the actual cost of the work done, which may vary from that budgeted. You do not need to know how much has actually been spent - just the amount of work done multiplied by the associated unit costs.

Approval to Proceed.
This formal approval is given by the project owner at project initiation and at each main project review, prior to commencement of the work involved in the next phase. It represents a commitment to further expenditure up to the end of the next phase of the project.

Arrow Diagram.
There are two basic networking techniques called :
1. Arrow diagram method (ADM) - also called network-on-arrow.
2. Precedence diagram method (PDM) - which uses activity network diagrams.
The arrow diagram approach depicts activity information on the arrow or relational link. The preceding and succeeding activities are more clearly highlighted and this can be useful when dealing with a large network. However this method has been largely superceded by the PDM approach which has been incorporated into most project management software packages.

Baseline.
A baseline is a snapshot of the state of a configuration item (or a plan) and its component configuration items at a point in time. Baselines, plus approved changes from those baselines, constitute the current configuration identification. Baselined plans represent those which have been formally agreed and accepted; each baseline should be permanently recorded - so that it can be recalled at any future time.

BCWP.
BCWP - Budgeted Cost for Work Performed
This is the value of work actually done at a given point in time. It takes the work that has been done and the budget for each task and shows what portion of the budget should have been spent to achieve it. This variable is often referred to as 'earned value' as it represents the true value of the work that has been completed.

BCWS.
BCWS - Budgeted Cost for Work Scheduled. This is the value of work that should have been done at a given point in time, it indicates the budget and work targets at that point in time.

Budget Variance.
As a project progresses it is important to monitor the overall costs of the project in relation to the original budget. These values are :
ECAC - Estimated Cost at Completion
This is a revised prediction of how much the project will cost (it takes into account the money spent so far and your current estimate of the total resources required to
complete the project).
BCAC - Budgeted Cost at Completion
This is the original budget for the whole project.
% Budget Variance = (BCAC - ECAC)/BCAC * 100

Business Case.
The business case details the justification for undertaking, and for continuing, a project. It is used to define the financial and other benefits which the project is expected to deliver, and the cost, timescale and other constraints within which the project is required to operate and against which its performance will be evaluated.

Business Co-ordinator.
The business co-ordinator is responsible for the planning, monitoring and reporting of a variety of administrative aspects of the project. The business co-ordinator should act as the focal point for administrative controls and is responsible for seeing that quality control procedures are followed.

Chairman.
The chairman of a quality review should ensure that the review process is properly organized in all three of its phases; preparation, review and follow-up. He/she chairs the review, records the actions noted by the reviewers and ensures that the direction of the review does not stray from its main aim - to detect errors.

Change Control.
The recommended change control framework is administered via the project exception mechanism. Project exceptions enable anybody connected with the project to raise any issue that is concerning them with the confidence that this issue will be analyzed via formal procedures. Project exceptions should be processed within the framework of a formal configuration management scheme.

Change Request.
Change requests are a formal means of proposing modification to the proposed end-product. They should only be raised under the authority of the project Manager as a result of analysis of a project exception. Each change request should be evaluated and a decision made whether to reject it, adopt it immediately or adopt it at a later date. In the latter case it is "held over" and may form part of a later enhancement to the product in question.

Configuration Audit.
Configuration audits involve verifying that all of the required configuration items are, in fact, in the stage of production indicated by the progress reporting information and that the current version agrees with specified requirements. The audits should also ensure that the technical documentation completely and accurately describes the configuration items and that all change requests have been resolved.

Configuration Control.
Configuration control is the process of evaluating, approving and co-ordinating changes to configuration items after formal establishment of their configuration identification description record.

Configuration Identification.
The process of identifying and designating the configuration items in a project and recording their characteristics. The method and scope of identifying configuration items should be designed to address the requirements of each individual project.

Configuration Item.
Configuration items can be formally defined as; "Any article that is indicated by any component of a configuration that has a defined function and is designated as requiring the controls of configuration management." Configuration items vary widely in complexity, size and type.

CIDR.
The configuration item description record contains the information needed to identify and track a configuration item through its development life cycle and correctly position it in the final deliverable. This record should contain the following information :
1) Name
2) Description
3) Life-cycle description
4) List of parent items
5) List of child items
6) Staff responsible
7) Date responsibility started
8) Source - e.g. in-house, externally supplied etc.
9) Current life-cycle phase
10) Latest baseline identity
11) Product list - required for current step
12) Change history - for any associated products

Configuration Administrator.
The configuration administrator is appointed to administer the configuration management and project exception procedures. They should control the receipt, storage and issue of the products created during the life of the project. This role may exist within the project team, or externally with responsibility for the delivered end-product - rather than being concerned with the project itself.

Configuration Management.
Configuration management is the process of identifying and defining the configuration items within the project environment and controlling the release and change of those items throughout the life cycle of the project. Configuration management also encompasses the recording and reporting of the status of configuration items and change requests, and verifying the completeness and correctness of configuration items.

Configuration Management Plan.
The configuration management plan should detail the configuration management procedures to be used throughout the project. It should be produced as part of the project initiation document, for approval by the project owner - at project initiation.

Configuration Status Accounting.
Configuration status accounting is the process of recording and reporting information that is needed to manage a configuration effectively. This includes the approved current configuration identification, the changes to the proposed configuration and the implementation status of approved changes.

Control Points.
Project controls should be applied as and when required. The controls are divided between management and product controls - the former being collectively termed control points, i.e.
1) Project initiation
2) Project reviews
4) Project closure
5) Post implementation review

Critical Path.
The critical path is the sequence of activities, as depicted on a PERT chart (activity network), that should take the longest time to complete. This sequence of activities (and there may be more than one such sequence on the network) will have zero float associated with it. The critical path is probably the single most important item of information shown on a PERT chart and is normally highlighted in some way - e.g. by using a contrasting color.

Dependency.
A dependency indicates a constraint on the sequence and timing of work within a project. Activities may be dependent on other project activities (internal dependencies) or on resources or inputs from outside the project (external dependencies).

Detailed Plan.
A detailed plan normally comprises two components - a detailed technical plan and a detailed resource plan. Detailed technical plans will exist on most larger projects. They are used to give a detailed breakdown of certain major activities, e.g. product testing, and are produced as and when required. A detailed resource plan will exist when it is considered necessary to plan and control a particular major activity within a stage. The detailed resource plan sets out the costs and resource usage, categorized by resource type, which correspond to a detailed technical plan.

Detailed Resource Plan.
A detailed resource plan should be created when it is considered necessary to plan and control a particular major activity within a stage. The detailed resource plan sets out the costs and resource usage, categorized by resource type, which correspond to a detailed technical plan.

Detailed Technical Plan.
Detailed technical plans give a detailed breakdown of certain major activities, for example product testing, and should be produced as and when required.

Document Update Request.
A document update request (DUR) is used to document any situation where the products being developed will fail to meet their original specification in some respect.
A DUR is a formal document that is used to update the documentation to reflect the product as it now is, rather than as it was in the existing design documentation.

Earned Value Analysis.
Earned value analysis (EVA) is an approach which compares the value of the work done with the value of the work that should have been done. You do not need to know how much has been spent - just the amount of work done and its value. EVA overcomes many of the intrinsic delays associated with variance analysis - the major problem with which is the amount of time it takes to accurately establish actual costs.

End Project Report.
This report should be produced by the overall project manager and tabled at the project closure meeting. It is used to document the projects performance and the major issues that were raised. To ensure that the experience of the project is recorded for the benefit of others it is helpful to hold a post-implementation review, typically around six months after delivery of the projects end-product.

Exception Memo.
An exception memo is a document that should be used to record situations which have resulted in a significant deviation from the planned quality review activities. They may be raised by the sub-project manager or project manager, or the chairman of a quality review.

Float.
Activity float is a measure of the flexibility of an activity, indicating how many working days the activity can be delayed or extended before it will effect the completion date of the project - or any shorter term milestone dates that are being applied. In addition to the float associated with a specific activity, there are two other types of float in network analysis:
1) Total float - here the float is shared with all of the other activities in the arm. Therefore using the float in one activity will reduce the float available for the other activities.
2) Free float - this is the amount of float that the activity can use up without affecting the 'earliest start' of any other activity. Only activities that precede a junction can have free float.

Gantt Chart.
Gantt charts, or Barcharts, are one of the most widely used project planning diagrams. The horizontal axis is normally used to represent the calendar time-scale in days and the activities are represented along the vertical axis. These charts should clearly communicate the duration and scheduling of the various activities - each activity being represented by a horizontal line from the its start to its finish date. The length of this line will be in proportion to the scheduled duration of the activity.

Highlight Report.
Highlight reports should be prepared by the project manager at intervals determined by the project owner, often monthly or four-weekly. They can also be generated at any time if the project manager becomes aware of an issue of sufficient urgency that needs to be communicated to the project owner. Highlight reports are also used to collate and distil the information conveyed in the progress reports. They review progress to date and highlight any actual or potential problems which have been identified during the period which they cover.

Histogram.
Histograms are graphical representations of the amount of resources that will be needed over a given period of time. They are a widely used project planning aid and are normally derived from the relevant Gantt chart. The only information that may be required in addition to the Gantt chart is the type of specialist resource required for each activity.

Impact Analysis.
Impact analysis is the term given to the process of assessing the ramifications of pursuing a particular course of action - typically a change to the existing project. Impact analysis can be carried out quickly and easily under a configuration management method which contains the following features:
1. A mapping from the requirements onto the configuration items
2. mapping from configuration items back onto the requirements
3. A structure showing the relationships between configuration items, so that no configuration item is changed without checking for implications that may effect its 'associates'.

Implementation Strategy.
Projects that are delivering a sophisticated or widely used end-product may well require an implementation strategy in order to detail the introduction and initial use of the end-product. Examples would include projects aimed at introducing new technology or at widening its application - for example the introduction of a new computerized accounts system. Other examples include business re-engineering projects and the delivery of large products that have a technical bias.

Individual Work Plan.
The individual work plan is the lowest level of technical plan which defines the tasks and responsibilities of an individual team member. It is derived from a project technical plan, a sub-project technical plan or a detailed technical plan - depending on the size and scope of the project. Individual work plans should be created by team leaders in conjunction with the appropriate project manager.

Informal Review.
Although the main application of quality reviews is for the formal review of an evolving, or complete, product; it is also possible to use a subset of these procedures in order to conduct an informal review. Informal reviews should be designed specifically to address the needs of the product(s) in question - but typically the usual sequence of events consisting of preparation, review and follow-up may be concatenated - as may the staff involved in the process.

Library.
A library is a set of configuration items - whether they comprise physical components, software or documentation. The project environment should have only one library, containing references to all configuration items; if not the items themselves. Each individual item within the library, i.e. all versions and all variants of all configuration items, will have a unique identification. Where several projects are working on the same end-product, they will share the library.

Life Cycle.
Projects are temporary structures set up with the specific aim of delivering an identifiable end-product. All projects will therefore have an identifiable life cycle, the
characteristics of which will vary according to the size and complexity of the project. A typical life cycle will run from the formal initiation of a project through to a post implementation review of the delivered end-product. This is an important point - that most project life cycles extend beyond the formal project closure and hand over of the specified end-product.

Line Manager.
Line managers are those staff who occupy permanent managerial positions within the organizational structure. The term is used to refer to all levels of organizational
management but does not include project management staff - who operate in a fluid environment (projects by their nature being temporary structures). Departmental managers, heads of department etc. are all job descriptions that fall within the general umbrella of line management.

Matrix Management.
A descriptive term for the management environment where projects cut across organizational boundaries and involve staff who are required to report to their own line
manager as well as to project management staff. In this environment, staff are required to report to more than one manager - hence the term matrix management.
Marketing/User Co-ordinator. The marketing, or user, co-ordinator is responsible for the planning, monitoring and reporting on all marketing, or user, related aspects of the project. This role essentially involves representing the marketing department or the users at all times.

Plans.
The plans used should be tailored to match the requirements of each individual project. A flexible framework of plans is proposed, along with an explanation of their use in a variety of project scenarios. Planning is an essential process but one that is frequently under- valued or viewed as 'an unproductive use of resources'. However whilst highlighting the need for effective planning it should be realized that the rigorous adherence to a comprehensive set of plans is not always the ideal solution for each and every project.

Post Implementation Review.
A post implementation review should be viewed as an integral part of the management and control of the end-product, carried out typically some 6 to 12 months after the end-product has been delivered. Its purpose is twofold: to check that the delivery has met the project objectives; and to check that the delivered product is meeting user needs.

Presenter.
A presenter at a quality review is usually the author of the item under review. During the preparation for, and during, the quality review he/she should ensure that the other review attendees (the chairman and a number of reviewers) have all the information they require in order to carry out the review effectively.

Product.
The concept of products is very useful as it facilitates efficient planning, activity identification and resource allocation. The overall deliverable of the project is termed the end-product. Products can be identified as any tangible output, either produced by, or for, a project. Virtually anything can be identified as a product - for the purposes of facilitating their planning and production. A product may be a physical component, an item of software, an intellectual creation, documentation or even a discrete group of tasks or activities (when the planners are desperate). A product may itself be a collection of other products - therefore giving rise to a product breakdown structure (PBS) and associated product specification diagrams.

Work Breakdown Structure.
The work breakdown structure is a product-oriented subdivision of all of the resources, including hardware, services and data that are required to deliver the required
end-product. The projects end-product appears at the top of the work breakdown structure, with the products that are required represented hierarchically beneath it. The work breakdown structure can be split into a series of diagrams, representing discrete sub-divisions; such as product groupings or all of the products relating to specific sub-projects.

Product Description.
The product description describes the purpose, form and components of each product and lists the quality criteria which apply to it. Each product in the product breakdown structure is associated with a product description; the component products of a complex product may be described in separate product descriptions, producing a hierarchy of product descriptions for the product.

Product Design.
The product description describes the purpose, form and components of each product and lists the quality criteria which apply to it. These, in association with the information contained in the product breakdown structure and product flow diagram will constitute the product design documentation. Each product in the product breakdown structure is associated with a product description. The component products of a complex product may be described in separate product descriptions, giving rise to a hierarchy of product descriptions for the product.

Product Flow Diagram.
The product flow diagram shows how the products are produced by identifying their derivation and the dependencies between them. Inputs to the production of product flow diagrams include product breakdown structures and product descriptions. The product flow diagrams are one type of product specification diagrams.

Progress Meeting.
This is a regular management control point. Progress meetings should be conducted on behalf of the sub-project manager or project manager. They bring together the project team members and provide the basic information used to measure actual achievement against plans. Ideally they should be run in an open manner, encouraging contributions from all members of the team.

Progress Report.
Each project should hold regular progress meetings as prescribed by the project owner - when specifying the controls framework they wish to see. Following each progress meeting the sub-project manager (with help from the project co-ordinators) should prepare a progress report and forward this to the project manager.

Project.
There are numerous definitions of what constitutes a 'project', many of which fail to define the term clearly and concisely. We suggest the following :
“A project is a human activity that aims to achieve a clearly defined objective against time, cost and other constraints.”
Projects should be characterized by :
1. A life cycle, defined by start and end dates.
2. A clearly defined objective.
3. A budget that is approved and forthcoming.
4. A team of suitably qualified people.

Projects should aim to :
1. Deliver the specified end-product(s).
2. Meet the specified quality goals.
3. Stay within budgetary limits.
4. Deliver on time.
Projects are unique, no matter how similar a previous project may have been - each project will be different in some respect. If this is not the case then the work being undertaken is not really a project.

Project Boundary.
A project does not normally exist in isolation. There are various relationships and areas of common interests with other projects, or other activities in the same department, organization, or even externally. The project boundary must therefore be defined in a way which makes it clear how related projects interact, and where the output from one project forms the input to another project, or related area of work.

Project Brief.
The project brief is a document initially provided by senior management, which is subsequently refined by the project owner into the terms of reference for the project. Both of these components should form part of the project initiation document.

Project Closure.
Project closure, signifying the formal end of the project, requires approval by the project owner. This is normally given at the project closure meeting control point. These activities should be led by the project owner and a formal mechanism for project closure, including a structured project closure meeting is advisable for all projects of significant size.

Project Closure Meeting.
The project closure meeting is concerned with reviewing the project, particularly with regard to ensuring the completeness of all project deliverables. The agenda should be based upon :
1. Review the end project report
2. Review all other information presented by the project manager
3. Ensure that all acceptance letters are signed
4. Verify hand-over of all maintenance documents
5. Verify hand-over of QA and training materials to the relevant staff
6. Schedule a subsequent meeting if any items remain unresolved
7. Inform the project sponsor and/or senior management of the outcome
8. Distribute minutes of the meeting, if appropriate.

Project Co-ordinators.
Project co-ordinators can be used to provide support in the planning and control of the project, in the application of standards, quality assurance and user/client liaison. They are usually full time members of the project office and bring continuity to each project they are involved with, by being familiar with its work from beginning to end. Project co-ordinators may be involved in more than one project at any given time. Four Co-ordinator roles are described in Project Team, and their appointment may shadow the roles appointed to the Project Executive:
1. Business Co-ordinator.
2. Technical Co-ordinator.
3. Marketing Co-ordinator.
4. User Co-ordinator.

Project Exception.
A project exception is any concern that has been formally raised by any member of the project team. It may address a potential technical problem, such as errors and failures, or identify ideas for improvements. Alternatively it may address a management issue, perhaps related to budgets, plans, schedules or skill shortages. The raising of a project exception report should start a formal process to ensure that it is analyzed and resolved. This process is called change control and should be administered within the context of the configuration management method adopted.

Project Exception Report.
A project exception report enables any member of the project team to raise any concern, in the knowledge that it will be considered and evaluated via a formal mechanism. This mechanism is called change control and should be administered within the context of the configuration management method adopted. The original concern can relate to any aspect of the project - it may address a potential technical problem, such as errors and failures, or identify ideas for improvements. Alternatively it may address a management issue, perhaps related to budgets, plans, schedules or skill shortages.

Project Owner.
The project owner is the senior management body (and this can be one individual) that is deemed to have ownership of a project. Its members should be appointed by the 'project sponsor' and be responsible for approving plans, committing resources and assessing the continuing viability of the project. The project owner is not normally responsible for the hands-on management of the project but should appoint staff to manage the project on their behalf and should avoid becoming entangled in day-to-day management decisions.

Project Initiation.
Certain management activities are required at project initiation to ensure that the project is established with clear 'terms of reference' and an adequate management
structure. These activities should be led by the project owner and a formal mechanism for project initiation, including a structured project initiation meeting is strongly advised for all projects of significant size.

Project Initiation Document.
The project initiation document (PID) should form the basis for gaining formal approval for the project - from the project owner at project initiation. It defines the 'terms of reference' for the project, based on the initial 'project brief' provided by senior management. In a typical project the PID should have the following components :
* Business case
* Project boundary
* Business needs
* Information needs
* Organization and responsibility definitions
* Project plans
* Terms of reference
* Configuration management plan (inc. change control)
* Quality policy

Project Initiation Meeting.
The project initiation meeting is normally the final stage in the project initiation process. It should be convened by the senior business member of the project owner in order to formally initiate the project.

Project Manager.
The project manager is appointed, by the project owner, to assume overall responsibility for the project throughout its life cycle. The project manager is responsible for : Planning at the project and sub-project level, exercising control (on a day-to-day basis), ensuring product delivery and exerting people management and motivation. On large or complex projects the project manager may be supported by sub-project managers, who are responsible for discrete sub-divisions (called sub-projects) of the overall project. Depending on the resources required and/or the skills available, the project owner may choose to appoint:
1. One project manager, supported by a sub-project manager for each sub-project;
2. One project manager who assumes the role of sub-project manager throughout;
3. A succession of sub-project managers, each assuming the role of project manager for the duration of the sub-project.

Project Office.
The most common project management environment combines full time project staff with departmental staff who are used on an as needed basis. Full time project staff who are permanently (and long term) involved in project related work, are often collectively referred to as the project office and their purpose is to support the project manager in carrying out his duties. Typically the project office supplies a variety of key project specialists - e.g. planners and co-ordinators, to any number of projects that may be being run within the organization. The project office usually includes a variety of staff with expertise in one or more specialist project areas e.g. planning and the application of organizational standards.

Project Office Manager.
Where the project office contains a significant number of people a project office manager may be appointed - to ensure the optimum utilization of its resources. Where this is the case the project managers will normally communicate directly with this individual in order to secure project office resources for their projects.

Project Plan.
A project plan will normally consist of a project technical plan and a project resource plan. The project technical plan is produced at the beginning of the project and shows the products required and the corresponding schedule of major activities that will occur throughout the project. It is a top-level plan produced in conjunction with a project resource plan. The project resource plan is a top-level management resource plan produced at the beginning of the project. It addresses all of the activities necessary in the production of all products - categorized by resource type, which fall within the project boundary. Both the project resource plan and project technical plan are used to monitor progress on the project as a whole. The project technical plan should also address strategic issues related to quality control and configuration management.

Project Resource Plan.
The project resource plan should show the breakdown of the major resource types the project will utilize. Once approved by the project owner the project resource plan becomes the top level business plan for the project. If the project has been divided into sub-projects then this plan should reflect the content of all the sub-project resource plans.

Project Review.
Project review meetings should be staged to monitor the actual progress against the baselined plans and to review any current or potential problems. The aim of these meetings is to gather information from project team members and allow them to hear what others involved in the project are doing. These meetings are usually held at regular intervals, for example weekly or fortnightly. Project reviews are primarily a project managers tool for monitoring progress at a practical level. They also consider current and potential problems and can be used to consider corrective action, where appropriate.

Project Sponsor.
The body responsible for the origination and funding of the project. In the context of critical projects in large organizations the project sponsor would normally be the board of directors; less significant projects may be sponsored at various lower levels. The project sponsor may also be a body that exists outside of the organization that is carrying out the work of the project - in which case it is normally referred to as the 'client'.

Project Team.
All of the staff working on project related tasks should be regarded as members of the project team. On large scale projects more than one team may be set up - to reflect discrete sub-divisions of the project; whilst smaller projects are likely to be serviced by a single team. Because any project team may consist of a mixture of full-time and part-time staff the definition of precisely who is in the 'team' at any given time, e.g. for reporting purposes, may not be clear cut.

Project Technical Plan.
The project technical plan shows the products required and a corresponding breakdown of the relationships between the major activities required by the project. Once approved by the project owner the project technical plan becomes the top level production schedule for the major products required throughout the project. If the project has been divided into sub-projects then this plan should reflect the content of all the sub-project technical plans.

Quality Assurance.
Quality assurance is concerned with how quality is achieved and assured through the specification of cost-effective quality control procedures, and through external
inspections and audits of the quality control system.

Quality Control.
Quality control is the process of ensuring that the required qualities are built into a product throughout its development. Quality control involves the examination and checking of products produced by the project. It is facilitated via the quality review, the various control mechanisms put in place (e.g. progress meetings and reports, highlight reports, change control and configuration management mechanisms etc.) and by the testing of the products against pre-determined acceptance criteria.

Quality Criteria.
Quality criteria, or acceptance criteria, are those characteristics of a product against which it can be objectively measured in order to determine whether it meets the
specified requirements. These criteria therefore define 'quality' in the context of that product and should be specified, in subjective and measurable terms, in the appropriate product description.

Quality Policy.
Quality policy, where it is applied, is the documented standard for the application of quality assurance and quality control procedures to the running of projects within an organization. Quality assurance is concerned with how quality is achieved and assured through the specification of cost-effective quality control procedures, and through external inspections and audits of the quality control system.

Quality Review.
The quality review is a means whereby a product (or group of related products) is checked against an agreed set of quality criteria (or acceptance criteria). Those criteria will be defined for every type of product and will be supplemented with other documents as appropriate. The review should be conducted by a chairman, a presenter and a number of reviewers. Where only a subset of the complete review process is required, an informal review may be carried out.

Release.
A release consists of a specified set of products from one or more baselined configuration items, which are issued as a set for a specified purpose. All recipients of the release should be informed, or consulted, before approval of any change to any constituent configuration items. Releases should be authorized by the project or sub-project manager.

Remedial Plan.
Remedial plans may be produced in situations where costs or timescales have already been exceeded, or are anticipated to exceed, the tolerance limits. If this is the case and no easier course of action can be undertaken to resolve the situation then a remedial plan may be appropriate. It is used to detail the work considered
necessary to bring the project back in line and effectively replaces the existing sub-project plan.

Resource Plan.
Resource plans are used to identify the type, size and allocation of the various resources required during the project. There are three levels of resource plans :
1) Project resource plan
2) Sub-project resource plan
3) Detailed resource plan

Requirements Specification.
The requirements specification details the user requirements including any constraints and possible future enhancements. The requirements specification should be written at a level of detail that enables appropriate solutions to be identified and formally proposed.

Resource Planning.
Resource planning involves the assignment of resources to each project activity in order to optimize efficiency and effectiveness. This may include scheduling activities so as to minimize fluctuations in day-to-day resource requirements.

Reviewer.
A number of reviewers may attend a quality review. They are responsible for checking that the product under review is complete and fault, or error, free. Quality reviews should be undertaken against pre-determined quality criteria - as detailed in the relevant product descriptions.

Senior Business Role.
The senior business role is one of the three representatives of the project owner - the senior management body deemed to have ownership of the project. The senior
business role should chair project owner meetings and provide direction to the other members of the project owner, this responsibility reflecting the importance of the
business interest. The senior business role should also take personal responsibility for ensuring that the project is delivered on time and within budget

Senior Marketing/User Role.
The senior marketing (or senior user) role is one of the three representatives of the project owner - the senior management body deemed to have ownership of the project. The main responsibility of the senior marketing role is to ensure that the project delivers the needs of the marketplace and to monitor progress against these requirements. If the project is going to deliver an end-product for use within the organization, then the senior marketing member should be replaced by a senior user member within the project owner body. The senior users prime responsibility should be to ensure that the users interests are represented at all times, at project owner level.

Senior Technical Role.
The senior technical role is one of the three representatives of the project owner - the senior management body deemed to have ownership of the project. The main
responsibility of the senior technical role is to represent the interests of the development and operations departments at project owner level; their other duties include ensuring that the technical activities are properly resourced.

Stage.
Larger projects may be divided into a number of stages; each stage forming a distinct unit for management review purposes. The main reason for dividing a project into stages is to facilitate detailed periodic reviews of the projects progress. The dividing up of a project into stages can be a complex process that benefits from the application of past experience. Generally speaking stages should reflect the completion of defined sets of products.

Sub-Project.
Large or complex projects may be broken down into one or more discrete sub-divisions. These sub-divisions can be identified as sub-projects for the purpose of management control, technical expediency, or both. It is normal to divide projects on the basis of major identifiable deliverables - such as major products, or groups of products; however the division can be based on any appropriate criteria.

Submission.
Formal procedures should be in place controlling the issue and submission of all configuration items (CI's) - those relating to administrative CI's as well as those pertaining to the evolving products. Configuration items are originally created at the time of their identification and then issued to appropriate staff in order that the necessary work can commence. Only when the author of a new or revised product or document is satisfied that it is complete and ready for review should it be re-submitted to the configuration librarian. The configuration librarian should receive and issue copies of all such documentation, in accordance with the formal procedures devised, and update the appropriate configuration item description record - in particular to reflect its current circulation. Without careful control over the issue and submission of configuration items the configuration management process can collapse.

Submission Request Form.
When a new or revised product or document is complete and ready for review, it should be submitted to the configuration librarian accompanied by a submission request form, detailing the following :
1) The identity of the document, and version number
2) The date of submission
3) The configuration item (CI) to which it relates
4) Step and stage number in the CI's life cycle
5) The name of the person submitting it
6) A list of the reviewers - each will need a copy

Project Team.
Projects may be run on the basis of a single project team, alternatively a number of separate teams may be created - for example to reflect the division of the project into sub-projects. The team organization, responsibility definitions and the allocation of these responsibilities to individuals will depend upon the size and nature of the project and the skill mix available. Task leaders should be appointed, usually by identifying suitably qualified personnel in the project teams.

Sub-Project Manager.
The sub-project manager is appointed, by the project owner, in consultation with the project manager, to assume day-to-day management of one or more discrete
sub-divisions of the project (the sub-projects). The responsibilities of this role are similar to those of the project manager but are restricted to the boundaries of the clearly defined sub-project. The sub-project manager should report directly to the overall project manager.

Sub-Project Plan.
The sub-project plan normally consists of a sub-project technical plan and a sub-project resource plan. A sub-project technical plan is required for each sub-project. It shows all technical products, activities and quality controls in that sub-project. A sub-project resource plan contains details of all the required resources for any one particular sub-project. A sub-project resource plan is produced initially - as the budget for the sub-project is presented to the project owner for approval prior to the formal commencement of the sub-project.

Sub-Project Resource Plan.
The sub-project resource plan contains details of all the required resources for any one particular sub-project. It is produced initially as the budget for the sub-project is presented to the project owner for approval prior to the formal commencement of the sub-project. After approval this plan is used by the sub-project manager to report actual financial expenditure and resource usage against that planned.

Sub-Project Technical Plan.
A sub-project technical plan is normally required for each sub-project of a project. It represents all of the technical products, activities and quality controls within the scope of the sub-project. The sub-project technical plan is produced in conjunction with a sub-project resource plan. The plans for the first stage sub-projects should be prepared and submitted at project initiation.

Task Leader.
The task leader fulfils a role in the project organization similar to that of a first line supervisor and will usually be expected to take on the responsibility for delivering discrete areas of work. Task leaders should be appointed, usually by identifying suitably qualified personnel in the project teams.

Technical Co-ordinator.
The technical co-ordinator is responsible for the planning, monitoring and reporting on all technical aspects of the project. The technical co-ordinator is also responsible for ensuring that the organizational technical standards are applied correctly and that products meet their technical quality criteria.

Technical Plan.
Technical plans are used to define the sequence and timing of activities, together with responsibilities assigned for
producing various parts of the overall product. Technical plans are derived from the product breakdown structure, the product flow diagram (PFD) and the PERT chart (which is itself based on the transformations identified from the PFD).
There are four levels of technical plan :
1. Project technical plan
2. Sub-project technical plans
3. Detailed technical plans
4. Individual work plans

Terms of Reference.
A definition of the objectives for a project, including any relevant background information.

Tolerance.
The permitted limits - as set by senior management or the project sponsor, in terms of the cost and timescale of the overall project. Tolerance may also be set by the project owner in terms of the cost and timescale of either a project or a sub-project. These limits may not be exceeded without reference to the appropriate body (the project owner, senior management or the project sponsor - in the case of externally funded projects).

User Co-ordinator.
The role responsible for monitoring, advising and reporting on all user aspects of the project.

Variance.
Variance quantifies the difference between the costs detailed in the plans and the actual costs incurred at any point in
time. It can be used to quantify the difference between the planned costs and the current costs incurred, at whatever level is required - for example for the project as a whole, for a sub-project, a group of related tasks or for individual tasks. In order to calculate variance, up to date and accurate information is essential - this is the main difficulty preventing the practical application of this straightforward technique.

Version.
A configuration item may have a number of versions relating to the continuing development of that configuration item.
In the first instance, a configuration item should be created and documented by the configuration librarian (the first
version). The configuration item may then undergo a number of modifications as it is tested and errors corrected, or as changes
are requested.

TOP <PREVIOUS NEXT>