City of Prince Albert - NRFP for ERP Solution and Implementation Services.pdf

NimbleStride Inc. is prepared to submit via any method acceptable to the City of Prince Albert / Cascadia Partners. If the complete proposal package exceeds email size limits, we request confirmation that a secure file-transfer link (e.g., WeTransfer, SharePoint, or equivalent) will be accepted in lieu of or in addition to email submission.

Mohammed Yousuf Shariff will serve as the dedicated Project Manager for this engagement, providing direct, accountable leadership across all phases — discovery, configuration, data migration, testing, training, go-live, and stabilization — leveraging his SAFe SPC 6, CSM, and PRINCE2 credentials and 17+ years of enterprise program delivery experience.

Following go-live, NimbleStride will provide a dedicated hypercare period of four (4) weeks during which the project team remains on-call (remote, with on-site availability upon request) to resolve issues in real time. Go/no-go criteria include: successful parallel-run reconciliation, completion of user-acceptance testing with sign-off, and zero open P1 defects. During hypercare, issues are classified as P1 (system down / critical business process blocked — 2-hour response, same-business-day resolution target), P2 (major function impaired — 4-hour response, 2-business-day resolution), and P3 (minor issue / workaround available — next-business-day response). Transition from hypercare to standard SLA-based support is triggered by 10 consecutive business days with no P1 or P2 incidents and formal written acceptance by the City's project sponsor.

Post-stabilization support is provided through a two-layer model: (1) the SaaS platform vendor's standard support agreement (including automatic updates, patch management, and platform SLAs) is assigned or passed through directly to the City; and (2) NimbleStride provides a managed application-support wrapper covering configuration changes, user queries, report development, and integration monitoring under a defined SLA — P1: 4-hour response / 1-business-day resolution; P2: 1-business-day response / 3-business-day resolution; P3: 3-business-day response / 10-business-day resolution. All hosting and infrastructure is managed by the SaaS vendor within Canadian data-residency boundaries; NimbleStride coordinates vendor escalations on the City's behalf.

NimbleStride Inc. and MGR Infotech confirm that, to the best of their knowledge, no actual, potential, or perceived conflict of interest exists with respect to this procurement. Neither entity, nor principal Mohammed Yousuf Shariff, holds a current employment, financial, or familial relationship with any employee or elected official of the City of Prince Albert that could improperly influence the award or delivery of this contract. Should any conflict arise during the engagement, NimbleStride Inc. commits to disclosing it immediately in writing to the City's designated Contract Authority and cooperating fully with any required mitigation measures.

NimbleStride Inc. understands that the City of Prince Albert (population ~37,000) is seeking to replace or significantly modernize its current ERP environment to consolidate fragmented systems and improve operational efficiency across core municipal functions including Finance, HR/Payroll, Procurement, Asset Management, Permitting/Licensing, and Utility Billing. The City's objectives — as understood from the NRFP — include reducing manual processes and data silos, improving reporting and decision-support, enabling self-service for staff and citizens, and ensuring a scalable, supportable platform for the long term. The initial implementation scope covers the core functional modules identified in the City's ERP Requirements Form, with additional modules (e.g., Permitting, GIS integration) treated as optional or future-phase deliverables consistent with the City's phasing preferences.

NimbleStride Inc. proposes a structured, five-phase implementation approach: (1) Discovery & Planning — stakeholder workshops, current-state process mapping, requirements validation, data-audit, and finalization of the project charter and detailed work plan; (2) Configuration & Development — platform configuration by module, integration build, and iterative review sessions with City subject-matter experts; (3) Data Migration — data cleansing, mapping, migration scripting, and parallel-run validation to ensure data integrity at go-live; (4) Testing & Training — system integration testing (SIT), user acceptance testing (UAT) with City staff, defect remediation, and role-based end-user training delivered in-person and via recorded materials; (5) Go-Live & Stabilization — cutover execution, hypercare support for 60–90 days post-go-live, knowledge transfer, and transition to steady-state support. Each phase concludes with a formal sign-off milestone before the next phase begins.

