5               Major Outputs and Deliverables

This section presents the major outputs and deliverables for each of the project management phases described above and the project manager’s participation and responsibilities related to them.

5.1           Initiation

At the beginning of Project Initiation, a Project Manager is assigned, if not already present. The Project Manager works with the Project Sponsor to identify the necessary resources and team members needed to further develop the key project parameters – Cost, Scope, Schedule, and Quality (CSSQ). The Project Team documents its charge in the form of a Project Charter, which is based on the Project Proposal, which includes the initial Business Case.


Approval of the Project Charter by the Project Sponsor authorizes the designated team to begin the initial planning effort. Developing the Project Charter is primarily concerned with documenting the business needs, project justification, current understanding of the requirements, and the new product, service, or result that is intended to satisfy those requirements. The Project Charter, either directly, or by reference to other documents, should address the following information:


The initial Project Plan resulting from Project Initiation differs in the level of detail and the validity of its estimates from Project Origination, and must be at a level sufficient to acquire any additional resources needed to progress to the next phase. The Project Plan also includes plans for involving and communicating with all the parties that are affected by the project, as well as identification of an initial set of foreseeable risks that can threaten the project. At the conclusion of Project Initiation, based on the initial planning documents, the Business Case is revised and re-evaluated and a decision is made to either halt the project, or proceed to Project Planning.

5.2           Planning

Project Planning builds on the work done in Project Initiation, refining and augmenting CSSQ and Project Plan deliverables. Usually, additional members join the Project Team, and they assist the Project Manager in further elaborating the details of the Cost, Scope, Schedule and Quality. A number of key elements are added to the Project Plan, including project-specific items such as change control, acceptance management and issue management, as well as externally-focused items such as organizational change management and project transition. The initial list of project risks is augmented, and detailed mitigation plans are developed. Project Planning marks the completion of the Project Plan – i.e., no work is left uncovered. However, some of the later phases of the project work may continue to be planned in more depth (e.g., Transition and Implementation details may not be developed until later in Project Execution). At the conclusion of Project Planning, the Business Case is revised and re-evaluated based on the completed planning documents and a decision is again made to either halt the project, or to commit the resources necessary for Project Execution and Control.


     Planning is an essential activity that determines the success or failure of a project and must be given adequate time. The planning process can be addressed by answering the following five questions: what, how, who, when and how much. The what is provided in the form of a specification, such as a Functional Specification or detailed user requirements. The how is provided in the Work Breakdown Structure (WBS). The who is provided in the resource schedule. The when is shown in the schedule. The how much is indicated in the cost schedule.

5.2.1        Planning Processes

Work Breakdown Structure

The Work Breakdown Structure (WBS) is equivalent to an organisational structure that is based on a hierarchy.  It is a hierarchical representation of tasks that define, organise, and display the work to be done on a project. At the very top of the WBS is the project itself. The next layer down is a meaningful subdivision of the project into phases/stages or major deliverables. Further subdivisions are made until there is a single output or deliverable at the end of every activity. A WBS helps to organise the project and provides a structure for meaningful management summary reporting. It can also be automated to facilitate budgeting and cost control procedures. The budgeted and actual cost of performing an activity or providing a deliverable at any layer in the hierarchy can be compute



Estimates are required for all resources, including human resources, facilities, equipment, and products, to be supplied by the contractor and its partners. For each item, the aspects that need to be estimated are:

The following must also be considered when estimating:


It is important that there is no confusion between cost and price estimates.



After the WBS has been produced and the effort estimated, the tasks should be scheduled, showing planned start and finish dates for each task. The project schedule should include an overall schedule for the entire project and a detailed schedule for the next phase/stage.


Milestones should be shown. These are points in time, denoting the completion of a specified part of the project, such as a phase/stage transition, and they need to be clearly identified. They are a useful method of communicating progress to the customer, the management and the Project Team(s). In some cases payment by the customer may be linked to specific milestones. In these circumstances, criteria for achieving the milestone must be specified and agreed to by the customer.


When producing a schedule, the following techniques should be considered:

A precedence diagram is a method used to show the sequence of tasks, in the form of a network, which identifies the interdependencies between tasks.


Critical Path Method (CPM) is a scheduling method, also based on a network that identifies the single chain of tasks through the schedule that will take the longest to complete or achieve. CPM incorporates the word `critical` because, if this sequence of tasks and milestones is not complete on time, the project will not finish on schedule. Planned start and finish dates should be added and the logic of the diagram should be configured to minimise the impact of the critical path.


