Software Delivery Program Review and Architecture Audit for a US MVNO With 500,000 Subscribers

About Our Client

The Client is a fast-growing US-based mobile virtual network operator serving more than 500,000 subscribers nationwide.

10-Year-Old Software Delivery Program Began to Show Structural Risks

For over 10 years, the Client had been running a software delivery program that included five projects and involved more than 20 IT specialists. The program supported several core customer-facing systems, enterprise platforms, and integration solutions. The teams were experienced, had worked together for years, and the setup was considered stable and well-controlled.

However, over time, management began to question whether the software delivery program’s stability was structurally sustainable and scalable, or whether it had gradually become dependent on informal practices and the knowledge of specific key individuals. With long-standing teams, such dependencies can form naturally, but they may create hidden operational risks.

Additionally, the Client was concerned that delivery predictability had declined. While releases continued, schedules became harder to forecast, dependencies became less transparent, and recurring bottlenecks appeared without clear ownership. It was unclear whether these delays were isolated or systemic.

Finally, the Client also wanted to understand whether the software delivery program was operating at its full potential. The Client believed that delivery automation, architecture improvements, and AI adoption could bring significant value, but lacked objective data to determine where and how these improvements could be introduced safely.

Taken together, these concerns led the Client to initiate a comprehensive audit of the software delivery program to validate its structural soundness, identify systemic risks, and uncover practical opportunities for improvement.

Dual-Track Audit to Assess Delivery Maturity and Technical Health

To conduct an objective assessment, ScienceSoft assembled a focused audit team of four senior specialists: two delivery managers, a principal architect, and a solution architect. They were intentionally brought in as an independent group, without any prior exposure to the project context.

The team conducted a parallel two-track audit combining delivery analysis with deep technical assessment. Delivery managers examined project management practices and team efficiency, while architects assessed architecture, system dependencies, and technical constraints.

The audit prioritized value over blame. The team didn’t call out individuals — instead, they identified process gaps and offered actionable ways to improve efficiency.

Delivery Audit With Actionable Recommendations for Greater Transparency, Predictability, and Team Efficiency

The delivery audit evaluated how effectively the project was being run and identified inefficiencies that affected speed, quality, or clarity.

Team morale and communication

The delivery managers used structured, anonymous surveys to assess team morale, alignment on goals, and pain points in daily delivery (e.g., delayed approvals, unclear ownership) without bias. Additionally, the auditors participated in daily stand-ups, backlog refinement sessions, and stakeholder synchronization meetings to observe real communication dynamics and decision-making workflows. The analysis revealed:

• Overloaded communication channels and unclear escalation paths.
• Formalized retrospectives that limited open feedback and improvement initiatives.
• Inefficient meeting structures, including daily one-hour sessions with more than 20 participants and low engagement from the majority of attendees, and more.

To address these challenges, the auditors recommended several changes, including splitting the oversized Scrum team into smaller, system-focused teams with clear Product Owner responsibilities, introducing systematic backlog refinement, and adding a lightweight Scrum-of-Scrums layer to streamline cross-team coordination. Meeting practices were also optimized by reducing unnecessary participants and following a structured format. For example, during daily stand-up, each team member gives a brief status update and notes any questions or blockers; if no one has questions for them, they leave, while all questions are discussed after the updates.

Process standardization and knowledge management

The delivery managers reviewed release and sprint planning artifacts (roadmaps, backlogs, sprint goals), change management records and incident reports, operational runbooks and escalation procedures, testing documentation (including regression testing scope and coverage), knowledge base, and onboarding materials. Key findings included:

• Documentation formats varied across projects, and knowledge was stored in multiple disconnected repositories.
• Backlog items often lacked sufficient business context, making requirements harder to interpret.
• Jira tickets frequently lacked clear acceptance criteria; Confluence documentation had unclear dependency mapping and navigation gaps.
• Team velocity was measured inconsistently, masking capacity constraints.
• New features or changes were added late in the release cycle, leaving the QA team with less time than planned to test everything properly. As a result, they had to test more work in less time, which increased pressure and the risk of missed defects.