NimbleStride Inc. applies Agile principles within a structured ERP delivery framework, led by Mohammed Yousuf Shariff (SAFe SPC 6, CSM, PRINCE2). Configuration and testing work is organized into two-week sprints, each producing a demonstrable, tested increment of configured functionality reviewed by City subject-matter experts at a sprint review. City staff are embedded as product owners for each functional area (Finance, HR, etc.), ensuring requirements are validated continuously rather than at the end. A Definition of Done for each sprint requires: configuration complete, unit-tested, integrated with adjacent modules, and signed off by the City SME. Change requests are managed through a lightweight change-control board meeting bi-weekly, keeping scope, schedule, and budget transparent throughout. Training materials are developed iteratively alongside configuration so that end-user readiness keeps pace with system readiness.

The proposed governance model includes: (a) Steering Committee — City CAO or designate, City CFO, and NimbleStride Principal (Mohammed Yousuf Shariff), meeting monthly to review progress, resolve escalations, and approve scope changes; (b) Project Management — NimbleStride Project Manager (Mohammed Yousuf Shariff / named associate) and City-side Project Coordinator meet weekly; (c) City-Side Responsibilities — designated SMEs per functional area, timely UAT participation, data-cleansing ownership, and IT environment access; (d) Escalation Path — operational issues resolved at PM level within 5 business days; unresolved issues escalated to Steering Committee within 10 business days; (e) Status Reporting — bi-weekly written status report covering RAG status, milestone progress, risks/issues log, and budget burn; (f) Change Control — all scope changes documented on a Change Request form, impact-assessed, and approved by both the City Project Coordinator and NimbleStride PM before work proceeds; (g) Risk & Issue Management — a live RAID log (Risks, Assumptions, Issues, Decisions) maintained by the NimbleStride PM and reviewed at every weekly meeting.

Needs_input note: A credible ERP data migration strategy requires knowing the specific ERP platform being proposed and the City's current source systems (e.g., legacy finance, HR, payroll, utility billing). However, a framework answer is provided below as a starting point. Our data migration strategy follows five phases: (1) Discovery & Inventory — catalogue all source systems, data entities, volumes, and data-quality issues in collaboration with City staff; (2) Data Mapping & Cleansing — map source fields to target ERP schema, define transformation rules, and cleanse/de-duplicate records before migration; (3) Migration Tooling & Trial Runs — use the ERP vendor's native migration utilities or ETL tooling (e.g., Azure Data Factory or equivalent) to execute at least two full trial migrations in a non-production environment, validating record counts and business rules; (4) Parallel Validation — City staff reconcile migrated data against source-system reports for key entities (chart of accounts, vendor master, employee records, open transactions) before cutover approval; (5) Cutover & Freeze — a defined data-freeze window is agreed with the City, final delta migration is executed, and a signed data-acceptance sign-off is obtained before go-live. All migration scripts and mapping documentation are delivered as project artifacts.

Our ERP testing approach is structured across four layers: (1) Configuration Testing — each configured module (GL, AP, AR, Payroll, HR, etc.) is tested against documented business rules immediately after configuration, with defects logged and resolved before progressing; (2) Integration Testing — all interfaces between the ERP and external systems (banking, GIS, utility billing, reporting) are tested end-to-end using realistic data volumes, with pass/fail criteria defined in an Integration Test Plan; (3) User Acceptance Testing (UAT) — City staff execute scripted test scenarios mapped to their day-to-day processes across all in-scope modules; a UAT coordinator from our team supports City testers, tracks defects in a shared register, and obtains formal sign-off before go-live; (4) Performance Testing — load and stress tests are run against the hosted environment to confirm response times meet agreed SLAs under peak concurrent-user conditions; (5) Regression Testing for Updates — a regression test suite is maintained and executed against each vendor patch or upgrade in a staging environment before promotion to production, protecting configuration and integrations from unintended changes.

