Learning the Fundamentals

Build on the fundamentals of technical program management by learning the SDLC.

We'll cover the following

Throughout this course, we’ll discuss many concepts that are core to any program manager, as well as some that are more specific to the TPM specialization. Let’s briefly discuss some of these terms so that we have a shared foundation to build upon.

Let’s start with some of the key management areas that project and program managers have in common. As we’ll discuss further, these are shared across all program manager roles, including specialized roles such as the TPM.

Project planning

Project planning is where we work through requirements, resourcing, and constraints and develop an action plan. This makes up the backbone of our work—all the other management areas build from this planning or feed into it, and it is of paramount importance to a successful project.

Once we have a project plan, we will analyze the roadmap and identify any risks that could arise. These can be related to tight scheduling, resourcing constraints, project dependencies, or scope concerns. Depending on the risk, we may amend our project plan to help mitigate it (such as swarming—or increasing resources on a particular task to get it done quicker—to alleviate scheduling concerns).

Elements of project planning
Elements of project planning

Throughout these stages, we'll be engaging with our stakeholders to provide insight. Requirements often come from one or more of the stakeholders and they may identify risks or mitigation strategies for reducing risks. We’ll also develop a strategy and cadence for regular communication with our stakeholders called a communication plan.

The below figure illustrates the key management areas we’ll discuss and how they influence each other:

Key management areas
Key management areas

In the preceding diagram, we can see that both project planning and stakeholder management have central roles during the life of our project. Risk analysis and strategies feed into the initial project plan, and also act as continuous feedback. As a risk arises, the schedule may need to be adjusted. The same is true for resource management—if we lose or gain resources, our project plan will need to be adjusted. The available resourcing also plays heavily into our initial timelines. Though some organizations resource based on an optimal plan (in that they will determine the quickest most efficient path to completion and resource according to this need) most tech companies provide resourcing based on prioritization of the project and the schedule adjusts based on what is available. If the project is deemed to be a high priority, more resourcing may be given to hit a specific date. Conversely, a project may be given less resourcing if there is higher priority elsewhere.

Each of these management areas also feeds directly into stakeholder management—especially around standard communication routines. Any changes in the schedule, resourcing, or risk realizations should be immediately communicated by the TPM to the appropriate groups of people based on the communication plan.

Now that we’ve covered the program management fundamentals, we’ll move on to concepts that are more closely aligned with the technical specialization aspect of the role.

The Systems Development Life Cycle

The Systems Development Life Cycle (SDLC), sometimes written as The Software Development Life Cycle, is fundamental for a TPM to understand because it is central to both software and hardware development. Because it's a cycle, by nature it's iterative. The below figure illustrates the cycle, starting at the top with requirements analysis and following clockwise to come back around to this initial step:

The SDLC
The SDLC

The number of phases in the SDLC can vary depending on the situation. This configuration incorporates what we see as the main phases that need to be involved for the cycle to be successful. Starting at the top, the flow is as follows:

  1. Requirements analysis: At the beginning of a project, the SDLC starts with the requirements analysis phase. These may already be well established or are newly discovered or added requirements that need to be broken down.

  2. Design: Once the requirements are better understood, the design phase is started, which takes the requirements and builds a design that meets those requirements.

  3. Implementation: The design then drives the implementation of the actual product.

  4. Testing: Once the product has been implemented, it must be tested.

  5. Evaluation: The final phase is evaluation or iteration. This step involves looking at the product and looking for improvements. These improvements may also come from feedback from stakeholders and customers. Once they are identified, we begin requirements analysis once more and the cycle continues.

Though this looks to be a waterfall approachThe waterfall approach is a traditional software development methodology that divides the project into sequential phases, with each phase depending on the completion of the previous one, where all steps of a phase such as requirements gathering are completed before moving on to the next phase, this cycle can happen as often as needed. A single requirement may go through this entire cycle while another is being clarified and may proceed to design much later. To that end, the cycle is utilized in waterfall, agile, and hybrid environments.

Many other pieces can contribute to the technical fundamentals, which we will cover later in more detail. Those skills will vary from company to company, as well as from team to team within a company as the needs of that team can vary. Keeping that in mind, the SDLC is a fundamental process across all variations of being a TPM.The waterfall approach is a traditional software development methodology that divides the project into sequential phases, with each phase depending on the completion of the previous one