The project structure covers the manner in which staff is organized and the mechanisms for project reporting. Both the team structure and the reporting mechanisms are highly dependant on the size, duration and the nature of the project. For this project, the ideal team structure and reporting mechanism are detailed below.

The team structure for this project is depicted in the figure below. Roles and responsibilities of each team member have been explained in the section on Roles and Responsibilities below.

Project reporting occurs at two levels; intra team and inter team. Inter team communications occur within the project team while inter team reporting occurs from the project team to the senior management and the Client. A schematic of the process for progress reporting and inter/intra team communication is shown in the figure below.

Effective and timely communication on a project is a critical success factor. It goes a long way in managing the expectations of the client. If the client and his team are not kept well informed of the project progress there is a much higher probability of problems and difficulties arising due to differing levels of expectations.

Keeping in view the above points, two types of reporting shall be defined and implemented for this project:

• Reporting from the Project team to the Project Manager
• Reporting from the Project Manager to the Client

Two typical forums for communicating status are through a Status meeting and Status Reports. These activities are listed below:

Weekly Status Meetings The team shall attend status meetings on a weekly basis. The client may choose to have representation at the status meeting. If the project manager prefers, there could be a status meetings for the project team and a separate meeting with the client. There will be a standard agenda for the meetings and they will be kept to no more than one hour. In general, the purpose of the meetings is to communicate status, not solve problems.

The project manager shall send Status Reports to senior management and the client on a weekly basis.

The project team members shall send a weekly Status Report to the project manager detailing their progress during the reporting period. The project manager shall update the status of each assigned activity in the work plan. This reporting is over and above the weekly status meetings.

The team shall sequence status reports and status meetings on Monday or Tuesday, with the weekly team member Status Reports due to the project manager by Friday morning. This process ensures that the project manager is up-to-date on all project activities at the end of the week and is prepared for productive status meetings with the project team and the client at the beginning of the following week.

QA will work to foster constructive communication, provide feedback to detect and prevent development problems, control risks, discuss alternative solutions, and ensure quality is built-in to all applications.

The responsibilities of the Project Manager are listed below.

• Provide management support, supervision, and oversight for the project QA function.
• Ensure the independence of the QA function.
• Make available staff and other resources as needed to support QA and project development.
• Ensure resolution of problem and concern issues.
• Review QA audits, reports and ensure project is on schedule.

The responsibilities of the Project Leader are listed below.

• Manage overall System performance.
• Ensure QA activities are conducted and project plan is followed
• Ensure compliance with the QA program and system requirements
• Ensure responses to deficiency reports from QA reviews and audits
• Define system test cases
• Define training needs, develop plan

The responsibilities of the Team Leader are listed below.

• Develop system module(s)
• Monitor Functional and requirements specifications are implemented
• Escalate QA issues concerns to Project leader
• Report any technical non compliance to Project leader / Senior management
• Define Unit test plan and monitor test result

• Develop and maintain the Quality Assurance Plan
• Conduct audits and reviews
• Ensure work applications adhere to the appropriate standard
• Develop audit and review procedures for System activities
• Ensure the QA processes and procedures adequately control project quality
• Ensure the QA activities accurately measure the application, service and process quality.
• Review and approve specified deliverables for release.
• Promptly report result of audits to the project task leader.
• Periodically report unresolved noncompliant items to technical monitor/senior management.
• Maintain an on-going dialogue with the technical monitor and System support staff.
• Ensure that the expectations of QA activities are identified and understood between the technical monitor, task leader, and the team members.
• Collect and analyze metrics produced from the results of the QA process.
• Recommend changes in procedures to improve processes.

• Develop and maintain the Code.
• Implement QA processes.
• Implement code standards.
• Update and report status.
• Promptly report result of audits to the project task leader.
• Periodically report unresolved noncompliant items to technical monitor/senior management.

Various control mechanisms shall be defined to control various aspects of the project. Control mechanisms shall be implemented on the following:

• Project progress
• Changes to system requirements
• Problem resolution