A bar chart/Gantt chart can be used to show the network of tasks against a project calendar, taking into account the length of the working day, holidays, and other factors. It will also facilitate the mapping of resource availability against the activities and skills required and for resource levelling to take place.


Resource levelling techniques distribute the use of resources over time to minimise the variation in manpower, equipment, or money to be expended. The central idea of resource levelling is to reschedule tasks and milestones within the limits of available slack to achieve a better distribution of resources. The resource levelling procedure should not allow the duration of a project to increase.


Slack, once commonly know as float, can be used to calculate the amount of time over and above that is required that is required to complete the task or milestone.

Stretch is a factor used to calculate the amount of calendar time required, to complete a specified amount of effort. The stretch factor can take account of non-project overheads, such as holidays.


PERT is a time-focused, network-based planning system, which is used for projects where meeting the schedule is more sensitive than costs.


5.2.2        The Project Plan

A Project Plan should be prepared in the early part of the project. This should identify the tasks, resources, organisation, time-scales, and dependencies necessary to complete the project. The Plan should be regularly updated as more information becomes available, for example, with supplementary plans that focus on particular aspects of the project. The typical format for a Project Plan is shown below


The Project Manager is also responsible for for planning the financial aspects of the project. These details are included in the Project Business Plan, which must be attached to the Project Plan.


The Project Plan should be approved according to the appropriate approval procedure that is normally dependent on the size and risk of a project and the THE business procedures. If, after the approval process, there are many significant changes to the original approved plan, the senior management will need to be fully involved, and re-approval obtained, if necessary.


Planning is an interactive process and the Project Plan must be frequently reviewed and updated. It is normal practice to prepare an overall plan for the entire project and a detailed plan for the next phase/stage only. However, it is important to plan sufficiently in advance and to consider some of the issues that may arise later in the project life cycle that could potentially impact the plan. These might include the following:


Risk and Contingency Planning

A risk assessment first takes place during qualification and it is used as as basis for risk management. During the planning process, more risks may be identified. All risks should be documented in the Project Plan. By approving the Project Plan Senior Management is also accepting the associated risks.


All projects have an inherent level of risk associated with them. It is essential to identify risks at the earliest possible opportunity and manage them appropriately. This entails logging major risks, monitoring them throughout the project, forecasting and accessing the impact of changes on the risks and, when appropriate, ensuring that the remedial action is taken. The Project Manager must report regularly on risks, seeking re-approval of the Project Plan whenever there is significant increase in project risk.

5.2.3        The Project Plan Format

The Project Plan provides a central file containing all material of a planning nature, including tasks, resources, organisation, time-scales, and dependencies necessary to complete the project. It enables the progress of a project to be monitored consistently.

The Project Plan covers information relating to the entire project, but at any point in time, it will contain detailed activities for only the current stage/phase and the next stage/phase.

As more detailed information emerges during the course of the project, The Project Plan should be updated accordingly, for example with supplementary plans focusing on particular aspects of the project. These should be incorporated into the Project Plan and should follow the same format where appropriate, but without duplicating information. In the case of the Project Business Plan and the Project Quality Plan, the specific formats, as defined in the Project Management Manual, should be followed.

Project Plan Format

  1. Executive Summary

  2. Introduction

    1. Purpose and Goals

    2. Project Strategy

    3. Scope

    4. Deliverables

    5. Functional Interfaces

    6. Standards (specific to the project)

    7. Reference Documents

  3. Project Structure

    1. Roles and Responsibilities (Project Team, Project Manager, Sponsor)

    2. Constituent components of the Project, relationships and dependencies

    3. How the Project Team is to work together

    4. Role of Customer

    5. Role of Third Parties

    6. Management Involvement and Approval, Executive Relationships

    7. Project Change Management Process

    8. Project Management Techniques and Tools to be used

  4. Activities and Estimates

    1. Tasks, Sub-tasks, Activities, Effort, and skills required to complete the Project

  5. Schedule

    1. Schedule by Stage/Phase and Major Task of the project

    2. Milestone List

  6. Resources

    1. Personnel

    2. Equipment

    3. Facilities

    4. Other

  7. Reviews and Approval

    1. Project Reviews

    2. Project Document Approvals

    3. Stage/Phase Transitions

  8. Project Dependencies, Risks and Contingencies

    1. Dependencies on outside projects/events

    2. Risks and Contingencies

    3. Problem Resolution Process

    4. Escalation Procedure

  9. Appendices

