1.1. The AECF is a leading development finance organisation that supports businesses to innovate, create jobs and leverage investments in order to create resilience and sustainable incomes in rural and marginalized communities in Africa.
1.2. Since 2008, AECF has invested in 292 businesses across more than 40 value chains in 26 sub-Saharan Africa countries focusing on agribusiness, renewable energy and climate technologies, while also addressing the cross-cutting themes of gender, youth and fragile contexts. The AECF has impacted more than 27.7 million lives, created close to 24,000 jobs, and leveraged over US $740 million in matching funds from the private sector.
The AECF is headquartered in Kenya with offices in Cote d’ Ivoire and Tanzania.
2.1. Through this request for proposals (“RFP”), the Internal Audit Unit of The AECF is seeking a technology solution to their current manual processes for audit planning, scheduling, execution, management, reporting and follow-up needs.
2.2. The Internal Audit Unit requires a fully functional solution. The vendor will be required to provide training on the proposed system as well as on-going support and service including system upgrades, fixes, and enhancements. The proposal will encompass all requirements to automate the audit process including electronic work papers, reporting, issue tracking, project scheduling, timekeeping, risk assessment, and a documentation library.
2.4. The AECF may, at its discretion, cancel the requirement in part or in whole. It also reserves the right to accept or reject any proposal and to annul the selection process and reject all proposals at any time prior to selection, without thereby incurring any liability to proposers/firms.
2.5. Proposers may withdraw the proposal after submission provided that written notice of withdrawal is received by the AECF prior to the deadline prescribed for submission of proposals. No proposal may be modified subsequent to the deadline for submission of proposals. No proposal may be withdrawn in the interval between the deadline for submission of proposals and the expiration of the period of proposal validity.
2.6. All proposals shall remain valid and open for acceptance for a period of 180 calendar days after the date specified for receipt of proposals. A proposal valid for a shorter period may be rejected. In exceptional circumstances, the AECF may solicit the proposer’s consent to an extension of the period of validity. The request and the responses thereto shall be made in writing.
2.7. Effective with the release of this solicitation, all communications must be directed only to the Procurement department by email at firstname.lastname@example.org. Proposers must not communicate with any other person of the AECF regarding this RFP.
3.1. Award will be made to one Proposer. Award will be made to the highest ranked, responsive and responsible Proposer whose proposal is determined to be the most advantageous to The AECF. The service contract will be based on the initial product cost, licenses, maintenance fee, and professional services for training and implementation.
4. REQUEST FOR CLARIFICATION OF RFP DOCUMENTS
4.1. A prospective proposer requiring any clarification of the solicitation documents may notify the AECF in writing via the email address email@example.com by 22nd February 2021. The AECF will respond in writing to any request for clarification of the solicitation documents that it receives by the due date. Written copies of The AECF response including an explanation of the query but without identifying the source of inquiry will be posted on The AECF website.
5. AMENDMENTS TO RFP DOCUMENTS
5.1. At any time prior to the deadline for submission of proposals, The AECF may, for any reason, whether at its own initiative or in response to a clarification requested by a prospective proposer, modify the RFP documents by amendment. All amendments will also be posted on The AECF website in the “Work with Us” section.
6. LANGUAGE OF PROPOSALS
6.1. The proposals prepared by the proposer and all correspondence and documents relating to the proposal exchanged by the proposer and the AECF, shall be written in English.
7. SUBMISSION OF PROPOSALS
7.1. Proposers shall submit their proposal in soft copy via email firstname.lastname@example.org.
7.2. Technical and Financial proposals must be submitted in separate documents and with clear subject description of the proposal (technical or financial) by the date and time stipulated.
7.3. Proposals must be sent ONLY to the address provided above. Proposals sent to any other addresses will be rejected.
7.4. The Financial proposals shall include all applicable taxes quoted separately. If taxes are not mentioned in the financial proposal, The AECF shall consider that they are included in the prices provided. Applicants are advised to ensure that they have a clear understanding of their tax position with regards to provisions of Kenya tax legislation when developing their proposals.
7.5. The financial proposal shall include implementation costs, license costs & expected recurrent costs for at least the first 3 years.
8. LATE PROPOSALS
8.1. Any proposals received by the AECF after the deadline for submission of proposals will be rejected.
9. CONFLICT OF INTEREST
9.1. In their proposal, proposers must confirm that, based on their current best knowledge, there are no real or potential conflicts of interest involved in rendering Services to the AECF.
10.1. Information relating to the evaluation of proposals and recommendations concerning selection of Firms will not be disclosed to Firms that submitted proposals.
11.1. AECF reserves the right to determine the structure of the process, number of short-listed participants, the right to withdraw from the proposal process, the right to change this timetable at any time without notice and reserves the right to withdraw this tender at any time, without prior notice and without liability to compensate and/or reimburse any party.
STATEMENT OF WORK
A. BACKGROUND AND PURPOSE
1.1. The AECF Internal Audit Unit requires the Audit Management System to provide all functions described in this RFP as a fully integrated solution and may not consider proposals suggesting a combination of various modules that individually address the requirements.
1.2. The Internal Audit Unit seeks to leverage a new technology solution to help facilitate standardized work paper documentation methodology across the entire audit staff.
1.3. Internal Audit provides the AECF’s Board and Management Team with objective, accurate and meaningful information regarding The AECF’s operations and, where necessary, makes recommendations for improving compliance, operational efficiency and controls, cost savings, information technology, security, and other areas as needed to minimize risks.
1.4. The risk universe consists of The AECF’s internal processes such as procurement, finance, human resources, risk management, portfolio process etc. as well as donor/funder programs, investees (AECF’s investments in grants and repayable loans), investigations and special audit assignments as and when directed by The AECF’s board.
1.5. Currently, a team of two (2) employees perform audits using manual processes and electronic workpapers (Microsoft Office) format. Automated software is not currently available. Productivity software (Microsoft Office), phone calls, e-mails, paper-evidence and in-person meetings are the methods of data collection and management.
1.6. Storage of outputs, including final Audit Reports, is accomplished via storage on the local machine hard-drive and on The AECF’s shared drive folder (Microsoft SharePoint). Formalized access control security is in place for the current storage systems to ensure unauthorized personnel do not have access to the data.
1.7. Annual Audit Plan – An audit plan is prepared using risk assessment techniques applied to the entire population or universe of programs or departmental processes for The AECF. The plan takes into consideration known changes in personnel in key positions as well as upcoming changes in laws and regulations. Interim changes to the plan will occur from time to time due to changes in business risk, local and regulatory mandates, and staff availability.
1.8. Scheduling and Assignment – Scheduling is primarily driven by the annual internal audit workplan. Additionally, information received from outside sources about alleged wrong doing or other significant changes will trigger a special project/audit.
1.9. Audit Execution, Fieldwork, and Reporting – Audit execution contains three phases: 1) planning, 2) fieldwork, and 3) reporting. Once planned, an auditor will be assigned to an audit project. Audit execution begins with project planning and the auditor will assess risk and significance within the context of the audit objective.
1.10. The auditor will prepare a written Audit Program to test relevant controls or compliance requirements identified during the planning phase to collect data/information used to draw conclusions. Audit work papers are generally the primary output of fieldwork performed by an auditor and retained in accordance with paperwork retention policies.
1.11. Audit Reporting – Audit reports are the documents presented to the investee companies, AECF management and Board.
1.12. Follow-up and Tracking – The tracking of implementation of recommendations and agreed actions is done. A report on the progress is generated on a monthly basis to Management and Quarterly to the Board.
1.13. Document retention – All documents supporting or related to an internal audit must be retained in accordance with The AECF’s document retention policy.
1.14. Resource and Workflow Management and Administrative Reporting – The tracking and management of these assignments and schedules is currently done manually using Microsoft Excel.
B. GENERAL SCOPE OF WORK
The scope of work primarily consists of five elements as follows:
a) Supply, implementation and installation of audit management software with 3 years of maintenance after the implementation project.
b) Advice on installation and commissioning of appropriate platform & supporting software, network links, in association with The AECF’s service providers. A cloud solution will be preferred.
c) Setting up of the necessary ICT infrastructure and application support function with minimum requirements delivering a performance level and availability requirement suitable for AECF.
d) Implementation services including application installation, custom development, data conversion and migration, training and change management, documentation, fitting the solution’s specific customer support arrangement and warranty services.
e) Optional, on-demand support services, especially for the time period beyond implementation project closure.
Any specification in this section labeled as “MUST” is a requirement of this RFP.
1.1. The solution MUST have role-based security.
1.2. The solution MUST allow a local administrator to set permissions for licensed users.
1.3. The solution MUST allow users with the appropriate permission level to update or modify/correct data.
1.4. The solution MUST provide the ability to record and store information associated with each audit project, including all supporting audit work papers.
1.5. The solution MUST provide a means or method by which users can easily determine when an audit was last performed.
1.6. The solution MUST provide the ability to assign specific audit step(s) to individual auditor(s).
1.7. The solution MUST provide two-way cross referencing between documents, and support point-to-point hyperlinks for Word, Excel, PowerPoint and PDF files.
1.8. The solution MUST provide the ability for individual sign-off by reviewers and management.
1.9. The solution MUST support the ability to print completed work papers, review notes, and audit programs, and other electronic documentation created within the system.
1.10. The solution MUST provide the ability to document and resolve review notes.
1.11. The solution MUST provide the ability to view audit trail or history of changes made upon request.
1.12. The solution MUST provide search capabilities within audit findings, projects, and the document library.
1.13. The vendor MUST provide notification when the solution is no longer supported and is at the end of its useful life.
1.14. The vendor MUST provide improvements to the acquired product via updated versions throughout the useful life of the solution.
1.15. The solution SHOULD support workflow and task assignment needs.
1.16. The solution MUST provide users with the ability to add or delete audit steps to an existing audit program.
1.17. The solution MUST manage, track and report on task assignments of specific audit steps, audit sections or entire audit projects, to individual auditors.
1.18. The solution SHOULD provide event-based notifications and alerts via electronic mail.
1.19. The solution SHOULD store, retain and track audit reports preferably in an inbuilt document repository
1.20. The solution SHOULD support the output of editable audit reports via Microsoft Word.
1.21. The solution SHOULD allow customization of audit report format, including margins, fonts, and organization of information.
1.22. The solution SHOULD support e-mail distribution of reports.
1.23. The solution SHOULD support the ability to have more than one management response or auditee for each observation or finding.
1.24. The solution MUST allow users the ability to capture, save, and print a draft report to present observations to the auditee.
1.25. The solution SHOULD generate administrative reports.
1.26. The solution MUST capture details of auditor assigned, audit project assigned, completion dates, initiation dates, projects currently in progress.
1.27. The solution SHOULD support the creation and tracking of project milestones within audit projects and allow users to run reports on variances between the planned audit schedule and its actual executed schedule.
1.28. The solution SHOULD provide ad hoc reporting capabilities.
1.29. The solution SHOULD provide a method or means whereby an auditor may track and follow-up on audit observations and recommendations.
1.30. The solution SHOULD capture and track actual time an auditor may spend by at least, but not limited to, the following criteria:
· By specific audits performed
· By individual auditors
· By projects or engagement
· By departments
· By planned and unplanned hours for an audit assignment
· By direct time and administrative time an auditor spends on an audit
· By budgeted time
1.31. The solution SHOULD allow users to import external documents.
1.32. The solution MUST allow users to hyperlink to specific documents within the project or solution, including but not limited to: current or legacy versions of Microsoft Word or Microsoft Excel documents, scanned images, and data mining output files, as well as flow chart (i.e. current or legacy versions of Microsoft Visio) documents associated with audit work papers.
1.33. The solution SHOULD allow users to make annotations, if desired, on imaged (i.e., pdf or scanned) documents.
1.34. The solution SHOULD support indexing of work papers, attachments, or other documents.
1.35. The solution MUST capture, manage and track all observations (effect, priority rating and cause), recommendations and corrective actions (customer response, responsible person and implementation date), created as stand-alone documents, and store them in an internal, secured database.
1.36. The solution SHOULD provide a means or method whereby an auditor may assign risk severity ratings to observations.
1.37. The solution SHOULD support risk-based audit project planning and scheduling.
1.38. The solution SHOULD allow annual audit plan development, including, but not limited to the following elements: budgeting support and reporting of deviations to actual project time.
1.39. The solution SHOULD provide a means or method for auditors to perform qualitative and quantitative risk assessment of the audit universe.
1.40. The solution SHOULD support project specific customized risk assessments using risk criteria defined by audit personnel.
1.41. The solution SHOULD have a means or method for the creation of draft yearly audit plans
1.42. The solution MUST have the ability to allow nominated customers to receive periodic reminders to resolve pending audit issues
1.43. The solution MUST allow nominated customers to update the system with management actions taken so far to address audit findings
1.44. The AECF currently uses Dynamics 365 Business Central ver. 2020 ERP. The solution proposed should be able to easily integrate with this ERP whose database is SQL and allow for easy exchange of data between the systems. This will be an added advantage, if available.
D. SPECIFIC DUTIES AND RESPONSIBILITIES OF THE IMPLEMENTOR
The Implementor will be responsible for the following:
1.1. Responding to the RFP and executing the same if selected, describing the process to be followed for supply and implementation of the software.
1.2. Supply the Solution indicating specific modules, and justification with respect to satisfying the functional and technical requirement specifications laid down in this document.
1.3. Test the solution configured and provide quality assurance within the project.
1.4. The product version proposed by the Implementor must comply with the mandatory criteria below;
a. It must be of the latest commercially available and acceptable version, at the time of Commencement of project implementation.
b. It must have all functions described in business process requirements as natively integrated applications on a single interoperable open platform and not the integration of multiple products and overlapping middleware.
c. It should provide a mandatory Single Sign-On authentication matching with the AECF’s current platform environment with Microsoft Azure, authorization.
d. Upgrade to new releases should not become mandatory for the next three years from the date of installation.
e. It must have product roadmap for the last 3 years and the next 3 years, demonstrating a vendor commitment for continuous investments and enhancements for the specific version of the system
f. It must be upwards scalable in size, capacity and functionality to meet changing business and technical requirements, thereby enabling AECF to be adaptable to change.
1.5. The vendors will be required to provide detailed documentation on the following in their technical response:
a. The system’s required customization if any, tools, database, network performance and the related software being supplied in order to meet the functional and technical requirements set out in this document.
b. The process to be followed in installation and configuration of the system, tools, database and the related software.
c. The process to be followed for maintenance and upgrade of the system, applying patches, and integration of the related software.
E. IMPLEMENTATION SERVICES
The Implementor will be responsible for the following during the implementation;
1.1. Design and implementation of system architecture
1.2. Project management, planning and scheduling various phases of the implementation
1.3. Verify and ensure the completeness of business process descriptions and their mapping against the capabilities of the proposed solution.
1.4. Conceptualizing, configuring, developing, customizing, validating and implementing the solution, including developing and testing interfaces, custom applications, data conversion where required, training and change management, documentation etc.
1.5. Providing post go-live support.
F. GENERAL SYSTEM ARCHITECTURE GUIDELINES
1.1. The system architecture should be based on open and prevailing industry standards and protocols.
1.2. The system will be Cloud based or cloud ready, centrally deployed and accessed.
1.3. Role based access shall be planned to ensure high granularity without compromising on security needs of the application.
1.4. The system shall be designed to be scalable and extensible.
G. DATA MANAGEMENT
1.1. Data will be owned, shared, controlled and protected as a corporate asset.
1.2. Shared data will have consistent formats and definitions and be independent of applications.
1.3. Data should only be accessed through application/interfaces to create, update and delete.
1.4. System must have inbuilt data repository allowing data to sit and be accessed within the system
H. IMPLEMENTATION PLAN
1.1. The date of award of contract to the Implementor will be considered as start date of implementation.
1.2. The implementor should propose a suitable project plan.
1.3. The Implementor will further detail the project plan in early stages of the project and get it validated by AECF. The project plan should include training strategy, describing and implementing proposed approach in providing training to various categories of users, including Internal Audit team.
1.4. Post implementation support strategy;
1.5. All documentation will be in English and subject to review and acceptance by The AECF.
J. FUNCTIONAL SCOPE
1.1. The new system should be a centralized, Cloud ready Solution maintaining all the data under a single database.
K. AUDIT TRAIL
1.1. The Implementor must ensure that the system has extensive functionality with respect to maintaining audit trail. The system shall be able to define audit trails, audit logs and transaction logging requirements.
1.2. Any addition, deletion or modification to an existing record must bear the date and time stamp, the name of the log-in user who made the change and the terminal from which the change was made.
1.3. It should also be possible to maintain details of the original record and subsequent changes to the record. Standard audit related reports should also be available.
1.1. The Solution must be scalable both in terms of the business rules, volume of transaction and master data but also in terms of defining new entities and structure.
M. 24/7 SUPPORT OPERATIONS
1.1. The Implementor must ensure that the system is supported 24/7. This is necessary as AECF will work with implementation partners and stakeholders across all time zones worldwide.
N. TRAINING SCOPE
1.1. The key to successful implementation will be the Implementor’s ability to train the Internal Audit Unit staff in operating the system. In this context, the Implementor is expected to:
1.1.1. Provide a description of the training hand-outs and/or operating manuals to be provided to the core team members and the end users;
1.1.2. Training programs organized for separate categories of users based on functions, roles and responsibilities.
1.1.3. The Implementor will be responsible for the preparation of the training material and end user manuals. End user manuals should cover “how to use” concepts for all modules implemented.
- The Technical Proposal must be submitted separately and clearly marked on the document and email subject “Technical Proposal-Audit Management Software”. No details of a financial nature whatsoever should be included in this Technical Proposal. Failure to comply with this requirement will result in the disqualification.
- Proposers are requested to submit a Technical Proposal that demonstrates the capability in delivering requested services.
- The Technical Proposal shall include information to demonstrate the current soundness and financial position of the submitting organization:
a) Organizational: a brief description, including ownership details, date, and place of incorporation of the firm, objectives of the firm, partnerships, qualifications, and certificates, etc.
b) Statement of Satisfactory Performance of similar services from the firm’s op 3 (three) Clients in terms of Contract Value the past 3 (three) years. Contact details of the mentioned clients must be provided.
c) Listing of proposed personnel, experience, and qualifications
d) Comments on the RFP and how the firm will address the requirements.
e) Methodology and approach
- To facilitate a faster evaluation and comparative analysis of the proposals, we recommend that the proposals be structured in the following manner:
a) Expertise of Firm/Organization – This section should provide details regarding management structure of the organization, organizational capability/resources, and experience of organization/firm, the list of projects/contracts (both completed and on-going, both domestic and international) which are related or similar in nature to the requirements of the RFP.
b) Proposed Methodology, Approach and Implementation Plan – This section should demonstrate the implementor’s response to the RFP/scope of services by identifying the specific components proposed, how the requirements shall be addressed, as specified, point by point; providing a detailed description of the essential performance characteristics proposed; and demonstrating how the proposed methodology meets or exceeds the specifications, while ensuring appropriateness of the approach to the local conditions and the rest of the project operating environment.
c) Management Structure and Key Personnel – This section should include the comprehensive curriculum vitae (CVs) of key personnel that will be assigned to support the implementation of the proposed methodology, clearly defining the roles and responsibilities vis-à-vis the proposed methodology. CVs should establish competence and demonstrate qualifications in areas relevant to the TOR.
In complying with this section, the implementor assures and confirms to The AECF that the personnel being nominated are available for the Contract on the dates proposed. If any of the key personnel later becomes unavailable, except for unavoidable reasons such as death or medical incapacity, The AECF reserves the right to render the proposal non- responsive.
- The Financial Proposal should include pricing information covering the requirements covered in this document.
- The Financial Proposal document must be clearly marked “Financial Proposal-Audit Management Software” as well as the email subject. NO details of a financial nature whatsoever must be included in the Technical Proposal. Failure to comply with this requirement will result in disqualification.
- The financial component shall include the following:
3.1. Fee structure and pricing details in US dollars including all expenses and applicable taxes;
3.2. Financial methodology that explains the rationale of the financial component and how it offers best value;
3.3. Financial plan that clearly links all costs to activities and outputs detailed in the work plan with associated payment mechanisms;
3.4. Unit rates
3.5. Total Lump sum Contract amount
- Financial proposals that will not have the above details will be disqualified.
- Implementor shall include and clearly show all expected taxes in the financial component.
- The AECF reserves the right to give preference to the most appropriate baseline in terms of expected economies of scale.
- The financial proposal shall be fixed price and not based on Time & Material. It should contain real efforts in terms of man days (i.e. Junior, Intermediate, Senior etc.) and price per man day for each category. Based on the Technical proposal (Workplan, methodology, personnel, goods and services to be supplied under the contract and the unit rates, the bidder must provide a total lump sum fixed price for determining the financial score and contract value.
- The AECF will follow the timeline below for this RFP. Any changes to this timeline will be posted on the AECF website. Please note that the target dates and may be adjusted.
Date (and time, EAT*)
Posting of RFP
05th February 2021
Last date for requests for clarification of the RFP
27th February 2021; 17.00HRS EAT
Last date to reply to questions received/ Last date for amendment
20th February 2021; 17.00HRS EAT
Last date for submission of proposal
05th March 2021; 17.00HRS EAT
*EAT: East Africa Time (Nairobi)
A. Evaluation and Comparison of Proposals
1.1. An evaluation committee will be formed by the AECF and may include employees of the businesses to be supported. All members will be bound by the same standards of confidentiality. The Specialist should ensure that they fully respond to all criteria to be comprehensively evaluated.
1.2. The AECF may request and receive clarification from any Specialist when evaluating a proposal. The evaluation committee may invite some or all the Specialists to appear before the committee to clarify their proposals. In such event, the evaluation committee may consider such clarifications in evaluating proposals.
1.3. In deciding the final selection of qualified bidder, the technical quality of the proposal will be given a weighting of 70% based on the evaluation criteria. Only the financial proposal of those bidders who qualify technically will be opened. The financial proposal will be allocated a weighting of 30% and the proposals will be ranked in terms of total points scored.
1.4. The mandatory and desirable criteria against which proposals will be evaluated are identified in the table below.
Key Areas for Evaluation/ Assessment
(A) TECHNICAL PROPOSAL
i) Understanding of the needs
· Demonstrable understanding of the AECF and Internal Audit Functions and requirements
ii) Expertise of Firm/Organization
· Organogram/Management structure of the company
· Demonstrated financial capability of the company
· Demonstrate relevant past experience and recent engagements for similar assignments
· Letters of reference from past customers
iii) Proposed methodology, approach and implementation plan
· Meets all specifications labelled ‘MUST’ and to a considerable degree those labelled ‘SHOULD’
· Meets and complies with the mandatory criteria
· Clear and suitable project management, planning and scheduling plan
· Meets the general system architecture guidelines
· Proposed solution satisfies the data management requirements
· Solution meets all functional scope requirements
· Proposed solution provides functionality with respect to maintaining audit trail.
· Satisfies scalability requirements
· Demonstrated ability for 24/7 maintenance support
· Demonstrable training support with clearly defined training hand-outs and/or operating manuals
iv) Management Structure and Key Personnel
· Provide comprehensive curriculum vitae (CVs) of key personnel
· Clearly defined roles and responsibilities
(B) FINANCIAL PROPOSAL
· Clarity, relevance, reality to market value/ value for money of cost for the Assignment (inclusive of any applicable tax).
· All applicable taxes quoted separately in the proposal
· Clear illustration of implementation costs, license costs & expected recurrent costs for at least the first 3 years
B. Acceptance of Submissions
1.1. All proposers are expected to adhere to the requirements for submitting a proposal.
1.2. Any proposals that fail to comply will be disqualified from further consideration as part of this evaluation. In particular:
a) Full compliance with the formal requirements for submitting a proposal;
b) Submission of all requested documentation
A. Completion of this document
1.1. Please complete each part of this document or provide a brief explanation where this is not possible using the space available. The vendors are asked to respond by addressing the following:
Company Profile Form
Please respond to all questions within your proposal.
Company details – vendor’s name:
Parent company, if any
Subsidiaries, Associates and/or Overseas Rep(s), if any
Type of organization
Public Enterprise () Private Company ()
Organization sponsored by donors () Other (please specify) ()
Type of Business
ICT Software Implementor ( )
Software Vendor () Consulting Company ()
Other (please specify) ( )
Summary of main business activities
No. of employees (by location)
In-house working language(s)
Bank Address Account Holder Account Number
Prior experience with international organizations
List contracts undertaken in the last three years with a similar scope.
BRIEFLY list recent clients for whom you produced similar deliverables as well as values: Attach additional sheets if necessary.
List any disputes your company has been involved in over the last three years
List suitable reference projects and contacts.
*W**hat options would there be for a site visit to a reference project and/or the vendor’s site?*
*I**f this is a part bid, list relevant recent experience of working with partners.*
Are there already formal or informal preferred partnership agreements in place?
Conflict of Interest
Are there any likely circumstances or contracts in place that may introduce a conflict of interest with the parties to this contract? If so, explain how this will be mitigated
How to apply
2.3. To be considered, your proposal reference “REQUEST FOR PROPOSAL IMPLEMENTATION OF AN AUDIT MANAGEMENT SOFTWARE” must be addressed to email@example.com and received by 05th March 2021, 5:00 PM EAT