Collectively, these issues significantly extended the time required to onboard new developers, increased rework, and weakened delivery predictability.

To address these challenges, the auditors recommended multiple improvements, including a new task description and acceptance criteria format, clearer prioritization rules, and a redesigned Jira setup — covering boards, workflows, and automation.

Knowledge dependency and skill distribution

Through interviews and workload analysis, the delivery managers found that critical system knowledge was concentrated within a small group of senior developers, creating single points of failure and contributing to delivery bottlenecks. The absence of an intermediary role between the business and engineers reinforced this dependency, as senior developers were often required to clarify and explain undocumented business logic for the product owners and business stakeholders.

At the same time, these senior developers were frequently overloaded with mentoring responsibilities and unplanned scope changes. This combination increased their workload, added avoidable delivery overhead, and highlighted gaps in shared domain understanding.

To address knowledge gaps and role ambiguities, the auditors first captured existing responsibilities in as-is RACI charts. They then designed to-be RACI charts to define optimal responsibilities, accountabilities, and consultation paths. Complementing this, they suggested creating targeted documentation, maintaining a change log, introducing a business analyst role, and more, to strengthen knowledge sharing and reduce reliance on a few key developers.

Technical Audit: Identifying Systemic Barriers to Scalability, Reliability, and Innovation

The technical audit focused on uncovering architectural, infrastructure, and engineering practices that limited the agility, operational stability, and modernization readiness of systems.

Architecture and infrastructure assessment

The audit team began by mapping core software components, data flows, and integration points. Then they moved on to a detailed assessment of the systems' architectural and engineering health. Auditors assessed the number of modules, clarity of boundaries between components, distribution of responsibilities, architectural patterns used, legacy and aging components in place, service coupling levels and dependencies, functional consistency across system components, and alignment of the technology stack with current business needs. For example, the auditors found that the current enterprise architecture — a synchronous, request-driven architecture — limited experimentation and slowed the adoption of new practices. To address this and improve scalability, flexibility, and speed of change, the team recommended moving toward an event-driven architecture.

The team also evaluated the maturity of key technical domains — cloud and hosting, infrastructure, databases, back-end and front-end code, integrations, and CI/CD pipelines — using a five-level scale. Based on these findings, they developed a structured modernization roadmap with iterative steps to advance each domain toward higher maturity.

AWS usage assessment

The audit team used AWS Cloud Readiness Assessment Framework and AWS Well-Architected Framework to review the Client’s current AWS environment and on-premises infrastructure. The goal was to identify ways to use the cloud more efficiently, estimate migration costs, and uncover obstacles that could slow or complicate cloud-native transformation, such as monolithic dependencies and hard-coded configurations. Based on this analysis, the team outlined practical modernization options to support smoother, faster, and more scalable cloud adoption.

Code quality and maintainability analysis

The team conducted a deep dive into representative code modules, analyzing complexity, dependencies, testing coverage, and error handling, with a focus on historically incident-prone areas. This analysis helped identify high-risk code areas and opportunities to improve long-term maintainability and reduce production incidents. The team used technical debt heat mapping and dependency visualization to identify modules that had the greatest cross-system impact. This allowed them to prioritize modernization initiatives based on risk and ROI, rather than pursuing costly full-scale rewrites.

DevOps and QA maturity evaluation

The audit team reviewed CI/CD pipelines, branching strategies, deployment and rollback procedures, testing practices, and overall delivery reliability.

While deployments were partially automated, release stability and predictability remained limited. Automated processes still depended heavily on manual and incomplete regression testing, which reduced confidence in release quality and increased operational risk. Builds and tests were not parallelized, slowing feedback and extending the time it took for fixes to propagate to production. The absence of blue-green deployments and underdeveloped rollback procedures further increased the risk of downtime and production failures, as there was no safe, rapid recovery path.

