How to TMP in SDLC?

In the dynamic world of software development, the Software Development Life Cycle (SDLC) serves as a fundamental framework, transforming an idea into a product through a step-by-step process that is iterative and adaptive.

This article provides an overview of each SDLC phase, with a focus on the Technical Project Manager (TPM) role. Within each phase, highlights and insights will be presented about the TPM’s responsibilities and how to drive the process toward successful software delivery.

Consider the flow of building a model airplane as an analogy to the SDLC approach. It begins with an idea or concept, followed by meticulous planning around the airplane’s execution process and functionalities. Next, a design is drafted, detailing the structure and components. Once finalized, the construction starts, involving shaping and assembling the pieces. Then, the airplane is subjected to inspection and testing for fit and functionality. If there are any issues, adjustments or changes are made. Upon achieving satisfaction with the completed airplane, it’s then presented, and ready to be used. The model airplane is consistently refined with repairs, enhancements, and additional new features, all driven by ongoing feedback and evolving ideas.

Software Development Life Cycle (SDLC) is a structured framework divided into six phases: planning, design, development, testing, deployment, and maintenance. SDLC is the key engineering process that makes the company’s product progress.

Within this framework, the Technical Project Manager (TPM) plays a critical and irreplaceable role. The TPM is responsible for overseeing and managing the SDLC. While the execution of individual phases is managed by Product Operations or Technical Lead, the TPM’s responsibilities include:

1. Progress and Visibility — maintaining and enforcing the SDLC process through progress reviews and regular meetings. Managing dashboards that track and display feature progression through the SDLC stages.

2. Phase Transition and Approval — monitoring compliance with phase transition criteria by defining necessary input and output requirements. Establishing approval gates and communicating protocols, determining who must approve changes and who should be informed during these transitions.

3. Implementation — implementing and leading the SDLC framework and best practices within the organization. Defining and communicating clear roles and responsibilities (R&R), choosing and utilizing tools for documenting features, and breaking them into epics and stories. In addition to ensuring that every stakeholder knows their accountabilities throughout the various phases of the SDLC.

4. Process Enhancement — continuously pursuing the ongoing improvement of the process, and workflow and methodically advancing, and consistently evolving with the maturity of the organization’s SDLC.

Planning & Analysis

This phase, the first and most integral part of the cycle, is primarily carried out by Product Operations. It entails an in-depth business analysis, gathering customer requirements, and understanding their expectations. Detailed discussions are conducted based on the customer’s feedback, competitor analysis, and other relevant business reports, involving teams and stakeholders. In this phase, the Product department\ Operations, architects, and technical leads collaborate to define system specifications, assess technical complexity, and determine the system’s intended functionality. This includes considering aspects of the product’s interface design, addressing high-level time estimations and the team’s technical capacity verifying that they have the necessary expertise to deliver. All these elements are documented in the Product Requirements Document (PRD).

The TPM’s responsibilities are:

1. Setting in motion the analysis process and guaranteeing that all necessary stakeholders are involved in the requirement-gathering meetings.
2. Ensuring that the outcomes of the planning, including the product vision and all its elements, are approved by relevant stakeholders, along with the technical representative who has been predefined, before moving on to the next phase.
3. Facilitating communication and document requirements.
4. Making sure that the Software Testing Life Cycle (STLC) is aligned with the requirements.

Challenges: Balancing ideal product planning with execution limitations, managing conflicts and dependencies between teams, ensuring clear and testable requirements, and breaking down planning into appropriate phases.

Design

Based on the requirements gathered, the software architects or senior tech leads will create the system design following the Product Requirements Document (PRD) from the previous phase. The system design outlines the system’s architecture, the user interface design, and the testing strategy. All details from the design phase are documented within the Design Document Specification (DDS).

The TPM’s responsibilities are:

1. Ensuring that the design phase advances according to plan despite the TPM typically being outside the direct design discussions.
2. Communicating clearly that if a Proof of Concept (POC) could validate the project’s direction or technical feasibility, it is the TPM’s responsibility to allocate development teams accordingly. This includes positioning the POC within the sprint planning process and treating it as a standard development task.
3. Collaborating with designers, architects, developers, and stakeholders to secure approval for the design. Additionally, confirming that the technical design receives approval from Product, Support, and all other relevant stakeholders proceeding to the next phase.
4. Confirming that the Design’s outcome is well-defined epics with associated user stories, complete with acceptance criteria, high-level estimations, and team assignments.

