Quality Assurance PlanTypical Risk Controls Risks associated with projects can be eased or allayed by the existence of controls. Controls can have an effect on risks ranging from little or no effect to one of significant reliability. Controls may prevent risks from developing within a project; they may detect the existence of risks; they may correct or alleviate risks. Contractor Failure: A contractor or third party should be capable of delivering services and products on a timely basis. The service or product must be of acceptable quality to assure project success. The service or product should comply with industry standards as appropriate. Contracts should be comprehensive and clear. Schedules, commitments, and responsibilities of each party should be specified. The contractor should use accepted methodologies. The contractor should be bondable and insurable as necessary to assure project success. Current/Recent Litigation Against Vendor: A review of current or recent litigation against a vendor or contractor should be performed in order to assure satisfactory performance history and establish a basis for business continuity. Litigation can indicate current or future financial problems and it can give evidence toward a contractor's ability to perform through the conclusion of a project. Descriptions & Justifications Ambiguous or Nonexistent: The project design should be developed using clear, concise descriptions of processes, services, or products that will facilitate communications. Fuzzy descriptions will cause confusion. Specific justifications and characteristics that are important to the project should be well defined. Failure to Use Established Methodology: Design and implementation of the project should make use of an established methodology to assure consistency and uniformity. Project team members trained in and competent in the use of a given methodology have a common basis for communicating and coordinating project efforts. Ineffective Organization and Management: The project should have firm and effective commitment and sponsorship from appropriate administrative levels. Management support should include proper prioritization, required staffing levels, and commitment of necessary resources. Management should be involved in the project and review the status on a periodic basis making necessary staffing, timing, and resource adjustments. Management should assure assembly of a capable project team. Insufficient and Untrained Staff: Appropriate numbers of staff with relevant job skills should be identified and assigned to the project. Scheduling and other delays related to hiring of skilled staff and/or training of staff must be accounted for. Lack of proper training or specialization may result in increased errors and rework efforts. Retention of staff and contract personnel through the project duration must be considered. Insufficient/Inadequate Design: The Project design should address all major issues. Oversimplification, excessive complexity, inappropriate design, or other factors that might contribute to the need to redesign and re-implement the project should be avoided. Unfamiliar methodologies or processes should be avoided. Insufficient Contractor Schedule and Resources: A contractor or third party vendor must be capable of scheduling and prioritizing resources to assure timely delivery of service and/or product for the project. The contractor should not be obviously over-committed and the contractor should have a good work history. Insufficient Control of Project Requirements: A methodology should be utilized to manage and control change to the project's requirements. Requirements should not be expanded without proper review and approval of management to assure the requirement change is necessary. No Change Management Process: Projects are dynamic by nature and they are comprised of many variables. Project objectives and timelines may be altered when project requirements are changed due to technology, regulatory, or general discretionary factors. A change management structure should be implemented in order to evaluate changes as they arise and to determine whether such changes should be implemented within the scope of the project. Appropriate administrator review and approval of changes can keep the project focused on its goals and timelines. Failure to control change may result in a failed project. No Project Guidelines Are Established: Projects should be structured and conducted in a rational, practical manner that leads to the accomplishment of project goals. Guidelines related to all aspects of the project should be developed and utilized in order to assure uniformity and consistency of processes and tasks within the project. Guidelines should minimize ambiguities and uncertainties. Guidelines can be very detailed or they can be general, depending on the magnitude and complexity of the project. No Requirement/Design Change Approvals: A management process should be in place to review changes that occur with respect to requirements, design, implementation, or other aspects of the project. Changes should be justified. Changes should be subjected to management review. Changes should be approved by those people managing the project and by those people sponsoring the project. Approvals provide evidence that potential schedule changes that result from design or requirements changes are acceptable. No Testing and Acceptance Methodology: Whenever appropriate, a testing methodology should be established in order to assure that all critical processes and equipment function in accordance with project requirements. A test plan should be developed that identifies those components to be tested, specifies test processes and methods, and provides measurable outcomes. Appropriate administrators and users should formally accept test results and ultimately they should accept delivery of the project based on satisfactory test results. Failure to use an appropriate methodology will allow the project to be essentially uncontrolled and uncontrollable. Other Risks: Each project is unique and dynamic and they assume various degrees of individuality. Consequently projects should be evaluated for additional risks that may be specifically relevant to it. These risks should be included in risk assessments as appropriate within the judgment of management. Overly Optimistic Schedules: Schedules developed based on unfounded desires rather than a solid practical basis considering all relevant factors. Necessary tasks should not be omitted or minimized. Poor Documentation and No Standards: Projects should be properly documented in accordance with relevant rules and regulations and with good management practices. Project documentation establishes management trails relating to the development and definition of the project, related decisions, job tasks, changes and modifications, authorizations and approvals. Standards for types and quantities of project documentation should be established and the standards should be generally applicable to all types of projects. The degree of documentation will usually depend on the size and complexity of the project. Poor Financial Stability: A vendor with poor financial standing and stability represents a significant risk to successful completion of a project. Whenever appropriate, a vendor should be required to present financial statements and other documentation and certification of stable financial status. The unexpected bankruptcy of a vendor can halt a project and may result in the loss of all resources invested into the project. Poor Function Modularization: The project should be designed to properly modularize functions. This will assist in clear definition of responsibilities and project milestones. Modularization will facilitate go/no go decision-making. Poor modularization will contribute to fuzzy project functional definitions, blurring specific tasks and job assignments. Accountability may become excessively vague. Poor or No Status Reporting: A project status reporting process should be implemented and applied for active projects. Status reporting will assure administrators and decision-makers receive necessary information on a timely basis to assess the project’s status and alter priorities, resources, or timelines when necessary. A project’s opportunity for success is severely jeopardized if no status reporting mechanism exists. Poor Product/Service Quality: Quality of delivered products or services should be enhanced through good design techniques, testing, and error detection and correction. Compatibility with existing systems or processes may require stringent testing beyond levels expected for stand-alone systems or processes. Poor Vendor Selection Process: Failure to utilize a logical and practical approach for the selection of a vendor or other third party to provide products or services for a project can jeopardize the entire project. The selection process should be rational and it should be documented. Competent vendors should be given opportunities to bid or participate in the project. Logical and defendable criteria should be used to assess each vendor and enable selection of the best vendor. Poorly Defined Function Limits: Fuzzy or vague function boundaries make modularization of functions difficult adversely affecting the ability to assign responsibility and establish accountability for project tasks. Function limits should be clear and documented. Poorly Defined Measures of Accomplishment: Project milestones should be clearly identified. Completion of project tasks and phases should be unambiguous. Poorly Defined Project Priority: The priority must be well defined and supported by appropriate administrative levels. Assignment of staff and use of resources should be clear. Relationship to other projects and tasks should be defined in early planning stages. Poorly defined priorities create confusion and ambiguity with respect to staff work efforts and job assignments. Important project efforts could be preempted by minor job assignments because of poor prioritization. Poorly Defined Requirements: Requirements should not be artificially inflated. Requirements should not be allowed to creep beyond scope of project. Requirements should be accurate, complete, and unambiguous. Requirements should be capable of testing whenever possible with measurable results to assure compliance. Prerequisites Not Identified or Accomplished: Prerequisite resource acquisitions and tasks must be identified and accomplished in order for the project to be completed on a timely basis. Failure to identify a prerequisite task will delay accomplishment of those tasks dependent on it and this delay could likely cascade throughout the project producing adverse effects far beyond the significance of the original prerequisite. Schedule Creation Methodology not used: Project schedules should be created using appropriate and accepted methodologies, techniques, and tools. Lack of a logical approach to schedule creation can result in wild guesses that have no practical basis for success. Uncontrollable External Factors: This category can include federal, state, or local rules or regulations that can change with little forewarning. Significant technology changes for computer hardware of software provided by vendors may also be factors. Uncontrolled/Unmanaged Human Factors: Various human factors can adversely influence the success of the project. These can include poor relationships between various individuals or groups, poor training, poorly defined responsibilities, poor communication, low motivation, low morale, etc. Training and retention can become issues. Staff receiving specialized training may find more lucrative employment options elsewhere. Unrealistic Expectations: Project deliverables should be based on realistic and accomplishable projections based on commitment, resource availability, and staffing levels and capabilities. Unsatisfactory Vendor Performance History: A vendor that has an unsatisfactory history of performance will significantly jeopardize a project and greatly increase the risk that the project will be unsuccessful. Vendor work histories should be reviewed and evaluated. References should be asked for and checked to assure satisfactory performance. Vague Contract Requirements: Contracts should be clear with requirements and responsibilities specifically defined. Contracts with vague and ambiguous requirements may confuse project efforts and result in the delivery of unacceptable products or services. Vague contracts may be unenforceable with respect to performance. Specifically, if the end product or service delivered is not that which was expected with appropriate quality, there may be no legal recourse to enforce satisfactory performance when contract requirements are not specific. | |||