The auditors also identified major gaps in automated testing coverage. Critical layers — including end-to-end, API, performance, capacity, and security tests — were largely not covered by automation. This limited the Client’s ability to detect system-wide issues early and slowed down safe release cycles. Testing teams also lacked independent deployment capabilities, adding further delays.

In addition, the Client’s IT team wasn’t tracking key DevOps performance metrics (e.g., deployments frequency, lead time for changes, change failure rate, and time to restore services), reducing visibility into pipeline efficiency, failure trends, and overall delivery health.

Support, monitoring, and operational resilience

The audit team examined support processes and observed that many L1 tickets were frequently escalated directly to developers, reducing their productivity. The auditors also identified gaps in IT systems monitoring, which relied on disconnected tools and focused mainly on technical metrics while missing business indicators (e.g., transaction errors), SLA tracking, and proactive performance monitoring. Additionally, the team found that several cloud resources (e.g., Kubernetes), could be used more efficiently, contributing to better FinOps practices.

Technical documentation quality

The audit team reviewed architecture decision records, API documentation, system diagrams, and onboarding guides. They discovered outdated and fragmented documentation that increased onboarding time and complicated troubleshooting.

Clarity, Risk Transparency, and a Practical Phased Recovery Roadmap

Within one month, the Client received a 40-page assessment of the state of its software delivery program and its improvement opportunities. The audit provided:

• A clear picture of the program’s health, highlighting strengths and weaknesses in the delivery pipeline, processes, and technology.
• Improvement areas and actions, with observable problems (symptoms) clearly distinguished from their underlying root causes, and all items prioritized by impact. Key technical issues included legacy components, outdated libraries, limited observability, insufficient cloud adoption, and weak FinOps practices. Among process-related issues were inefficient release cycles and suboptimal meeting structures.
• Structured risk assessment. ScienceSoft categorized project risks by criticality, evaluated potential business consequences of inaction, and proposed mitigation strategies. The most critical risks involved scalability limitations, cost inefficiencies, and unpredictable delivery timelines.
• Three practical recovery and improvement scenarios. Each scenario came with estimated costs and expected outcomes:
  • Immediate actions (0–30 days) to stabilize delivery and address the most critical risks.
  • Mid-term improvements (up to 4 months) to remove systemic bottlenecks and improve predictability.
  • Strategic initiatives (up to 8 months) to modernize engineering and delivery practices, reduce knowledge dependency, and improve long-term efficiency.
• Detailed implementation advice. For example, the guidelines included:
  • Clear recommendations for testing (tools, test types, coverage targets, metrics, and expected outcomes).
  • Structured communication plans (meeting cadence, formats, and stakeholders).
  • Standardized documentation practices (naming conventions, version control, templates, and Jira knowledge base structure).
  • An architectural roadmap outlining a safe, efficient, and scalable path for improvement, including proposed architecture diagrams and a practical migration schedule.
• AI enablement strategy. The audit team identified practical use cases where AI could improve customer experience and operational efficiency, evaluated implementation complexity, recommended suitable tools, and forecasted the adoption timelines. The priority use cases included predictive analytics for anomaly detection and cloud resource optimization, conversational AI solutions to automate FAQs and user onboarding, and generative and agentic AI capabilities to deliver more personalized experiences across the Client’s products and services.

As a result, the Client gained decision-ready insights, a shared understanding across stakeholders, and a realistic, phased path forward, without disrupting ongoing operations.

Techniques and Methodologies

Stakeholder and development team interviews, one-to-one sessions with key project players, Scrum ceremony observation, documentation analysis, delivery process assessment, KPI and metrics analysis, codebase and architecture assessment, and risk modeling.

Frameworks and Standards

AWS Cloud Readiness Assessment Framework, AWS Well-Architected Framework.