Learning the fundamentals

Throughout this book, 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 tackle some of the key management areas that project and program managers have in common. As we’ll discuss more in Chapter 2, these are shared across all program manager roles, including specialized roles such as the TPM.

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 or feed into it and it is paramount to a successful project. In Chapter 5, we will go into further detail on this.

Once you have a project plan, you 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, you may amend your 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).

Throughout these stages, you will be engaging with your 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. You’ll also develop a strategy and cadence for regular communication with your stakeholders called a communication plan.

Figure 1.2 illustrates the key management areas we’ll discuss and how they influence each other:

Figure 1.2 – Key management areas

In the preceding diagram, we can see that both project planning and stakeholder management have central roles during the life of your project. Risk analysis and strategies feed into the initial project plan as well as act as continuous feedback. As a risk arises, the schedule may need to be adjusted. The same is true for resource management – if you lose or gain resources, your project plan will need to be adjusted. The available resourcing also plays heavily into your 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, and conversely, 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 aligned more closely with the technical specialization aspect of the role.

The Systems Development Life Cycle

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

Figure 1.3 – The SDLC

The number of phases in the SDLC can vary depending on the situation. This configuration incorporates what I 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.

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. Once these requirements are better understood, the design phase is started, which takes the requirements and builds a design that meets the requirements. The design then drives the implementation of the actual product, which then leads to testing. 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, you begin requirements analysis once more and the cycle continues. Though this looks to be a waterfall approach, 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 in Part 3 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 understanding across all variations of being a TPM.

Now that we’ve covered the fundamentals, let’s take a look at what skills or traits make a TPM the most successful at their role.