CC BY
43
Section 16. Economics and management
Kopani Xhevdet,
Agricultural University of Tirana, PHD in process, Faculty of Economics General Manager of "Eurosig" Sha Company, Tirane-Albania E-mail: [email protected]
Quality, risk and acceptance plan of the project, significant factors in its success
Abstract: "Quality" can be defined as the extent to which the final result matches the customer's requirements. Quality generally is considered from two different perspectives: the quality of each result produced for the client and quality of management processes undertaken to produce each result. For this reason a quality plan does not only define the approach taken to ensure the level of quality for each result, but also the management processes required to influence the quality of the outcome, such as change, risk and management of problems.
A risk plan lists all the anticipated risks of the project and presents some of the actions required to prevent any risk from happening and to reduce its impact if it happens. "Acceptance" is defined as getting approval from the client that the results produced from the project, meet the criteria set by the client. These criteria relate to the quality and cost of results and also the deadlines within which they are produced and can relate to the entire range of proj ects in industry, agriculture, services, infrastructure etc.
Keywords: project, quality, risk, acceptance, acceptance, client, analysis, impact, target.
Quality plan The first step towards the development of a comprehensive
To create a quality plan, the following steps are taken: quality plan is to identify and control the quality of the results within
• Determine the term «quality» in relation to the project un- the project. To do this, we need to define the term «quality», to dertaken; determine quality objectives and to list quality assurance and qual-
• Identify the quality objectives to be met; ity control activities.
• Describe the quality assurance and control techniques that To ensure that there is a continuing sense of the term «quality» must be undertaken; within the project, the term quality should be formally defined as
• Define the processes required to achieve specified quality follows:
targets. Quality is the extent to which the final result matches the cus-
A quality plan is established during the planning phase of the tomer's requirements. project after the identification of the project plan, resource plan and Quality objectives
financial plan. Since quality plan summarizes the quality objectives For each requremnet and result of the project, quality objectives
to be met and management processes to be undertaken, it is a refer- are identified, so that, once completed will ensure that the outcome ence throughout the whole project. meets the customer's requirements. See table 1 as an example.
Tablel. - Quality Objectives
Project requrements Project results Quality criteria Quality standarts
The new settlement of financial management with collectable accounts and structured processes payable. Implementation of Oracle financial books, payable accounts and collectable accounts and system modules. The functionality of the system: • Oracle tested and installed • Tested and installed equipment • tested and installed equipment and System performance: • development of the system • time response of the system • migrate data from the old system. Functionality of the system: • operational Oracle with no errors • Equipment operating without any error • Equipment operating without any error System performance: • 99.9% the system with good performance • 5 seconds response time • 100% data accuracy.
Quality assurance plan
To ensure the client that quality objectives specified above will be met, quality assurance techniques (QA) must be defined.
Quality assurance techniques are preventive steps taken to eliminate any deviation from the quality of the results produced by the established quality objectives. Quality assurance is often undertaken in a project summary level by an external source of the
project. Examples of techniques used to ensure the quality of the results include:
• Review of historical data: the meaning of other projects related to the project (or that are being carried out or have been completed recently) and quality issues encountered by these projects will make it possible for the quality manager to identify potential quality issues within the project;
• Definition of requirements: by documenting a comprehensive range of customer requirements, a greater understanding of the level of required quality of results will be gained in order to achieve total customer satisfaction;
• Definition of standards: by defining a set of criteria and specific quality standards, the project team will clearly understand the level of quality which will be achieved;
• Recruitment of qualified staff: using qualified staff will directly influence the quality of produced results. Properly qualified staff will have the knowledge, skills and experience required to undertake given tasks in the project plan with minimal training, to achieve the desired level of quality;
• Conduct of quality reviews: independent reviews to assess the overall quality of each result can give the client confidence that the project is on track and is likely to produce a result that meets the requirement;
• Implementation of change control: changes in the subject often have an effect on the level of quality provided. Through the identification of a clear process of change control, only the changes that are absolutely necessary will be approved by the project for implementation.
Table2 identifies the techniques required to ensure the customer that quality objectives will be met.
Table 2. - Quality Assurance plan
Technique Description Frequency
Recruit qualified staff We will recruit qualified staff to ensure the quality of results by means of: • Ensuring that staff allocated to the project has at least 3 months of trading experience in similar projects within this field of business; • Appointment of two major managers from existing businesses who understand the business requirements in details; • Appointment of two technical consultants to ensure that the results of this project technology meet the quality objectives. Throughout the whole project
Conduct quality reviews We will review the quality of results through: • Appointment of an independent specialist to conduct monthly quality reviews for all key results of the project; • Appointment of quality project manager who is responsible for the quality of results produced by the project. Each month.
Quality control plan
Besides undertaking quality assurance to improve the quality of the result, several techniques of quality control (QC) can be implemented. QC techniques are often undertaken at a detailed level of the project from an internal source of the project. Types of techniques used to "control" the quality of the results are:
• Reviews of everyone's work: the process of requiring by members of the project team to review the work of each is known to increase the level of quality of the results. It will also make it possible to identify quality problems earlier in the execution phase of the project and therefore will increase the likelihood of quality problems to be solved earlier;
• Reviews of the result: internal staff ofthe project can undertake formal planned reviews of the results, to ensure that they meet customer requirements;
• Reviews of documentation: Similar with reviews of the result, this process involves a review of all project documentation at regularly scheduled intervals planned in the project;
• Phase reviews: these are formal reviews at the end of each major phase of the project to evaluate the activities and results completed by this time and to get approval from the project sponsor to continue with the next phase of the project.
Table 3 provides an example of identifying the QC techniques that will be implemented to control the quality of each result in the project.
Table 3. - Quality Control Plan
Technique Description Frequency
Review of everyone's work Implement the following policy to review the work of each member of staff: • A team leader will be responsible for each project result. • To each team leader will be given a "counterpart" for the leadership of the team for counterpartss reviews. • Team leaders will formally review each week the results of his counterpart. • Team leaders will document the results of each review of the counterparts using a quality review form. • The Quality Manager will review the process of reviewing counterparts regularly to ensure that reviews of counterparts are undertaken regularly. Every week, throughout the project
Phase reviews. Implement stage reviews: • At the end of each of phase of the project a formal phase review will be undertaken. This review will bring receipt of acceptance from the project sponsor that the project has reached its objectives by that time and can progress towards the next phase of the project. • To start a phase review, the project manager will complete a phase review form and submit it to the project review council for evaluation and approval. At the end of each important phase of the project.
Besides describing how to ensure quality of each result produced for the client, we must also describe how to ensure quality of management processes undertaken to produce each result. For each
of the following processes, the steps involved in the undertaking of the process and the responsibilities of the source responsible for process managing are described:
• Time management process;
• Cost management process;
• Quality management process;
• Change management process;
• Risk management Process;
• Problems management process;
• Procurement management process;
• Acceptance management proces;s
• Communication management process.
Risk plan of the project
A comprehensive risk plan includes:
• A list of anticipated project risks;
• Assessing the possibility for each risk to occur;
• A description of the impact on the project if a risk actually occurs;
• Estimates of the overall importance of each risk;
• Some preventive actions to be taken in order to reduce the possibility of a risk to occure;
• Several contingency actions to be taken in order to reduce the impact if the risk if it occurs;
• Risk management process throughout the proj ect.
The risk plan should be documented in the planning phase of the project to ensure that risks are mitigated before the project execution. Shortly after the risk plan is documented, the risk management process begins to be monitored and risks of control are identified within the project. Risk management process is interrupted only when the execution phase of the project is completed.
The first step toward creating a risk plan is to identify any risk that might otherwise affect the ability of the project to achieve its set objectives. Some risk categories are listed and for each category, several potential risks are identified. A seminar on risk planning can
be undertaken to help key shareholders of the project to identify project risks. This could include the project sponsor, the project manager, project team, suppliers and in some cases the client. Each risk identified is defined and documented in detail in the risk plan.
To ensure that there is a constant meaning of the term «risk» in the project, it will be necessary to formally define the term as follows:
A risk is an event that is likely to negatively affect the project's ability to achieve the established objectives.
Possible categories of risk for this project are identified. A risk category is a particular aspect of the project that is likely to experience a risk during the course of the project. Typical risk categories are:
• Requirements of the project;
• Potential benefits of the project;
• Deadline for the project completion;
• The budget for the project implementation;
• Expected results of the project;
• Scope of the project, its precise definition;
• Identified problems and their solution;
• The supplier or suppliers to be contracted for the provision of goods and services;
• Acceptance of goods and services;
• Communication between the project implementation participants, sponsors, suppliers etc;
• Available resources, mainly human resources, equipment, etc.
For some of the major risk categories identified above, the potential risks were described, by completing Table 4. Where, for each of the listed risk, a unique identification number (ID/No.) should be established for future reference.
Risk Category Description of risk Nr./ID of risk
1 2 3
Requrements • Requirements are not clearly specified. • Specified requirements do not match the client's needs. • Specified requirements are not measurable. 1.1 1.2 1.3
Benefits • The business benefits are not identified. • The business benefits are not expressed in quantity. • The final solution provided fails to reach the requred benefits. 2.1 2.2 2.3
Deadlines • The deadline does not give enough time to complete the project. • The deadline does not list all the activities and tasks required. • The deadline does not correct dependencies. 3.1 3.2 3.3
Budget • The project exceeds the budget allocated • There is an expense in the project not included in the accounts. • There are not responsible sources for the registration of project expenses. 4.1 4.2 4.3
Results • Requested results from the project are not clearly defined. • Quality criteria for each result are not clearly defined • Produced results don't meet the defined quality criteria. 5.1 5.2 5.3
Scope • The scope of project is not clearly defined. • The project has not been undertaken within the scope of which has been agreed. • Changes to the project adversely affect the project. 6.1 6.2 6.3
Problems • Project Problems are not solved within a convenient time. • Similar problems continually reappear throughout the project • Unresolved problems become new risks in the project. 7.1 7.2 7.3
Suppliers • Expectations for the delivery from the supplier have not been determined. • Suppliers do not meet the set expectations. • Procurement delays affect the timeliness of the project delivery. 8.1 8.2 8.3
Table 4. - Risk List
1 2 3
Acceptance • Criteria for acceptance of the project results are not clearly defined. • Clients do not accept the final results of the project. • The acceptance process leaves the client unsatisfied. 9.1 9.2 9.3
Communication • Lack of controled communication causes problems to the project. • Key shareholders of the project are not informed of the progress. 10.1 10.2
Resources. • Staff allocated to the project is not appropriately qualified. • There is insufficient equipment to undertake the project. • There is a lack of available materials when required. 11.1 11.2 11.3
The next step is to assess the possibility of any impact of each must be accomplished. To our help comes table 5 used to measure risk if it occurs. For this reason a quantitative expression of risks the possibility of occurrence for each risk.
Table 5. - Probability of risk
Title Points Description
Very low 20 There is no possibility of occurrence based on current information, because the circumstances that could cause risks are unlikely to occur.
Low 40 Unlikely to happen. However it should be monitored as certain circumstances could lead to the risk of becoming a potential occurrence during the project.
Medium 60 Likely to happen since it is clear that the risk can occur.
High 80 More likely to occur, based on the circumstances of the project.
Very High 100 Most likely to happen because the circumstances that would make this risk to occur, is also most likely to occur.
It is important that in addition to the possibilities of occurrence, Table 6 creates a rating system used to measure the "impact" of each the impact that each risk will have in the project is also measured. risk if it occurs.
Table 6. - Impact of Risk
Title Points Description
Very Low 20 Insignificant impacts on the project. It is not possible to measure the impact on the project because it is so minimal.
Low 40 Small impact on the project. It results in less than 5 percent of the deviations in the object, the completion deadline of the project or budget.
Medium 60 Measurable impact on the project. Results in 5-10 percent deviation of the results in the object, the completion deadline or project budget.
High 80 Significant impact on the project. 10-25 percent deviation of the results in the object, deadlines or project budget.
Very High 100 Great impact on the project, resulting in a deviation of more than 25 percent to the object, a deadline or in the project budget.
For the risk assessment of the project, after we have calculated the possibility and impact we estimate the priority for each risk, by indicating the points of priority based on the number of risk.
Priority pointss can be calculated as the average of possibility of occurrence with the impact scores, divided by 2.
Priority points = (possibility+ Impact)/2. Table 7 presents the calculation of points and assessment under the pointss resulted. For nearly 50 points, the evaluation is medium, over 50 points high, over 80 points very high, less than 50 points low.
Table 7. - Risk Priority
Nr./Id of Risk Possibility Impact Priority Assesment
1.1 20 80 50 Medium
1.2 80 60 70 High
1.3 100 40 70 High
2.1 40 20 30 Low
2.2 90 100 95 Very High
2.3 20 80 50 Medium
After performing the priority assessment, Table 8 is used to to each assesment: determine the assessment and to assign an appropriate color code
Quality, risk and acceptance plan of the project, significant factors in its success Table 8. - Assesment of risk priority
Priority points Priority assessment Priority colour
0-20 Very Low White
21-40 Low Green
41-60 Medium Yellow
61-80 High Orange
81-100 Very High Red
For each identified risk, we list the preventive actions required to reduce the possibility of occurrence of risk and contingent actions needed to reduce operations in the project, if the risk occurs..Against each action, we assign a resource that is responsible for taking acTable 9. -
tion and the date within which action must be completed. Table 9 is used to merge this information. This table should be completed for each identified risk. To risks of highest priority should be given the most comprehensive actions where possible.
Table of risk
Estimation No. Of risk preventive actions Source of Action Action Date Source of Action
Very High 2.2 Clearly identify the expected business benefits Project sponsor Contingency actions. Measure the actual business benefits achieved by the project Project Manager
High 1.2 Clearly specify client requirements in terms of quality Project Manager We asses the requirements after they produce results, measure any deviation and increase results to meet the reqire-ments. Project Manager
High 1.3 Clearly specify the quality criteria used to determine whether the stated requirements for each result are met. Quality Manager Estimate the quality criteria after the result is produced, measure any deviation and increase results to meet the established quality criteria. Quality Manager
Table 10.
Risks analysis focuses on the analysis of key stakeholders and the environment in which the project takes place.
It is important to analyze one by one the stakeholders participating directly and indirectly in the projects and that may be:
• Customers, Executive Board, project manager, project team, Controllers, end-users, employees, heads of departments, Media, interested persons, activists, authorities, suppliers, sponsors etc.
It is also important the analysis and evaluation of and social and factual environment, which might be:
Social environment Factual environment
Client The technology
Owner Knowledge
Directory Budget
The project team Strategy
Project leader Market Development
Employees Weather
Suppliers Environment
Partners parallel activities
The public Laws
Competitors Status of resources
Family
The analysis can take place as following in a tabular order
Table 11. - Analysis of the Social environment
No. Pressure group The attitude towards the project (—/0/+) Force of influence (1/2/3) What interest groups expect Fear of groups Measures
Table 12. - Analysis of the actual environment
No. Influencing factors Influence to project (-/0/+) Force of influence (1/2/3) Impact on the project Measures
A method of managing risks is FMEA (Failure mode and effects analysis). Schematically this method may appear:
Table 13. - FMEA
Work package Risk Consequences Probability of occurrence (1-10) a The effect on the project (1-10) b Change of Impact (1-10) c Risk Index (Axbxc) Measures
Draughting ofthe acceptance plan.
The acceptance plan includes:
• A list of key milestones to be achieved and results to be produced;
• Some criteria and standards for acceptance of the results by the client;
• A plan that describes how the results will be reviewed to determine whether or not they meet the criteria and standards set by the client;
• The process of obtaining customer approval, after the results are produced.
The acceptance Plan is an important document in the project. Usually it is built towards the end of the planning phase of the project after the project plan, resource plan, financial plan, qual-
Table 14. - Main stages of acceptance
ity plan and risk management plan are documented. Acceptance Plan is identified throughout the execution phase since it is used to confirm that each produced result is complete and ready for acceptance by the customer. It is also addressed during the closing phase of the project as part of the project closure report and post-implementation review.
To ensure that there is a constant sense of the term «acceptance» within the project, we should normally define the term of acceptance. We define acceptance as following:
Acceptance is defined as getting approval from the client that the results produced by the project meet the criteria set by the client.
According to the main stages of the project, the results of which the client's acceptance is required are listed in the example of Ta-ble14. As follows:
Name Description Result Name
Update of the financial system Implementation of the software package on the new hardware Software packages installed Description, implementation of the ledger (Oracle), accounts payable (equipment) and software of collectable accounts
It is important at this stage to identify the criteria and standards this purpose we can rely in table15 as follows: that must be met to achieve customer acceptance for each result. For
Table 15. - Acceptance Criteria:
Result Criteria Standarts
Software packages installed Functionality of the system: Oracle tested and installed Tested and installed Equipment tested and installed, Software tested and installed. System performance: The system in operation System reaction time Functionality of the system: Oracle operating without errors Operational equipment without errors Software operating without errors System performance: 99.9% system working Less than 1 second from response time Data transferred 100%, data accuracy.
Criteria and standards listed above have to convince the client • Timely conduct of results and processes;
that the results produced can be measured adequately and that all • The ability of the project to produce results within the budget.
requirements are met. Although the criteria listed mostly explain Create a board of review needed to ensure that the results pro-
quality of "results", other types of criteria can be used, such as: duced by the project meet the criteria and standards already estab-
• Quality of new processes allocated by the project; lished. An example is shown in Table 16.
Table 16. - Acceptance Table
Main stages of completion Result Date Review Method Reviewers
The financial system updated. Software package installed. physical inspection. Software Testing. Review of accuracy. Systems tester Project Manager Manager of Data Quality Customer's lawyer. Independent Consultant.
• Completion date is the scheduled date on which the result will • Reviewers are people who in collaboration with eachother try be 100% complete and ready for customer acceptance. to conduct the review.
• Review method is the technique used to assess whether the • Accetance date is the date set for the acceptance of results quality criteria are met or not. from the client, after completing the acceptance review.
Possible assumptions made during acceptance planning exercise could be:
• There will be no changes in project requirements during the project;
• Acceptance criteria will not change during this project;
• The reviewers will be available to conduct reviews as required.
Risks identified during this planning exercise can be listed:
• acceptance criteria can not be directly compatible with the requirements of the client;
• Acceptance reviews carried out may not provide adequate confidence that the results meet the acceptance criteria listed above;
• Resource assigned to conduct the acceptance review can be not properly qualified to carry out each review as required.
References:
1. Project Management -Dynact Management Consulting -Aleksander Kagi.
2. Project Management -Manfred Strohmaier.
3. Quaity Management -Matthias Zacharnik.
4. Alston, J. M., M. C. Marra, P. G. Pardey, and T. J. Wyatt. 1999. "Research Returns Redux: A Meta-Analysis of the Returns to Agricultural R&D." EPTD Discussion Paper No. 38. International Food Policy Research Institute, Washington, DC.
5. Alston, J. M., G. W. Norton, and P. G. Pardey. 1995 Science Under Scarcity: Principles and Practice for Agricultural Research Evaluation and Priority Setting. Ithaca, NY: Cornell University Press.
6. Belli, P., J. Anderson, H. Barnum, J. Dixon, and J. P. Tan. 1998. Handbook on Economic Analysis of Investment Operations. Operations Core Services Network, Learning and Leadership Center, The World Bank, Washington, DC.
7. Byerlee, D., and G. Alex. 1998. "Strengthening National Agricultural Research Systems: Policy Issues and Good Practice." ESSD, The World Bank, Washington, DC.
8. Horton, D., P. Bellantyne, W. Peterson, B. Uribe, D. Gapasin, and K. Sheridan. 1993. Monitor-ing and Evaluating Agricultural Research: ASourcebook.CAB International, Wallingford.
