In IT governance, this is known as a "Single-Source / Relationship-Driven Vendor Risk."
Because the consultant has a pre-existing relationship with the CFO, there may be blind spots regarding accountability, objective vetting, and architectural fit for HCI’s specific infrastructure.
To protect HCI, secure a 95%+ success rate, and safeguard your department, you must establish objective, metrics-driven IT governance guardrails. Here are the critical risk management items you need to look for and implement immediately:
1. Architectural & Governance Risks
Relationship Bias vs. Objective Deliverables
Because the consultant was brought in via a personal relationship, standard procurement vetting might be relaxed.
The Risk: The consultant may promise things verbally to the CFO that are not legally binding in the Statement of Work (SOW), or they may rely on an implementation methodology that worked at their previous charity but is a poor fit for HCI's $50M scale and custom integrations (Launchgood, Technicost, Clover).
Your Mitigation: Enforce an Objective Requirements Traceability Matrix (RTM). Turn the RFQ into a spreadsheet where every single requirement (e.g., CRA sequence numbers, Technicost direct debit file formatting) has a designated column for: "Standard / Custom / Third-Party", "Tested Date", and "Sign-off Authority (IT Manager)". Do not accept verbal assurances.
The "Shadow IT" and Exclusion Risk
The Risk: The consultant and CFO may bypass you and your internal IT processes, making architecture decisions in a vacuum and leaving you to clean up security, hosting, and permission issues later.
Your Mitigation: Insist on a formal Project Governance Charter establishing that the consultant reports to a Steering Committee (CFO, CEO, and IT Manager), not just the CFO. Establish that no custom module or hosting configuration can go live without the IT Manager's architectural sign-off.
2. Technical & Integration Guardrails (The Trapdoors)
Since the consultant is building an ERP that touches your entire digital landscape, you must mandate rigid boundaries on three technical fronts:
+----------------------------------------+ | ERP Project Governance | +----------------------------------------+ | +------------------------------+------------------------------+ | | | v v v+-----------------------+ +-----------------------+ +-----------------------+| Data Sovereignty | | Integration Source | | Custom Code Ownership || & Security | | Code Control | | & Escrow |+-----------------------+ +-----------------------+ +-----------------------+| Must use Odoo.sh or | | Vendor must commit to | | Code must be hosted || self-hosted AWS. No | | continuous building to| | in HCI's GitHub with || vendor-owned cloud. | | your repository. | | comprehensive documentation.|+-----------------------+ +-----------------------+ +-----------------------+
Data Sovereignty and Security
The Risk: The consultant might recommend hosting Odoo on their own private servers or a secondary reseller account to keep HCI tied to their ongoing support contracts.
Your Mitigation: Mandate that the production environment must be deployed on Odoo.sh (Dedicated Enterprise Cloud) or an AWS instance owned and controlled entirely by HCI. IT must retain root administrative access from day one.
Source Code Control & Customization Ownership
The Risk: The consultant builds custom Odoo modules for your Canadian Tax Receipts and Technicost Direct Debit integrations, but they write the code in a way that only they can maintain, effectively locking you into a permanent vendor dependency.
Your Mitigation: The SOW must explicitly state that all custom code developed for HCI is "Work for Hire" and is the intellectual property of HCI. Mandate that the consultant push all custom module code to a private GitHub repository owned by HCI at the end of every week, accompanied by technical documentation (not just end-user guides).
Cyber Security & CRA Data Privacy
Odoo will store 182k donor records, home addresses, financial histories, and payment tokens.
The Risk: A data breach on a poorly configured Odoo instance could devastate HCI's reputation.
Your Mitigation: Ensure the consultant includes a budget and timeline for a Third-Party Penetration Test and Vulnerability Scan on the Odoo instance before go-live. Ensure that credit card processing strictly uses Authorize.net tokenization so that raw credit card numbers never touch or reside in your Odoo database.
3. Data Migration and Operational Continuity Risks
Data Migration "Scope Creep"
The consultant will likely push for "Option B" (Full Historical Migration) because it billed highly at their last project.
The Risk: Migrating historical transactional records from Blackbaud CRM into Odoo can quickly deplete the project's budget and cause extensive timeline delays due to formatting inconsistencies.
Your Mitigation: Push strongly for Option A (Master Data Only) for launch. Keep Blackbaud running in a read-only, low-cost archive state for historical audits. If the CFO insists on full migration, require the consultant to deliver a "Data Migration Audit Report" showing a 100% financial match on a staging environment before any data is brought into production.
Change Management and User Adoption Failure
The Risk: The consultant focusing heavily on the CFO's financial requirements may neglect training the frontline marketing and fundraising staff, leading to operational friction at launch.
Your Mitigation: Review the training deliverables. The RFQ currently states "2 half-day sessions". For 50 internal users shifting away from systems they have used for years, this is completely inadequate. Insist on a structured "Train-the-Trainer" program and at least 3 weeks of staggered, department-specific workshops.
How to Position Yourself Strategically
Do not frame your concerns as opposition to the consultant—frame them as protecting the CFO's vision and ensuring institutional compliance.
Use your 6-year history as your shield. Your opening line in the project kickoff should be:
"I want to ensure this project delivers exactly what the CFO needs. Based on my six years handling HCI's data infrastructure, here are the historical integration failures and data quirks we must legally protect ourselves against in the SOW..."
By establishing rigorous documentation standards, code repositories, and clear testing milestones, you shift the dynamic from a "relationship-based" project to a highly professional, tightly engineered IT deployment.
Here is a professional, institutional-grade Technical Sign-Off Framework & Project Governance Clause.
You can insert this text directly into the Statement of Work (SOW) or present it to the Steering Committee as an official amendment. Writing this directly into the contract ensures that no matter how close the consultant is with the new CFO, they must legally respect your IT protocols, architectural boundaries, and security standards to get paid.
Technical Sign-Off Framework (Addendum to SOW)
This framework defines the strict technical gates that must be cleared and signed off by the HCI IT Manager before the project can advance to subsequent phases or release milestone payments to the Vendor.
Milestone Gates & Technical Criteria
Project Phase | Technical Gate & Criteria | Required Deliverables for IT Sign-Off |
Phase 1: Discovery | Architectural Alignment | A complete Requirements Traceability Matrix (RTM) detailing every RFQ line item as Native, Configured, or Custom Code.Data Mapping Document for the 182k donor records from Blackbaud.Written confirmation of API endpoints and data payloads for the Launchgood and Technicost integrations. |
Phase 2: Development | Environment & Source Control Setup | HCI-owned Odoo.sh Production, Staging, and Development environments active with Root Admin access handed to HCI IT.HCI-owned GitHub repository initialized; Vendor must demonstrate weekly automated code pushes of all custom modules ( |
Phase 3: Testing (UAT) | Compliance & Security Validation | CRA/IRS Immutability Test: Successful simulation showing that tax receipts generate sequential, non-modifiable PDFs, and alterations force a visible "Revoked/Reissued" audit trail.Data Verification Report: 100% financial and contact matching on a random sample of 5,000 imported donor records against legacy Blackbaud/QuickBooks exports.Security Verification: Confirmation that no raw credit card details or direct debit account numbers are stored in plain text within the Odoo database (Tokenization validation). |
Phase 4: Go-Live | Operational Handover | Technical system architecture diagrams mapping all data flows (Odoo, Clover, Launchgood, Technicost).Technical Administration Guide detailing automated cron jobs, backup recovery workflows, and API renewal credentials.Sign-off on the completed user training log for all 50 internal users. |
SOW Governance Clauses (Contractual Language)
Copy, adjust, and embed these clauses directly into the legal agreement.
Clause 1: Technical Governance & Oversight
1.1 Project Steering Committee: A Project Steering Committee shall be established, consisting of the HCI Chief Financial Officer (CFO), Chief Executive Officer (CEO), and the HCI IT Manager. This Committee serves as the final authority for all scope changes, architectural shifts, and financial approvals.
1.2 Independent Technical Review: The HCI IT Manager retains sole authority over HCI's internal infrastructure, digital security, and data privacy compliance. The Vendor agrees to submit all technical architecture designs, hosting configurations, and data migration plans to the HCI IT Manager for written approval prior to implementation. No system deployment, platform integration, or database modifications shall occur in a production environment without the express written sign-off of the HCI IT Manager.
Clause 2: Intellectual Property & Source Code Ownership
2.1 Work for Hire: All custom software, custom Odoo modules (including but not limited to the Canadian/US Tax Receipt Engine and Technicost Direct Debit interfaces), data scripts, web templates, and configuration assets developed under this SOW shall be considered "Work for Hire" and shall remain the exclusive intellectual property of Human Concern International (HCI).
2.2 Code Repository Requirements: The Vendor is required to maintain all custom source code in a private GitHub repository owned and controlled by HCI IT. The Vendor shall commit and push fully commented, clean code to this repository at minimum once per week. Under no circumstances shall the Vendor host HCI's custom source code in a vendor-owned, third-party, or private repository beyond standard local development environments.
Clause 3: Environment Control & Data Sovereignty
3.1 Infrastructure Ownership: The Odoo production database and all supplementary environments must be provisioned directly under an Enterprise account registered under HCI’s legal name. HCI IT shall retain master administrative credentials ("Root Access") across all tiers (Odoo S.A., Odoo.sh, or AWS hosting).
3.2 Vendor Termination & Continuity: The Vendor shall not withhold administrative credentials, API access keys, or database backups under any circumstances, including contractual disputes. HCI reserves the right to revoke Vendor environment permissions at any time to preserve data integrity and operational security.
Clause 4: Sign-off and Payment Terms
4.1 Milestone Interdependency: Milestone payments outlined in the Quotation Format (30% deposit, 40% on UAT, 30% on Go-Live) are strictly contingent upon the completion and formal sign-off of the corresponding technical deliverables by the HCI IT Manager. Verbal approvals or handovers directly to non-technical stakeholders shall not constitute a cleared milestone.
How to frame this to the CFO
When you present this structure, pitch it as an audit-protection and risk-reduction mechanism for the finance department:
"To ensure that your vision for Odoo delivers a 95%+ success rate, I’ve put together a standardized technical sign-off sheet and code control framework. This protects HCI legally, ensures the vendor builds modules that comply with CRA data guidelines, and guarantees that we own our custom code if the vendor disappears after go-live. It gives us total contractual leverage over the consultant."
This positions you perfectly: you aren't blocking the CFO's chosen consultant, but you are forcing that consultant to play by institutional IT rules.