9A. Delivery Schedule Realism

Delivery Schedule Realism Overview

3Wrkz believes the requested ~4.5-month implementation window is not realistic for the full Phase 1a scope as currently defined in the RFP materials. This is not primarily a staffing or cost issue. It is a scope-shaping, solution-design, integration-sequencing, and validation-readiness issue.

Based on the current requirements workbook, the Phase 1 effort includes approximately 172 requirements to be addressed within roughly 95 business days across the requested 4.5-month window. That implies an average delivery rate of just under 2 requirements per business day from design through architecture, build, testing, deployment, and go-live readiness. For a program with this level of operational complexity, compliance sensitivity, integration dependency, and cross-module coordination, that pace is not a responsible planning assumption.

Why the Requested Timeline Is High Risk

Several of the required capabilities are individually substantial and cannot be treated as half-day or one-day build items. Examples include:

1. ISO 27001-aligned security and compliance obligations
2. support for dynamic admin-configured assessments
3. app-wide context-aware help
4. electronic invoicing for programs and third-party payers
5. coordinated integrations across finance, routing, reporting, and retained systems

Each of these items carries meaningful analysis, architecture, implementation, validation, and operational-readiness effort on its own. When taken together inside a single implementation window, the risk is not merely that the team must move quickly. The risk is that the team is forced to compress decisions that should be designed carefully, validated early, and integrated deliberately.

Why Team Size Alone Does Not Solve the Problem

The delivery challenge is not solved simply by adding more developers. The RFP scope contains several parallel workstreams, but those workstreams do not start from a state of complete functional clarity. Important workflow, data, integration, reporting, and operational details still need to be shaped during early discovery and solution design.

That means the critical path is heavily influenced by shared design time:

1. the teams must align on a common operational model
2. the data, workflow, security, and integration boundaries must be defined before parallel delivery can safely accelerate
3. the parallel workstreams must still converge into one coherent platform at the API, data, reporting, and user-experience levels

As Brian Davis noted during planning, all teams effectively need to share a single brain for the implementation to work. In practical terms, that means architecture and product-definition work must lead the build, not trail behind it.

Design and Integration Are the True Schedule Constraint

This project includes multiple interconnected solution areas that must fit together cleanly: intake and referrals, assessments and care planning, scheduling and routing operations, billing, reporting, security, migration, and external integrations. Those areas can eventually be built in parallel, but they cannot be designed independently without creating significant rework and integration risk.

Before broad parallel execution begins, the project must establish:

1. a confirmed solution baseline for workflows, roles, and business rules
2. a stable application and data architecture
3. an agreed integration strategy and interface model
4. clear ownership of shared entities and process handoffs
5. realistic validation and go-live criteria

Without that foundation, adding more delivery teams increases coordination cost and defect risk faster than it increases safe throughput.

3Wrkz Position and Recommendation

3Wrkz therefore recommends that the requested 4.5-month timeline be treated as an aspirational target rather than a full-scope contractual assumption. A responsible implementation posture should use one of the following approaches:

1. reduce the initial committed scope to a narrower and clearly bounded go-live baseline that can credibly fit inside the requested window
2. preserve the current scope breadth, but allow a longer implementation schedule after discovery and solution-baseline confirmation

3Wrkz is prepared to mobilize quickly, run discovery with urgency, and structure the delivery team for parallel execution where appropriate. However, we do not believe it would be responsible to represent the entire current Phase 1 scope as safely deliverable within 4.5 months regardless of team size or cost.

Proposed Proposal Framing

For proposal purposes, 3Wrkz should position the schedule as follows:

1. the requested timeline is aggressive and materially high risk for the current scope volume and complexity
2. final committed delivery dates should be confirmed after early discovery, architecture definition, and implementation planning
3. if VNA requires the 4.5-month date to remain fixed, the initial production scope should be reduced to a smaller and explicitly prioritized subset
4. schedule credibility should be based on readiness gates and validated scope decisions, not calendar compression alone

This position is intended to be realistic, not resistant. The goal is to protect VNA from a schedule commitment that creates avoidable rework, quality issues, and go-live risk later in the project.