Supplementary plans that focus on particular aspects of the project should be produced for incorporation into the Project Plan. These should be planned from the outset and updated as more detailed information is obtained. Apart from the Project Business Plan and the Project Quality Plan, for which there are specific formats, the supplementary plans should follow the format of the Project Plan where appropriate, but without duplicating information.

Supplementary Plans

5.2.4        Supplementary Plans

The supplementary plans are usually prepared over a period of time and are an addition to the Project Plan, focusing on specific aspects.

These include the following:

Contingency Plan

This is only likely to be a separate plan when the contingency arrangements are so complex to warrant this. The plan is specifically aimed at continuing the project in the event of one or more risks occurring. It is to be hoped that it will not need to be used.

Business Plan

This plan contains all the relevant internal business information regarding the Project. Information in the Business Plan is highly sensitive and should be available for company internal use only on a restricted distribution basis.


Quality Plan

The Project Manager is responsible for the quality of the project a s well as for the quality of the solution components produced by the project. Quality should be a priority throughout the project life cycle and should be planned from the outset.


Test Plan

It is the Project Manager’s responsibility to integrate the planning of testing. The activities should identify the overall scope, approach, resources, schedule and risks of the testing tasks over the entire project life cycle and document them in the Test Plan. The Test Plan should define the generic levels of testing and the basic test environment and structure needed to support the required levels of testing.

It should be clearly understood that the test plan acts as a contractual and legal document and unless otherwise approved by the management must covers the following:

In principal the Test Plan should:




The plan to integrate the solution components and the Quality plan should be co-ordinated, and may be combined, with the Test Plan.

Included in the Test Plan, the customer will expect the Project Manager to establish a test and evaluation program that verifies that the solution meets the technical and operational requirements as stated in the agreed specifications. The method of verification could include analysis, inspections, demonstrations, and/or tests.

The extent in which the customer is involved in the Test Plan, will be determined by the contract requirements and the relationship between the project and the customer.


Solution Introduction Plan

This Plan is concerned with all aspects of introducing the solution into the customer’s environment so that the solution becomes fully operational with minimal disruption to the customer’s business. The plan covers many activities that are the responsibility of the customer.


Service Delivery Plan

The plan is concerned with all aspects of providing services as part of the project. As appropriate, it includes the:


Configuration Management Plan

This plan focuses on all the activities necessary to control the versions of the solution components, so that consistency between them is maintained.>>>


5.3           Execution

Project Execution and Control is where most of the resources are applied/expended on the project. A significant number of team members will join the project at the beginning of this phase. The primary task of the Project Manager during Project Execution and Control is to enable the Project Team to execute the tasks on the defined Project Schedule and develop the product or service the project is expected to deliver. The Project Manager uses the processes and plans prepared during Project Initiation and Project Planning to manage the project, while preparing the organization for the implementation of the product/service and for transitioning the product/service responsibility from the Project Team to the Performing Organization.

5.4           Monitoring and Control

Monitoring and Control (also covering Reporting) are the direct responsibilities of the Project Manager although the may be delegated to others at different levels of detail. The Project Manager is responsible for monitoring, controlling and reporting at the project level. The Project Leaders are responsible for this at the module or component level. The process is the same at all levels throughout this hierarchy.

Close working relationships and a strong bond between members of the teams will help communication to flow effectively and for information to be shared. This in turn will help to maintain a sense of commitment and high motivation. The monitoring, controlling and reporting process should take place on a regular basis, preferably weekly at the more detailed levels, so that problems and issues can be captured early, and the impact on the project, deliverables, or even the Project Team can be minimised. It is important to ensure that this process does not become a hindrance or impair the productivity of team members.

This section considers the different processes of monitoring, analysis, control and reporting.

5.4.1        Monitoring

Monitoring involves taking measurements of the current situation. At the most detailed level, it will involve activities such as:

To facilitate monitoring on a weekly basis, it is useful to prepare a weekly plan for each member of the team, identifying the activities to be performed, such as unfinished activities from the previous week, new activities, reviews and meetings. Resources assigned to a project must ensure that they cannot take up activities, which are not defined in the weekly plan, unless authorised by the Project Leader/Project Manager.


When all the relevant information has been obtained, it must be analysed to compare actuals against the Project Plan and to determine the variances. The analysis should focus on a comparison of the:

A graphical representation may help this comparison process by highlighting trends and variances.


5.4.2        Control