The Quality management System proposed for this project is the ISO 9000:2000 series. The system comprises eight quality management principles on which the quality management system standards of the revised ISO 9000:2000 series are based. The senior project management as a framework to guide the project team towards improved performance will use these principles.

The eight principles are:

• Customer focus
• Leadership
• Involvement of People
• Process Approach
• System Approach to Management
• Continual improvement
• Factual approach to decision making
• Mutually beneficial supplier relationship

A number of components, documents as well as program codes will be developed as a part of the project implementation. These components comprise the IT Baseline and it is imperative for the baseline to be protected. As a part of the IT Baseline protection, the following components of the application shall need to be securely stored and transferred to the Client:

• Design Documents
• Program Specifications
• Program Source
• Securely transfer program source to the Client

IT Baseline Protection shall be implemented at two levels:

• Software and Hardware Level: These are safeguards related to software and hardware protection to be implemented both at the Project team and the Client's end. Refer Appendix K for a list of proposed safeguards to be implemented at this level.
• Organization Level: A catalogue of safeguards to be implemented at the organization level. These shall be implemented at the Client end. Refer Appendix L. for a list of proposed safeguards to be implemented at this level.

The change management control and tracking is covered in detail in Chapter 6 on Change and Defect Management.

A Quality Assurance Plan shall be created keeping in the mind the specific requirements of this project.

Project handover is defined as the process of handing over of all deliverables defined for the system. The following tasks are part of the project handover phase:

• Submission of all relevant documentation
• Submission of Program Source Code
• User Training
• Acceptance Sign off
• Warranty Period

The System will be handed accompanied by a comprehensive and detailed reference and document library. Apart from accompanying documents and reference of third party hardware and software, the System will have adequate and suitable documents for the system to be developed. All documentation prepared will be simple, comprehensive and detailed. As far as possible, the target user will be considered as a non-technical person.

Document preparation will be undertaken before, during or after the application development (as applicable, depending on the document required).

This document is focused for people who are end users of the System. This will be detailed user manual explaining all the Non technical functionalities of the system.

This document/s is focused for administrators of the System. This will be detailed document covering all the hardware and software of the System. Also this document will contain the technical functionalities, which should be of help for maintenance of the system.

The system documentation shall be covered under following documents.

• System specification document
• System software documentation
• System administration security and operation documentation
• Equipment documentation

All users, maintenance and administrative staff shall receive training. The need for training users from different areas of the system is fairly obvious.

Training will be of two types:

• Administrator Specific
• Developer Specific
• User Specific

Training activity has been explained in detail in the Implementation Schedule.

Acceptance signoff is an important phase in the Project Life cycle. Acceptance signoff shall take place after the activities explained below are completed.

User acceptance testing shall be completed at the client site. Any defects reported shall be tracked and resolved. New version of the application shall be released after the fixes are completed and accepted by the client. User acceptance testing signoff shall be received from the client. Any defects reported shall be tracked and resolved. New version of the application shall be released after the fixes are completed and accepted by the client.

The acceptance test will be carried out by the client for the delivered system or part thereof through the test cases and the normal operations of the system. The following components will be submitted for the acceptance test:

• Acceptance Criteria
• Test Cases

User level and Administrator training shall be conducted at the client site giving an in-depth know-how of the system Thus completing the knowledge transfer to the client. The training material shall consist of transparencies and detailed documentation.

User feedback shall be taken about the New System and the training provided. Any acceptable changes in the training documentation needed shall be provided.

After the completion of implementation, User Acceptance testing and Training Signoff from the client shall be obtained. This marks the completion of development, implementation and Training for the system. The following components will be complied with for the acceptance procedure as specified:

• Installation Test
• Acceptance Test

Installation test shall be completed at the client site in accordance with the agreed test program and the test plans.

User acceptance testing shall have been cleared. Any defects reported shall have been tracked and resolved.

System support shall be provided during the Warranty period. Any defects found shall be Logged and rectified. The warranty period shall be for a period of 6 months after the Acceptance date.

The System Development will be based upon following assumptions:

• The complete information of the existing system and additional requirements will be provided.
• The modules/components requiring enhancement are currently functional/operational