Our training approach covers six elements: (a) Training Needs Assessment — at project outset we conduct a structured TNA with department leads to identify user roles, current skill levels, and module-specific learning objectives; (b) Role-Based Curriculum — training is organized by role (e.g., Finance Clerk, Payroll Administrator, Department Manager, System Administrator) so each group receives only the content relevant to their daily tasks, reducing time away from operations; (c) Delivery Format — we offer a blended model: live instructor-led sessions (virtual or on-site in Prince Albert, per City preference) for initial training, supplemented by recorded walkthroughs hosted on a shared drive or LMS for ongoing reference; (d) Training Materials — we deliver quick-reference cards, step-by-step process guides, and annotated screenshots for each role; all materials are provided in editable formats so the City can update them after future upgrades; (e) Train-the-Trainer — we identify and train a small cohort of City 'super users' who receive deeper system knowledge and can support colleagues post-go-live, reducing dependency on the implementation team; (f) Post-Go-Live Refresher Training — scheduled refresher sessions at 30 and 90 days post-go-live address questions arising from live use, and additional sessions are provided when major vendor updates are applied.

Our go-live approach uses a phased cutover model: (1) Go/No-Go Criteria — a formal checklist (UAT sign-off, data migration validation, integration smoke tests, training completion, support model activated) must be satisfied before cutover is authorized; (2) Cutover Plan — a detailed, hour-by-hour cutover runbook is prepared and rehearsed in a dress-rehearsal run at least two weeks before go-live, identifying rollback triggers and responsible owners; (3) Cutover Window — the production cutover is scheduled during a low-activity period (e.g., after month-end close) to minimize operational disruption; (4) Hypercare Period — the implementation team provides on-site or dedicated remote support for a minimum of 10 business days post-go-live, with same-day response to critical issues; (5) Rollback Plan — a documented rollback procedure is maintained so that, if critical issues arise during cutover, the City can revert to legacy systems with minimal data loss; (6) Stakeholder Communication — a go-live communication plan notifies all affected City staff and external parties (e.g., banking partners) of the transition timeline and support contacts.

Post-stabilization support is structured across three tiers: (1) Stabilization Support (Days 1–60 post-go-live) — dedicated hypercare support with defined SLAs: Critical (system down) — 2-hour response, 4-hour resolution target; High (major function impaired) — 4-hour response; Medium/Low — next business day; (2) Ongoing Managed Support — after stabilization, a retainer-based support model provides a defined number of monthly support hours for break-fix, configuration adjustments, user queries, and minor enhancements, with unused hours rolling forward or reconciled quarterly; (3) Vendor Patch & Upgrade Management — our team coordinates with the ERP vendor on scheduled releases, executes regression testing in staging, and promotes approved updates to production with City sign-off; (4) Escalation Path — issues beyond our resolution scope are escalated directly to the ERP vendor's support tier under the City's software maintenance agreement, with our team acting as the City's advocate; (5) Knowledge Transfer — all support runbooks, configuration documentation, and known-issue logs are maintained in a shared repository accessible to City IT staff, supporting eventual in-house capability. [PROVIDE: confirm the City's preferred support-hours window (e.g., 8 a.m.–5 p.m. CST, Monday–Friday) and whether after-hours on-call coverage is required, so SLA commitments can be priced accurately.]

Mohammed Yousuf Shariff will serve as Project Manager and Solution Architect for this engagement, providing direct leadership across both delivery governance and technical solutioning. He will be available at a minimum of 80% dedication during active project phases (Discovery, Design, Build, UAT, Go-Live) and 50% during stabilization and support. He is based in Chestermere, AB, and is available to travel to Prince Albert, SK for key on-site milestones (kick-off, UAT, go-live) as required by the City. [PROVIDE: confirm whether the City requires a named on-site presence in Prince Albert for the duration of the engagement, and the expected project start date, so availability can be formally confirmed.]