Having established the trends and variances, The Project Manager needs to replan and take effective controlling action as appropriate. This might include the following:


  1.  Reporting

  2. Though seen as part of Control, reporting generally follows on from monitoring and control and is used to inform the customer, Management, and third party management of the current status of the project. In some cases, reference to milestones is used as a basis for this. Issues, concerns and items that require resolution should be clearly identified. These same elements may be carried over from one reporting period to the next until they are resolved. Achievements during the reporting period and any expected revisions to the plan should be covered. Expected achievements by the next reporting period should also be identified.

    Reporting also provides management not directly involved in the daily activities with a means to access progress, risk, customer satisfaction, and so forth. Reports produced may also be tailored or condensed for presentation to the customer.

    Status reports should be produced on a regular basis, as defined in the Project Plan.  The contents will vary, but may include some or all of the following:

    The items that should be maintained are:


    If third parties are involved or teams are divided across multi locations then the monitoring and administration requires agreed formal procedures by all parties involved. The project manager retains overall control, but may decide to designate more of the activities involved.


    Monthly Progress Report

    The Project Manager is responsible for submitting the formal monthly progress report to management.The standard form is shown at Appendices A.1, A.2 and A.3.

    (Note: waiting for a report to be typed is not a valid or acceptable reason for delaying the issue of a report).

    The sections that follow provide instructions for the completion of the report referring to each appendix attached to this document:




  3.  Project Identification


  5.  Aim of Project

  6. This section contains a short statement describing the desired end-state. In other words what the project has been set up to deliver. It should not change throughout the project.


  7.  Current Status

  8. This section is used to provide a brief description of the current status of the Project. It must be short and to the points and should include mention of:


  9.  Project Milestones

  10. This section is to give the Project Board (Executive Management) an overall view of the project timescale as now perceived. The following information should be entered:


    Project Milestones are expected to be defined in the Project Plan.

    (Note: Milestones must have meaningful names. ‘End of Stage 2’ might be meaningful to the Project Manager but it may mean nothing to members of the Project Board.)




  11.  Achievements


    Deliverables Completed this Month

    This sub- section is used to notify the Project Board of significant deliverables that have been completed. Enter the following information:


    Note: ‘Completed’ means fully accepted and signed off - not  initial versions.


    Other Achievements This Month

    Use this sub-section to report significant events, which have a significant positive impact on the project. Examples could include:



  13.  Exceptions

  14. This section is used to inform the Project Board of deviations from the Project Plan.



    This sub-section is for project activities that have used resources this month but which were either not planned to start until later, or were not planned at all. It is not designed to cover the activities of project staff on tasks which lie outside the project (e.g. PC Support or maintenance of other systems).


  15.  Outstanding Issues

  16. This section is to notify the Project Board of issues that have been formally raised but which are not yet resolved. The Issues Procedure requires Project Managers to formally record issues and to monitor the progress towards resolution. This sub-section should only contain issues which have been formally recorded under the Project Issues procedure. If the Project Manager knows that an Issue should be mentioned here but it is not on the Project Issue Log, then he or she should raise the Project Issue Report and deal with it accordingly


    The information to be recorded is self-explanatory. ‘Progress’ should be kept brief: if the Project Board or any other interested party wants detailed information they can get it from the Project Issue Report.


  17.  Deliverables To Be Completed Next Month


    This section, informs the Project Board of deliverables scheduled to be delivered in the next calendar month. They may have been planned to be delivered some time previously or even some time ahead (a reference to these deliverables may also exist in the “Deliverables Planned but not Delivered” section of Exceptions).

    Note: ‘Completion’ means fully accepted and signed off - not initial or interim versions which may have to be changed on review.


  19.  Project Delays

  20. This section is to provide a brief description of the various factors causing a delay in the project and to allow the project manager to suggest actions to rectify the situation.

    Number each cause of delay and suggested resolution/comments accordingly.


  21.  Project Managers Comments

  22. This section is to allow the Project Manager to clarify for the Project Board the major points to be noted in the Monthly Progress Report. If relevant, it also allows the Project Manager to indicate any actions required of the Project Board.

    Comments should be short and to the point.


  23.  Signature

  24. The report is signed and dated by the Project Manager (the date is the date of release, not the date of first draft).


    APPENDICES A.2 & A.3



  25.  Budget Status

This section is to notify the Project Board of the use of resources against plan. Its purpose is to enable the Project Board (or, to be exact, the Business Assurance Coordinator on behalf of the Project Board) to monitor the use of resources against plan and to update the Business Case with details of currently expected costs to compare against benefits. Resource usage would normally be expected to be expressed in financial terms. Continued project viability should be assessed by the Project Board on the basis of the Net Project Value derived from the Cost/Benefit comparison.