The TPM should have a clear understanding of the expected results from the team’s involvement and the level of effort required for each task. To achieve this, a status meeting is led by the TPM, and progress is monitored closely.

Ceremonies: One-on-one update meetings.

Development

The Development phase, also known as the Implementation stage is the longest phase in the SDLC. During this stage, the actual construction of the software takes place, where developers translate the system design into programming code. The TPM is heavily involved in this phase (this is their time to shine).

The Development phase starts with a feature kickoff meeting where the Product team clearly explains the expected outcomes. The architecture team presents the overall technological approach that will underpin the feature. In the case of larger products, the focus is primarily on reviewing the first epic(s) that align with the initial product delivery. These epics and stories are examined in detail, ensuring that everyone, especially the developers, understands the scope. Subsequently, a planning session is conducted where stories are broken down into sub-tasks. Finally, the developers can begin coding.

The TPM’s responsibilities are:

1. Advocating that Agile methodology and principles are properly implemented and followed. Supporting teams in Agile practices, and coaching them through effective Agile ceremonies.
2. Constructing and continuously refining the sprints alongside the development.
3. Tracking the progress of the development and providing transparency to all stakeholders. This is achieved using dashboards that serve as a single source of truth. Each dashboard is customized to meet the informational needs of different stakeholders such as team leads or management. These dashboards showcase metrics such as:

• Feature status — tracking each feature’s current development stage.
• Sprint goal progress — measuring advancement towards sprint objectives.
• Bug analysis — evaluating release readiness by monitoring bug counts and severity.
• Team velocity — assessing work completed per sprint to forecast future performance.
• Dependencies and blockers — identify task dependencies and project impediments.

The dashboards assist the TPM in pinpointing process bottlenecks, improving predictability, and allowing for interventions to streamline operations and keep the development on track.

Ceremonies: All Agile ceremonies; Sprint Planning, Daily Standups, Scrum of Scrum, Sprint Retrospective, and Sprint Review/Demos.

Testing

The code is tested against the requirements to ensure that the software solves the intended purpose. Various types of functional and non-functional testing are conducted, such as end-to-end (E2E) testing, and regression tests.

The TPM’s role is important as it’s the last step before delivering the product.

The TPM’s responsibilities are:

1. Confirming that integration, end-to-end (E2E), and regression tests are incorporated as planned.
2. Guaranteeing that any bugs identified are prioritized correctly and addressed promptly.
3. Leveraging CI/CD for efficiency, the TPM should utilize it to its full potential, to speed up this phase with minimal manual effort.

Deployment

After thorough testing and confirmation of readiness, the product is formally launched to its designated market. Depending on the business strategy of the organization, this deployment may be rolled out in phases. Once deployed, the software becomes accessible for use by the end-users.

The TPM’s responsibilities are:

1. Observing the release process, managing risks, and addressing challenges within the scope, quality, and timelines.
2. Coordinating teams and communication, facilitating the collaboration between various teams and stakeholders, ensuring smooth progress and clear communication of release plans and changes.
3. Monitoring the initial deployments closely to ensure alertness in case of any issues.

Challenges: Ensuring zero downtime, addressing last-minute issues, and managing rollbacks if needed.

Ceremonies: Release planning, deployment checks, and post-deployment review.

Maintenance

During this stage, the software undergoes maintenance and updates, which are given through user feedback as well as any emerging issues. This involves continuous collection of bug reports and customer feedback, addressing the identified problems, and planning for subsequent updates or iterations.

The TPM’s responsibilities are:

1. Overseeing the schedule and execution of maintenance releases to ensure continuous alignment with user requirements and software performance standards.

Ceremonies: Feedback sessions, maintenance planning, and release retrospectives.

Enjoyed this article? Stay updated with the latest insights by following us on our Medium channel and visiting the Engineering Operations website.