From foundations to fixes, this is how production, dedicated, and support teams shape the software development life cycle (SDLC) across enterprise projects.
In large-scale enterprise environments, software development is never one-size-fits-all, and neither is the way teams interact with the Software Development Life Cycle. For a project manager, one of the most critical (and often underappreciated) aspects of the role is understanding how different teams experience and influence the SDLC and how that disparity impacts delivery, collaboration, and outcomes.
This blog provides insights into how SDLC practices and visibility vary across three common types of teams in enterprise settings: the Dedicated Development Team, the Production Team, and the Support Team. Each works under very different conditions, and Project Managers adjust their approach to ensure efficiency and cohesion across these teams.
What is SDLC in the Enterprise Context?
The Software Development Life Cycle (SDLC) is the structured process enterprises use to build, test, deploy, and maintain software. Whether the team follows Waterfall, Agile, SAFe, or hybrid models, SDLC provides a repeatable framework for delivering value.
But here’s the catch: not all teams interact with the SDLC in the same way. In fact, many enterprise teams operate with vastly different levels of access to documentation, decision-making power, and process transparency.
Team 1: The Dedicated Development Team
“We build and evolve projects, but we follow the client’s playbook.”
What they do:
These are skilled development teams with access to client documentation and processes. They are responsible for building new features, maintaining modules, and launching new projects. However, while they operate within the defined SDLC of the client, they are often not decision-makers in how that process is structured.
More examples of our Dedicated teams and how they operate can be found in the case studies:
- Digital-first pension and investments platform
- The Sun Dedicated Team
- Web platform for financial support and advice
- Custom web platform for travel enthusiasts
Project Manager’s perspective:
- These teams can deliver efficiently, but they rely heavily on well-maintained documentation and external guidance.
- They’re often constrained in proposing SDLC improvements — even when they identify clear gaps or inefficiencies.
- They execute well, but there’s a ceiling to their influence.
Key strategies for the Project Manager:
- Encourage feedback loops to capture recurring process pain points.
- Maintain a structured knowledge base and update it regularly — treat documentation as a first-class citizen.
- Establish regular alignment sessions with client-side product owners or architects to close the gap between execution and intent.
Team 2: The Production Team
“We define, build, and shape the process.”
What they do:
Production teams are responsible for developing solutions from the ground up. They typically have a clear understanding of the SDLC, collaborate closely with architects and stakeholders, and are empowered to influence and adapt the process itself.
Case studies for our production teams are available on these links:
- Digital transformation of the leading global supplier in the energy industry
- Developing a web platform for 10+ million users
- Building the website and mobile app for the world’s premier luxury destination
Project Manager’s perspective:
- This is where true agility and innovation can thrive — if properly supported.
- These teams are capable of piloting new tools (e.g., automated testing, CI/CD) and refining ceremonies (e.g., retros, backlog grooming).
- The risk? Without strong guidance, they can fall into “process tinkering” without clear alignment to business goals.
Key strategies:
- Reinforce process ownership: empower the team to evolve the software development life cycle, but tie improvements to measurable outcomes (e.g., velocity, cycle time).
- Encourage experimentation, but always collect and review metrics to validate impact.
- Align their evolution with enterprise goals (security, compliance, scalability), ensuring innovation doesn’t become siloed.
Team 3: The Support Team
“We’re the firefighters — but don’t ask us how the building was made.”
What they do:
Support teams work on post-launch issues and smaller updates: bug fixes, hot patches, and minor enhancements. They usually don’t have deep visibility into the client’s SDLC, and have limited context on design decisions or architectural choices. This is why the handover process from a Dedicated or Production team is crucial for the Support team, especially for big milestone decisions such as scope, architecture and release limitations.
Examples of projects that were handed over to support teams after a successful production launch are available in the following case studies:
- Drug shortage tracking app
- Mobile and Web App for a Training Community
- New website for luxury car dealership
Project Manager’s perspective:
- Their work is reactive, time-sensitive, and high-pressure — but not always respected as “strategic.”
- They operate with limited traceability and process alignment, often juggling incomplete or undocumented legacy code.
- SDLC for them is less a lifecycle and more a series of disconnected support tickets.
Key strategies:
- Implement lightweight SDLC artefacts (e.g., templates for fixes, root-cause-analysis logs, regression checklists).
- Suggest documentation backflow — when support teams resolve issues, they should contribute back to the documentation or internal wiki.
- Advocate for support teams to be included in retrospectives or postmortems, giving them a voice in the client’s process evolution.
Comparing Realities: Best Practices, Pain Points, Similarities & Differences
For project managers, understanding the nuances between teams is key to managing expectations, improving collaboration, and delivering consistent results. Below is a breakdown of best practices, common challenges, and key comparisons between the three teams.
Best Practices by Team
| Team | Best Practices |
| Dedicated Development | – Maintain up-to-date documentation and onboarding material. – Conduct regular sprint reviews and demos to stay aligned with the client. – Foster feedback loops even without direct decision-making control. – Use internal retrospectives to improve process adherence. |
| Production | – Invest in automation early (CI/CD, test pipelines). – Use iterative planning and retrospectives to fine-tune the SDLC. – Include business and technical stakeholders in backlog grooming. – Pilot new SDLC improvements and document outcomes. |
| Support | – Implement RCA (Root Cause Analysis) templates and maintain an issue resolution log. – Prioritise backlog hygiene and ticket quality. – Establish clear SLAs and incident response processes. – Share knowledge with the Dedicated/Production teams. |
Common Pain Points
| Team | Pain Points |
| Dedicated Development | – Limited visibility into broader product goals or business logic. – Dependency on the client for clarity, often leading to delays. – Misalignment between internal agile execution and external waterfall planning. |
| Production | – Risk of over-engineering or process bloat. – Balancing agility with governance in large enterprise settings. – Managing early-stage uncertainty while building scalable solutions. |
| Support | – Limited system context or rationale behind legacy decisions. – Pressure to fix issues without comprehensive documentation or access to source teams. – Reactive workload with little room for process improvement. |
Key Differences Across Teams
| Team Type | SDLC Visibility | Process Influence | Work Nature | Stakeholder Access | Documentation Use |
| Dedicated Dev | Moderate (execution-focused) | Limited | Feature-driven, planned | Indirect | Consumes and maintains |
| Production | High (participates in definition/evolution) | Significant | Visionary, structured planning | Direct (shapes requirements) | Creates foundational docs and standards |
| Support | Low (isolated from origin) | Very limited | Reactive, issue-driven | Minimal | Lacks or builds ad-hoc |
What about similarities across teams?
Despite their different roles, these teams share some common traits:
- Need for Clarity: Whether it’s fixing a bug or launching a new product, all teams depend on clear documentation and requirements.
- Reliance on Collaboration: Success hinges on effective communication with adjacent teams (developers, SA, QA, DevOps, Business Analysts, etc.).
- Desire for Impact: Even support teams want to know their work contributes to the product’s evolution — not just firefighting.
- Tool Overlap: Most teams work within the same tooling ecosystem (e.g., Jira, Git, CI/CD systems), though their usage varies.
The Project Manager’s Role: Bridging the SDLC Divide
When managing cross-functional teams in an enterprise environment, Project Manager’s role becomes more than just a schedule-keeper. The Project Manager becomes a process interpreter and unifier.
A way to approach:
| Team | Visibility | Influence | PM’s Role |
| Dedicated | Moderate | Low | Advocate for clarity, sync, and inclusion in planning. |
| Production | High | High | Facilitate experimentation, validate process improvements, align with business value. |
| Support | Low | Minimal | Provide structure, push for documentation, and structure the handover session to give as much information about the project and client. |
In all cases, Project Manager’s goal should focus on answering the following:
“How can I make this team’s work more visible, more valuable, and more connected to the enterprise mission?”
One SDLC, Many Journeys
As project managers, our job isn’t just to enforce a process — it’s to make the process meaningful and accessible to everyone. That means:
- Helping dedicated teams understand their influence beyond code.
- Supporting production teams in building scalable, modern, and flexible SDLC frameworks.
- Providing support teams the tools and voice to operate with intent.
When tailoring the approach to each team’s reality, Project Managers do more than deliver projects. They build sustainable systems of delivery.
Project Managers can’t manage what they don’t understand — and no two teams live the SDLC the same way
So it is important to walk in the team’s shoes.
- Let the dedicated team raise what they’d do differently.
- Empower the production team to shape the process, not just follow it.
- Set clear expectations with the client before the handover to the support team.
Because when teams align these realities, Project Managers don’t just manage projects better. They create systems that support humans, not the other way around.
Give Kudos by sharing the post!
ABOUT AUTHOR
Ana Cerimovic
Project Manager & Project Delivery Team Lead