The Financial Budget and the Resource Budgets are created with MS/EXCEL.


It should be noted that, the Monthly Progress Report Form at Appendices A.2 and A.3 utilise EXCEL spreadsheets already formatted. If Project Managers have access to MS/OFFICE it is suggested that they utilise the electronic version of the form to create the report directly using MS/WORD and MS/EXCEL. The Financial and Resource Budget sub-sections can then be completed once and merely updated each month thereafter.


The two sub-sections should be completed as follows:


This section gives information about the “Paid”, “Authorised”  and “Estimated”  Cost for the particular project.

The financial budget is categorised under the following:

This category will contain entries concerning any kind of Study for the particular project,  (e.g. Feasibility, Scoping, Audit, Preliminary, User Requirements, etc.) carried out by external Suppliers or Consultants.


This category will contain entries concerning the application software (Bespoke or ready made package).


This category will contain entries concerning Computers, all electronic equipment, System Software (Operating System, Network Management, RDBMS, etc.).


Projects that are concerned with tenders that are for Turnkey solution , the amounts estimated, authorised and payments done towards the particular contract should be included here.

In case of Turnkey Solution other budget categories will be omitted (e.g. Software, Hardware, etc.)


This category will contain entries like (hardware) above but the equipment will be used for the Data Capture module of the particular project and is not included in (hardware) or (turnkey solution) above.


This category will contain entries concerning application software, or amounts estimated, authorised or paid for data entry services etc. and is not included in (software) or (turnkey solution) above.


This category will contain entries concerning amounts for the purchase of  UPS and is not included in (hardware) or (turnkey solution) above.


This category will contain entries concerning amounts for the cabling of the buildings of the particular project and is not included in (hardware) or (turnkey solution) above.


In this category entries concerning additional amounts  for Hardware (see ‘hardware’ above)  should be entered.  For example for a project that an original amount has been estimated/authorised and then additional amount is required then all amounts related to that will be entered here.  All additions are related to Hardware Contract already in existence, thus in the note column the Contract No.  should be referred to.


In this category, entries concerning additional amounts for Software (application software - see ‘software´ above) should be entered.  For example for a project that an original amount has been estimated/authorised and then additional amount is required then all amounts related to that will be entered here.  All additions are related to Software Contract already in existence, thus in the note column the Contract No. should be referred to.


After a project has been implemented all amounts related to the operational support of the particular project should be entered here.


This category will contain entries related to the amount of money required/spent for training of people of the particular project and is not included in (studies) ,(software), (hardware), (turnkey solution) and (data capture services) above.


This category is to record sums estimated as being required, over and above known or estimated contract cost.  In the early stages of a project, where costs are all estimates, contingency will be included within the overall estimates and this category is left blank. Later, when contracts have been let.  There are never any ‘Actual’ or ‘Authorised’ entries in the Contingency category.


This category will include entries for amounts estimated/authorised/paid for  the employment of consultants as members of the Project Team. It does not include Consultancy contracts for specific deliverables (e.g. Preliminary Study) which will be classified as ‘Studies’.


Any other entries not included in any category above should be entered here with a description in the “note” column.

            For each category the following should be completed where appropriate.

Date.    It should denote either the date a payment was done, or an amount was authorised or an amount was estimated for the project for a specific category.

Actual will be the date of payment.

Authorised will be the date of Tender Board decision.

Estimated will be the end of month estimated that payment will occur, (if known) otherwise end of year  in which payment is due.

Year. The year of the Date field in four digits, i.e. 2000.

Item. If no formal Project/Stage Plan exists enter explanatory text indicating for what the payment/authorisation/estimation has been done for, otherwise use planned deliverable name.

Paid amount. The amount paid in Cypriot pounds and not including VAT.

Authorised Amount.    The amount first authorised by the Management for this Stage/Category.

Estimated Amount.   The amount estimated as being required to be spent for each item.  If an amount has been authorised the estimated amount may differ.  However, if the item has been fully paid for, the Actual & Estimated must be the same.  (The Authorised ought to be the same).

Whenever the amounts concerned are in foreign currency, conversion for the “authorised amounts” should be done using the rate stated in the relevant contract.

Once the figures are entered in the Excel spreadsheet of the financial budget, the category and project totals are calculated automatically. They will not be calculated correctly unless the Year field is completed in four digits for all items to be included in the calculations. 

