Project Governance

Introduction

This document establishes the governance framework for the OpenCHS (Open Child Helpline System) project. The purpose of this framework is to ensure alignment with strategic objectives, facilitate efficient decision-making processes, implement robust risk management strategies, and delineate clear lines of accountability throughout the project lifecycle, encompassing development, deployment, and operational phases.

Governance Objectives

The governance structure is designed to achieve the following objectives:

Strategic Alignment: Guarantee the project's adherence to established business and operational objectives supporting child protection services across Kenya, Tanzania, Uganda, and Lesotho.

Decision-Making: Enable the timely and judicious determination regarding development priorities, AI effectiveness, and system enhancements.

Accountability: Delineate explicit duties across the backend, frontend, artificial intelligence, and telephony departments.

Risk Management: Systematically identify, mitigate, and monitor potential project hazards related to data privacy, AI ethics, and operational reliability.

Adaptability: Ensure the system's capacity for subsequent improvements, scaling, and geographic expansion.

Open Source Stewardship: Maintain commitment to open-source principles, community engagement, and transparent development practices.

Governance Structure

Strategic Governance (Steering Committee)

Responsibility: Establishes strategic direction, exercises high-level oversight, and grants approval for significant decisions affecting project scope, budget, and timelines.

Composition:

• Representatives from UNICEF Venture Fund
• BITZ IT Consulting LTD Leadership
• Key stakeholders from Kenya, Tanzania, Uganda, and Lesotho
• Child protection service representatives

Meeting Frequency: Monthly

Key Decisions:

• Strategic roadmap and priorities
• Budget allocation and resource planning
• Geographic expansion decisions
• Major partnership agreements
• Compliance with UNICEF Venture Fund requirements

Project Management Office (PMO)

Responsibility: Manages project implementation, ensures adherence to project objectives, monitors risks, coordinates interdepartmental teams, and maintains communication channels.

Composition:

• Project Lead: Nelson Adagi
• Product Owners: Managing feature prioritization and stakeholder requirements
• UNICEF Representative: Ensuring alignment with UNICEF standards
• Technical Coordinators: From backend, frontend, AI, and telephony teams

Meeting Frequency: Weekly

Key Responsibilities:

• Sprint planning and execution
• Resource allocation and team coordination
• Risk identification and mitigation
• Progress tracking and reporting
• Quality assurance oversight
• Open-source community engagement

Technical Advisory Board

Responsibility: Guarantees the application of open-source best practices, ethical principles in AI, observance of privacy and security protocols, and technical excellence.

Composition:

• Ken Orwa: Specialist in AI Ethics and Data Privacy
• Gateway Frankline: AI Training and Model Development (S3)
• Joseph Kimani: Expert in Backend and System Architecture
• Community Representatives: Selected open-source contributors

Meeting Frequency: Bi-weekly

Key Responsibilities:

• AI model ethics review and bias detection
• Data privacy and security architecture
• Technical standards and best practices
• Open-source licensing compliance
• Code review and quality standards
• Technology stack evaluation

Development Teams

Backend Team: Django/PostgreSQL infrastructure, API development, system integration

Frontend Team: Vue.js applications, wallboard systems, user interfaces

AI Team: MLflow deployment, model training, NLP services, voice recognition

Telephony Team: Asterisk PBX integration, WebSocket connectivity, call routing

Project Ownership

Primary Owner: BITZ IT Consulting LTD, Nairobi, Kenya

Funding Partner: UNICEF Venture Fund

License: GNU General Public License v3.0 (GPL-3.0)

Intellectual Property: All code and documentation are open-source and available to the global community. BITZ IT Consulting LTD maintains copyright while ensuring free access under GPL-3.0.

Community Ownership: OpenCHS is developed as a public good for child protection services worldwide. Community contributions are welcomed and governed by the project's contribution guidelines.

Decision-Making Process

Operational Decisions

• Owner: Project Manager
• Approval Level: Project Manager
• Escalation Point: Steering Committee
• Examples: Sprint priorities, resource allocation, minor feature changes

Technical Decisions

• Owner: Technical Lead, Advisory Board
• Approval Level: Technical Advisory Board
• Escalation Point: Steering Committee
• Examples: Technology stack changes, architecture modifications, security protocols

Major Changes

• Owner: Steering Committee
• Approval Level: Steering Committee Approval
• Escalation Point: Project Sponsor (UNICEF)
• Examples: Budget changes >10%, scope modifications, timeline extensions, new country deployments

Critical Issues

• Owner: Steering Committee
• Approval Level: Project Sponsor Approval
• Escalation Point: Not Applicable
• Examples: Data breaches, major system failures, compliance violations, ethical concerns

Risk Management

Data Privacy Risks

Potential Issues: Data breaches, regulatory non-compliance (GDPR, local data protection laws), unauthorized access to child information

Mitigation Strategy:

• Data anonymization and pseudonymization
• Role-based access controls (RBAC)
• Encryption at rest and in transit
• Regular security audits and penetration testing
• Compliance monitoring and reporting
• Staff training on data protection

AI Model Risks

