Centralized Digital Planning and Monitoring System
By Hagos Muluye
ADA [Link]
Date: October 26, 2023
Table of Contents
Project Initiation & Planning
1.1. Executive Summary
1.2. Project Background & Business Need
1.3. Project Goals & Objectives
1.4. Scope Statement
1.5. Stakeholder Register
1.6. Project Methodology (Hybrid Agile-Waterfall Model)
1.7. High-Level Project Timeline
System Analysis & Requirements
2.1. Functional Requirements
2.2. User Stories
2.3. Non-Functional Requirements
2.4. System User Roles & Authorizations
System Design
3.1. Architectural Design
3.2. Data Design (Entity Relationship Diagram)
3.3. User Interface (UI/UX) Design Principles
Development & Construction
4.1. Development Environment & Technology Stack
4.2. Sprint-Based Development Process
4.3. Project Folder Structure
Testing & Quality Assurance
5.1. Testing Strategy
5.2. User Acceptance Testing (UAT)
Implementation & Deployment
6.1. Deployment Plan
6.2. User Training Plan
6.3. Data Migration Strategy
Maintenance & Support
7.1. Support Plan
7.2. System Maintenance & Backups
7.3. Future Enhancements
Appendix
A: Glossary of Terms
B: Full ERD Mermaid Code
1. Project Initiation & Planning (Waterfall Phase)
This phase establishes the foundation and vision for the entire project.
1.1. Executive Summary
The ADA Planning and Monitoring System (PMS) is a secure, web-based platform
designed to digitize and centralize the entire strategic planning, monitoring, and
reporting lifecycle for the Amhara Development Association. This project replaces the
current manual, paper- and spreadsheet-based processes, which are inefficient, prone to
error, and create significant challenges for data consolidation and timely reporting. The
PMS will empower stakeholders at all levels—from Headquarters to the Branch offices
—with the tools to collaboratively plan, track progress, and make data-driven decisions,
directly supporting ADA's mission to ensure the overall development and prosperity of
the people of Amhara.
1.2. Project Background & Business Need
As per its mandate, ADA executes a wide range of development programs in education,
health, job creation, and resource mobilization. Currently, the process of creating,
assigning, and reporting on goals, objectives, initiatives, and activities is fragmented
across various departments and geographical locations. This leads to:
Data Silos: Information is trapped in individual documents and spreadsheets at HQ,
Coordination Offices, and Branches.
Reporting Delays: Consolidating quarterly and annual reports is a time-consuming
manual effort.
Lack of Real-Time Visibility: Leadership cannot get an immediate, accurate snapshot of
performance across the organization.
Inefficient Collaboration: Assigning initiatives and tracking dependencies between
organizational units is difficult.
The PMS addresses these challenges by creating a single source of truth, automating
workflows, and providing role-based access to relevant information for all system users.
1.3. Project Goals & Objectives
Goal 1: To significantly improve the operational efficiency of ADA's planning and
reporting processes.
Goal 2: To enhance strategic decision-making by providing accurate, real-time data to
leadership.
Goal 3: To foster a culture of transparency and accountability across all levels of the
organization.
Project Objectives (SMART):
To deliver a fully functional, secure, and tested web-based system by the end of the
project timeline.
To successfully migrate all existing strategic framework data (Goals, Objectives,
Initiatives) into the new system.
To train 100% of the identified system users on how to perform their specific functions
within the platform.
To reduce the time required for generating consolidated quarterly reports by at least
75%.
1.4. Scope Statement
In-Scope:
User and Role Management with granular, location-based permissions.
Creation and management of the full strategic hierarchy: Goals, Objectives, Initiatives,
Major Tasks, and Activities.
Creation and approval workflows for HQ-level and Coordination Office-level plans
(Project, Training, Membership, etc.).
Role-based dashboards providing relevant key performance indicators.
View-only access for specific roles (e.g., MIS Officer, default User).
Full system access for Admin and CEO roles.
Out-of-Scope (for Version 1.0):
Public-facing portals or mobile applications.
Financial accounting and transaction processing (the system will track budget, but not
manage actuals).
Integration with third-party HR or finance systems.
Advanced business intelligence (BI) analytics and predictive modeling.
1.5. Stakeholder Register
The primary stakeholders are the internal users of the Amhara Development
Association, as defined in Section 2.4.
1.6. Project Methodology (Hybrid Agile-Waterfall Model)
This project will adopt a hybrid methodology to leverage the strengths of both Waterfall
and Agile approaches.
Waterfall Approach (Phases 1, 2, 3, 6, 7): The initial Project Planning, System Analysis,
and System Design phases will be conducted in a linear, Waterfall manner. This ensures
a comprehensive and well-documented foundation, a clear scope, and a robust
architectural design before development begins. The final Implementation and
Maintenance phases are also planned events.
Agile (Scrum) Approach (Phases 4, 5): The Development and Testing phases will be
executed using the Agile Scrum framework. The work will be broken down into a series
of two-week "Sprints." This allows for iterative development, continuous feedback from
stakeholders, flexibility in prioritizing features, and rapid delivery of functional system
components.
1.7. High-Level Project Timeline
Phase Duration Key Deliverable
1. Planning 2 Weeks This Project Documentation (v1.0)
2. Analysis 3 Weeks Finalized User Stories & Requirements
3. Design 3 Weeks Finalized Architecture & UI Mockups
4. Development 16 Weeks (8 Sprints)Functioning System Modules
5. Testing (UAT) 2 Weeks UAT Sign-off
6. Implementation 1 Week Live Deployed System
7. Post-Launch Support Ongoing System Maintenance
2. System Analysis & Requirements (Waterfall Phase)
2.1. Functional Requirements
The system shall allow users to perform actions based on their assigned roles. (Refer to
the detailed role descriptions in the initial prompt).
2.2. User Stories
A selection of high-level user stories that will form the initial product backlog:
As a HQ MEL Officer, I want to create goals, objectives, and initiatives so that the
organization's strategic framework is established in the system.
As a Director, I want to assign an initiative to a specific Coordination Office so that they
can begin their operational planning.
As a CO Head, I want to view all initiatives assigned to my office and assign them to my
branches so that work can be delegated effectively.
As a Branch Head, I want to create a new project plan tied to an assigned initiative so
that I can report my branch's planned activities for the quarter.
As a Deputy CEO, I want to view and approve all HQ-level plans for my department so
that I can provide oversight and ensure alignment with our strategy.
As an Admin, I want to create new users and assign them specific roles for specific
branches or offices so that system access is managed securely.
2.3. Non-Functional Requirements
Performance: All pages must load in under 3 seconds. Database queries for reports must
complete within 10 seconds.
Security: All data transmission must be encrypted via HTTPS. Passwords must be
hashed. The system must be protected against common web vulnerabilities (XSS, SQL
Injection).
Usability: The interface must be intuitive and consistent, requiring minimal training for
computer-literate users.
Scalability: The system must be able to support up to 500 concurrent users without
performance degradation.
Availability: The system must maintain 99.5% uptime.
2.4. System User Roles & Authorizations
The system will use a flexible, context-aware authorization model based on the
assignments table. A user's permissions are determined by the combination of their
assigned role (function) and the specific organizational unit (Department, Coordination
Office, or Branch) they are assigned to. (See Section 3.2 for the data model).
3. System Design (Waterfall Phase)
3.1. Architectural Design
The PMS will be a monolithic web application built on the LAMP/LEMP stack.
Backend Framework: Laravel 11+ (PHP)
Admin Panel/UI: Filament 3
Database: MySQL 8+ or MariaDB 10+
Server: Ubuntu 22.04 on a cloud provider (e.g., AWS, DigitalOcean) or on-premise server.
Code Structure: A Domain-Driven Design (DDD) approach will be used to organize code
into logical business domains (e.g., Headquarters, Branch, Shared).
3.2. Data Design (Entity Relationship Diagram)
The system's database schema is designed for normalization, flexibility, and scalability.
The core of the authorization model is the polymorphic assignments table, which links
users to roles within a specific organizational context.
The complete ERD code is available in Appendix B and can be rendered using a Mermaid
editor.
3.3. User Interface (UI/UX) Design Principles
The UI will be built using the Filament 3 framework, which provides a clean, modern,
and responsive user experience out-of-the-box.
Consistency: All forms, tables, and actions will follow a consistent design pattern.
Clarity: Navigation will be clearly labeled and organized into logical groups based on the
user's role.
Responsiveness: The interface will be fully functional on desktops, tablets, and mobile
devices.
Accessibility: Adherence to basic web accessibility standards will be maintained.
4. Development & Construction (Agile Phase)
4.1. Development Environment & Technology Stack
PHP: Version 8.2+
Dependency Manager: Composer
Frontend Tooling: [Link], Vite
Version Control: Git (hosted on GitLab, GitHub, or Bitbucket)
Local Development: Laravel Herd or Laravel Sail (Docker)
4.2. Sprint-Based Development Process
Product Backlog: All user stories are stored here.
Sprint Planning: At the start of each two-week sprint, the team selects a set of high-
priority stories from the backlog to work on.
Development: The team works on the selected stories.
Daily Stand-ups: A brief daily meeting to discuss progress and roadblocks.
Sprint Review: At the end of the sprint, the team demonstrates the completed work to
stakeholders for feedback.
Sprint Retrospective: The team discusses what went well and what could be improved
for the next sprint.
4.3. Project Folder Structure
The project will follow the Domain-Driven structure previously defined, which
organizes all related code (Models, Filament Resources, Policies) for a business concept
into a single, high-level directory.
5. Testing & Quality Assurance (Integrated Phase)
5.1. Testing Strategy
A multi-layered testing approach will ensure system quality:
Unit Tests (PHPUnit): Developers will write tests for individual functions and methods
to ensure they work as expected.
Integration Tests: Tests will be written to verify that different parts of the application
work correctly together (e.g., a form submission correctly updates the database).
End-to-End (E2E) Tests (Laravel Dusk): Automated browser tests will simulate user
workflows from start to finish.
User Acceptance Testing (UAT): See below.
5.2. User Acceptance Testing (UAT)
Before the final deployment, a select group of end-users from different roles (e.g., a
Branch Head, a CO MEL Officer) will be given access to a staging environment. They will
follow a set of test scripts to confirm the system meets their business requirements. UAT
sign-off is required for go-live.
6. Implementation & Deployment (Waterfall Phase)
6.1. Deployment Plan
Server Provisioning: Set up and secure the production server environment.
Code Deployment: Deploy the final, tested version of the application code.
Environment Configuration: Set up the .env file with production database credentials
and other settings.
Database Migration: Run php artisan migrate to create the database schema.
Data Seeding & Migration: Run seeders to populate lookup tables (Goals, Roles, etc.) and
execute data migration scripts (see 6.3).
Final Smoke Test: Perform a final check on the live system.
Go-Live: Make the system available to all users.
6.2. User Training Plan
Training will be conducted based on user roles:
Admin Training (2 hours): In-depth session for the IT/Admin team on user
management, system configuration, and troubleshooting.
HQ User Training (4 hours): Session for Directors and MEL Officers on creating strategic
frameworks and managing HQ-level plans.
Field User Training (4 hours): Session for CO and Branch level users on creating and
managing their respective operational plans.
Documentation: A concise user manual will be provided for each user group.
6.3. Data Migration Strategy
Existing data from Excel spreadsheets will be migrated into the new system. This will
involve:
Data Cleansing: Standardizing and cleaning the source Excel files.
Data Mapping: Mapping columns from the Excel files to the new database tables.
Scripting: Creating custom Laravel Artisan commands to read the cleaned data and
insert it into the database, respecting all foreign key relationships.
Validation: Verifying the migrated data in the staging environment before running on
production.
7. Maintenance & Support (Post-Launch Phase)
7.1. Support Plan
Level 1 Support: The internal ADA MIS department will be the first point of contact for
user issues like password resets and "how-to" questions.
Level 2 Support: The project development team will handle technical bugs and system
errors.
7.2. System Maintenance & Backups
Daily Backups: The production database will be backed up daily, with backups stored
off-site.
Security Updates: The server and all software dependencies will be regularly patched
and updated.
Monitoring: The system's uptime and performance will be actively monitored.
7.3. Future Enhancements
A backlog for future feature requests (Version 2.0 and beyond) will be maintained.
Potential future enhancements include:
Advanced BI Dashboards and Analytics.
Public-facing reporting portals.
Mobile application for field-based reporting.
8. Appendix
A: Glossary of Terms
PMS: Planning and Monitoring System.
HQ: Headquarters.
CO: Coordination Office.
MEL: Monitoring, Evaluation, and Learning.
UAT: User Acceptance Testing.
Sprint: A two-week development cycle in the Agile Scrum methodology.
B: Full ERD