MS/EXCEL limitation: Note that when inserting a row right before the category total row, the formula that calculates the category total is not adjusted automatically to include the new row in its calculations. It is the project manager’s responsibility to adjust the formula manually in order to ensure correct totals. This requires that the project manager:


(1)     clicks each relevant cell of the category total row (the ones marked £0), which then becomes active and

(2)     types in the correct range of the SUM formula that appears in the formula bar i.e., SUM(C1:C1) will become SUM(C1:C2), where C2 is a reference to the relevant cell of the row added.


This sub-section deals entirely with the effort expended by resources assigned to the project. The effort should be included in Stage plans.  It does not include the effort of Supplier staff, whose cost will be included in the Financial Budgets described above.


                      (Baseline Planed Mandays - To Go )       x  100

                      Actual Total Mandays Effort to Date


                      (Baseline Planed Mandays - To Go )       x  100

                        Planned Total Mandays Effort to Date



5.5           Progress Control

Progress control is concerned with directing activities, monitoring and reporting upon the use of resources, assessing achievement, and decision-making. Progress is measured by achievement of targets and milestones compared with plans. Progress control is effected by regularly collecting status information on deliverables, with particular emphasis on what remains to be done to complete the work and the resource implications. It is also assessing the status of work in terms of actual achievement compared with expectations expressed during planning, producing reports which highlight these findings and taking corrective action promptly to minimise any unnecessary disruption to project progress.


As a minimum, progress is reviewed weekly reporting on :-



5.6           Quality Control

Quality control is concerned with ensuring that the deliverables are fit for their intended purposes, that they meet the specifications, adhere to the relevant standards and are complete.  Quality control and quality assurance management are concerned with integrating all activities as depicted in the following diagram.


5.7           Change Control

Change Control or Change Management is concerned with controlling the results of unforeseen events, factors or mistakes which might modify or remove the need for the deliverables being developed. Such changes can occur at any time, before, during or after their creation. It is inevitable that there will be changes during the lifetime of a project and the Project Manager is concerned with the management and control of changes so that impact to the project may be minimised.


Change management involves a set of procedures including, change requests, evaluation of requested changes, change approval and implementing approved changes. Changes may be classified as minor changes, those which may be accommodated without impacting the project plan, and major changes which necessitate a revised plan and its re-approval.

Issue Management

In addition to changes, other issues may arise which may have an impact on the progress of the project. Examples of such issues include non-completion or late completion of actions by either the customer, the supplier or other involved party. Resourcing difficulties for either customer or supplier, etc. Such issues occur more commonly than most of us would like and to ignore them will always result in greater problems later in the project. We have a common issue management and change control procedure whereby all problems, no matter how large or small, are documented and communicated. The Project Manager together with the appropriate personnel meet to discuss these problems, identify solutions, the impact of these solutions and together with the customer agree on the action to be taken. There is also an associated escalation procedure whereby more senior management may become involved n order to resolve complex or time critical issues.

5.9           Configuration Management

Configuration Management is the software engineering discipline for:-


All software modules, specifications, test procedures, etc. are configuration items and subject to change control. A base level (or baseline) is the set of all documents and files that comprise a specific version of a product (or application) created at a specific time. Configuration management is therefore concerned with the identification and control of all components in any given base level.


It should be obvious that configuration management is almost synonymous with change control in that a change to a configuration item has an impact on the base level. However, both are necessary. Change control ensures that all changes are requested, reviewed and approved and configuration management ensures that all approved changes are applied correctly so that the integrity of each base level is maintained.


Good configuration management becomes essential for large projects involving many configuration items. Automated CASE tools to support this discipline are usually utilised.

5.10        Traceability

Traceability may be defined as the ability to trace a design representation or actual program back to requirements. Essentially traceability implies the two-way tracing of requirements through to program code and vice versa. It is also extended to include the tracing of requirements through to non-software deliverables, such as training and documentation.


Traceability is an important vehicle that serves to ensure all specified requirements are designed and coded and that each software module has a justification in the form of an initial requirement. It is therefore useful during acceptance. The traceability document also provides a valuable support document for configuration management since it links, via a cross reference, all of the configuration items.

5.11        Project Closure

In Project Closeout, the Project Team assesses the outcome of the project, as well as the performance of the Project Team and the Performing Organization. This is accomplished primarily through soliciting and evaluating feedback from Customers, Project Team members, Consumers and other stakeholders. The primary purpose of this assessment is to document best practices and lessons learned for use on future projects. Key project metrics are also captured to enable the Performing Organization to compare and evaluate performance measurements across projects.