Potential Issues: Model performance degradation, inaccurate predictions, bias in classification, language translation errors

Mitigation Strategy:

• Regular model retraining with diverse datasets
• Systematic bias detection and correction
• Continuous performance monitoring
• A/B testing for model improvements
• Human-in-the-loop validation for critical decisions
• Transparent AI decision-making logs

Operational Risks

Potential Issues: System outages affecting call functionality, voice processing failures, database corruption, capacity overload

Mitigation Strategy:

• Redundant system architecture
• Automated scaling mechanisms
• Manual override protocols
• Comprehensive backup systems
• Disaster recovery procedures
• 24/7 monitoring and alerting

Project Risks

Potential Issues: Budget overruns, insufficient resources, schedule delays, scope creep, staff turnover

Mitigation Strategy:

• Regular progress evaluations
• Contingency budget allocation
• Knowledge documentation and transfer
• Agile methodology for flexibility
• Regular stakeholder communication

Open Source Risks

Potential Issues: License violations, dependency vulnerabilities, community conflicts, contribution quality

Mitigation Strategy:

• License compliance scanning
• Dependency security monitoring
• Clear contribution guidelines
• Code review processes
• Community code of conduct

Reporting & Communication

Progress Reports

• Frequency: Weekly
• Recipients: Steering Committee, Stakeholders
• Purpose: Track progress, flag issues, report milestones, update on compliance requirements

Sprint Reviews/Demos

• Frequency: Bi-weekly
• Recipients: Development Teams, Stakeholders
• Purpose: Showcase features, collect feedback, demonstrate working software

Steering Committee Meetings

• Frequency: Monthly
• Recipients: Steering Committee members
• Purpose: Strategic decisions, budget reviews, risk assessment, expansion planning

Technical Advisory Board Meetings

• Frequency: Bi-weekly
• Recipients: Technical leads, AI ethics team
• Purpose: Technical reviews, ethics assessments, security audits

Ad-hoc Reports

• Frequency: As needed
• Recipients: Relevant teams, Project Sponsor
• Purpose: Address critical issues, security incidents, or unplanned events

Community Updates

• Frequency: Monthly
• Recipients: Open-source community, GitHub contributors
• Purpose: Development updates, roadmap changes, contribution opportunities

Change Management

Change Request Process

Stage 1: Submission: Any team member or community contributor submits a detailed change request with impact analysis including technical, timeline, and resource implications.

Stage 2: Impact Review: Technical leads evaluate the impact on performance, security, existing features, timeline, and budget.

Stage 3: Approval:

• Minor changes: Technical lead approval
• Moderate changes: PMO approval
• Major changes: Steering Committee approval

Stage 4: Implementation: Change integrated into development sprints with minimal disruption. Documentation updated accordingly.

Stage 5: Verification: Testing, quality assurance, and stakeholder validation before deployment.

Compliance & Auditing

Data Privacy Compliance

• Obligations: GDPR, local data protection laws (Kenya Data Protection Act, etc.), UNICEF child safeguarding standards
• Audit Schedule: Quarterly
• Responsible Party: Data Protection Officer, Technical Advisory Board

AI Performance & Ethics

• Obligations: Model accuracy monitoring, fairness assessment, bias detection, ethical AI principles
• Audit Schedule: Bi-monthly
• Responsible Party: AI Team, Ken Orwa (AI Ethics Lead)

System Performance

• Obligations: Uptime monitoring, call handling efficiency, response latency, resource utilization
• Audit Schedule: Monthly
• Responsible Party: DevOps Team, Joseph Kimani (System Architecture)

Code Quality & Security

• Obligations: Code coverage targets (80%), security vulnerability scanning, dependency updates
• Audit Schedule: Continuous (automated) + Quarterly manual review
• Responsible Party: All development teams, Technical Advisory Board

Open Source Compliance

• Obligations: GPL-3.0 compliance, proper attribution, contribution guidelines adherence
• Audit Schedule: Quarterly
• Responsible Party: Project Lead, Legal Advisor

Conflict Resolution

Internal Team Conflicts

Process: Escalate to Project Manager → PMO → Steering Committee

Technical Disagreements

Process: Technical Advisory Board review → Architecture decision record (ADR) → Implementation

Community Conflicts

Process: Code of Conduct enforcement → Community managers → Project leadership

Stakeholder Conflicts

Process: Facilitated discussion → Steering Committee mediation → UNICEF escalation if needed

Amendment Process

This governance document may be amended through the following process:

1. Proposed amendments submitted to PMO
2. Impact assessment by relevant teams
3. Review by Technical Advisory Board (if technical)
4. Approval by Steering Committee
5. Communication to all stakeholders
6. Documentation update in repository

Major governance changes require unanimous Steering Committee approval.

Conclusion

This governance structure ensures transparency, accountability, and adaptability for OpenCHS. The framework facilitates effective collaboration, risk mitigation, and decision-making throughout all project phases while maintaining commitment to open-source principles and child protection excellence.

Last Updated: October 2024
Next Review: January 2025
Document Owner: Nelson Adagi, Project Lead