4
Driving Toward Clarity
In this chapter, I’ll introduce the last foundational skill – driving toward clarity. It is not a single step in the management process but is instead a skill that is applied to every process we drive and every decision we make. It is the reason why you will hear the TPM in the room ask why and how. It’s why you see TPMs run meeting after meeting, working session after working session, and attending every standup that they can fit into their schedule. They are constantly taking the data they have and clarifying it so that it has no ambiguity left and is easier to understand and follow. This then feeds into getting consensus because, without clarity, it is hard to get past the first stage of getting everyone onto the same page, and we can’t move on to driving consensus.
As this skill permeates everything we do as leaders, it is not a pillar but the mortar that transforms a pile of bricks into a wall. It is an integral part of who we are and the reason this topic gets its own chapter!
We’ll learn how to drive toward clarity by exploring the following topics:
- Clarifying thoughts into plans
- Using clarity in key management areas
- Finding clarity in the technical landscape
Let’s get started right away!
Clarifying thoughts into plans
Everyone drives toward clarity in some aspect of their life. It is the act of taking knowledge and applying it to a situation to make the path forward better understood, and to lead to the desired outcome.
As an example, a retail worker may look at a product layout diagram, along with the products they have on hand, and the actual shelving they have available, and do their best to match the diagram – all along with making minor adjustments or judgment calls. They are driving toward the end goal of a properly stocked display. In the same situation, the worker may just be told to make a display out of the seasonal summer products. In this case, the level of ambiguity is much higher than the first – there is no diagram and no specific list of products, so the complexity and number of decisions are much higher. In both cases, the worker drives toward clarity to end up with a properly stocked display.
This is also true for a TPM and the roles that surround it. What makes a TPM shine is that they drive clarity in every aspect of their job. We question everything and everyone to ensure that the objective is as clear as it can be. In this respect, a TPM must be willing to question requirements from upper management just as deftly as from a leader on a peer team.
The most common area where this comes into play is in the problem statement, as in what is it that we are trying to solve? It is such a large part of our job that many role guidelines specifically mention the concept with varying degrees of complexity. Figure 4.1 shows a common breakdown of the level of ambiguity a problem statement will have for a TPM based on their career level:
Figure 4.1 – Growth by ambiguity
In this figure, you can see that the entry-level position’s problem statement and the solution are clearly defined – much like the first retail example. Both the problem and solution are laid out. There will be some minor ambiguities during execution you’ll need to resolve, but it will be fairly straightforward. Moving on to the industry TPM, there’s a little less direction. You might be told the general solution but not how to accomplish it. A senior TPM will simply be told to solve a problem but not how. Up to this point, the problem statement is known but the amount of ambiguity in how to solve the problem is what increases, the higher up in your career you go.
Beyond these levels, we get into high-impact positions where the ambiguity increases significantly. This can vary depending on your experience and the company but generally lands between being told that a problem may exist and to investigate and fix it, and to go find problems and fix them. In the first example, the problem statement is very ambiguous but, in the latter, the problem statement isn’t ambiguous, it’s non-existent! We’ll touch on this again in Chapter 9 and expand it as this directly correlates to scope as well as impact. Figure 4.1 used elements of Technical Program Managers by Ambiguity from The TPM Blog. Visit https://www.mariogerard.com/take-it-to-the-next-level-as-a-tpm/ for more information.
We now understand the basics of clarifying thoughts into plans and the impact this skill has on our success in a project as well as in our career (we’ll cover this further in Chapter 9 when we discuss career paths). Next, we’ll see how this skill is utilized throughout the project.
Using clarity in key management areas
There are many ways in which driving toward clarity has an impact on project or program execution. We’ll discuss the key management areas to demonstrate how seeking clarity is utilized.
Planning
Let’s take the original problem statement that was the basis of our case study as an example for driving thought into plans. In the original iteration of the application on Windows, I had a problem I was trying to solve – I wanted to talk with my colleagues via a chat client but didn’t have the resources or permission for a centralized server. I took the problem statement and looked for solutions that fit the need for no central server and landed on a P2P network. From this initial solution, I then dove into high-level designs, low-level designs, and then implementation. In every step here, there was some level of ambiguity that needed to be clarified to proceed. I didn’t have stakeholders to convince, nor a development team, but the need for clarity was still there as I knew what I wanted – requirements – but not how to accomplish them. What was different then versus now was the scope and impact of ambiguity. In the beginning, the scope was limited to my colleagues on Windows machines, and there was no impact as it was simply a desired feature to have at the office. Therefore, the ambiguity was limited to how to accomplish the requirements. In the Mercury program that I’m using in the book, the ambiguity stretches across both the requirements and solution, and there are stakeholders involved who are impacted by the work.
Now let’s expand this to the Mercury program that stands as the use case for this book. The problem statement is well understood, and the requirements are known at a high level: make a client for each operating system (based on our assumptions from Chapter 3). Many open questions differ from platform to platform. For instance, mobile platforms need more clarity on the certification process for their respective app stores to form a project plan and a high-level design. Similarly, all platforms need details on how to initiate a broadcast call over TCP/IP in order to finish high-level designs. This also helps determine the level of generalization the network communication layer component can be designed to work with across the platforms.
As the high-level designs for the broadcast call come into focus, further changes to the program plan, and each project plan, may be needed. To add to the complexity, each application will be developed by a team in the company that specializes in their respective operating system and may have additional requirements unique to their operating system, or the frameworks they use for development.
This iteration of the high-level design demonstrates how the planning cycles for the program and project can influence each other, and how driving clarity can feed right back into additional planning. Let’s take a closer look at the cyclical nature between planning and seeking clarity in Figure 4.2:
Figure 4.2 – Driving clarity in plan management
The preceding figure shows the interrelation between program and project planning, and how driving clarity plays a role in every step. As you work through the requirements for the program, you seek clarification on specifics in order to understand the impact and scope better. These clarified requirements then feed into your program plan, which, in turn, sets up the basis for each project plan. The program requirements that are covered by a specific project will make their way to the project requirements with traceability back to the program. Then, during the execution of both the program and project, as designs are finalized, updates to estimates and timelines are then fed back into the respective plans. The designs are also checked back against the requirements to ensure that the designs satisfy the requirement. Each of these cyclical paths is driving toward clarity to some degree.
What can happen when you don’t clarify your plan enough?
We’ve talked a lot about the good things that can happen when your management practices are solid. However, it’s worth talking about what can go wrong when clarity isn’t sought out, or the level of clarity is insufficient.
The plan and the planning process are important for a successful project or program. Due to this, any lack of clarity in the requirements or elements of the plan can lead to long-lasting issues. The next three chapters will explore this concept in more depth, but let’s walk through a few examples now.
Scope creep, or the addition of scope unexpectedly, can arise in a few different scenarios. We think of it mostly as additional requests that are added to the project after the scope is locked in, and this certainly does happen. However, it also occurs when requirements are not well understood. As requirements are fleshed out, they uncover complexities not seen at first, which will lead to additional tasks to meet the requirements. This is due to a lack of driving sufficient clarity in the requirements, resulting in poor estimations and understanding. Conversely, scope creep can happen through gold plating, or the addition of features or enhancements not asked for in the requirements. This can happen during design, where the developer adds things to the design that they believe are needed, or feel are needed, and it can also happen at the request of the TPM.
Lastly, there are derived requirements where the TPM gives the requirements or functional specifications to the development team, who then adds additional requirements based on the needs of their service. This could be things such as scaling, latency, or code refactoring that are needed to make the required changes maintainable. As a TPM, the more you know about the roadmaps, architectural evolutions, and availability needs of the services you work with, the more you can anticipate these needs earlier on, so they are not added during development but added into the scope at the beginning.
All of these types of scope creep are different from iterative development in that the requirements are understood, but the priorities may shift around. Even in the cases where scope is added due to customer feedback, it merely shifts the priority of other items and isn’t true scope creep, where scope is added but there is no additional time or resources to handle it.
Change management, which is the process used to handle a change in scope, resourcing, or timelines, is negatively impacted by scope creep, as it causes constant churn on the project plan. This then leads to delayed delivery of a milestone or the delay of the entire project. Though the nature of the project management triangle is that these elements are always tied to one another, a well-defined plan will reduce the friction between them.
In both of these examples, ambiguity in the requirements forces the late discovery of missed scoping during design and development. As such, ensuring that the project requirements are well understood and written in detail can mitigate these problems.
We’ve seen how driving toward clarity in project planning leads to a successful foundation for a project’s execution, as well as some areas where a lack of clarity can increase the project scope or timeline. Next, let’s see how the risk assessment process utilizes this same skill.
Risk assessment
For risk assessment, there are many ways to drive clarity. First and foremost is doing the exercise in the first place! I’ve seen plenty of projects that treat issues and risks synonymously – as in, an active issue is just a risk to the project, and that risks are an issue that causes timeline issues. However, a risk is something that might happen and impact the project timeline, scope, or resourcing, but hasn’t happened yet. In a textbook world, meaning in theory, an issue is just a risk that has been realized – as in a risk that was already captured, and there is a strategy in place to deal with it. By knowing ahead of when something might happen, you have a better chance of avoiding it or at the very least being prepared to handle it.
We aren’t in a textbook world though, and in the real world, many unforeseen problems can crop up (which should go into your risk register to reduce the chances of the same problem coming up again in future projects). The risk register for your project should be abundantly full to account for any issues that you can foresee. Though issues that arise may not match the risk perfectly, the stated risk and strategy are usually adaptable to the real-world scenario that takes place.
As an example of a foreseeable risk that may or may not occur, I have worked with a team that has had trouble with consistent service deployments. There are multiple reasons for the inconsistency, from lengthy deployment timelines to consistent merge and regression issues. Owing to this, deployment delays are a standard risk for my projects when there is work on these services that have delays. Once I have my project plan and one of these services is identified in a task, I immediately add the risk to the project. The service could have a great month and not miss a single deployment, but that doesn’t mean the risk is gone. This deployment risk isn’t meant as a slight to the team that owns the service but is just a statement of fact and if I ignore that fact, I put the project in jeopardy.
When driving clarity in analyzing risks, it forms a cyclical relationship between risk assessment and planning. Figure 4.3 shows this relationship:
Figure 4.3 – Driving clarity in risk management
From our case study, we’ve already identified several risks in Chapter 3. The first pass at risk assessment is relatively surface-level; you find the risks that are obvious and capture them. These risks may help uncover more risks, which in turn find more and so on. Every pass adds clarity to the project by adding more detail to the project plan and risk strategies.
What can happen when you don’t clarify your risks?
Risk assessment follows many of the perils of the project plan. As seen in Chapter 1, it feeds into the plan itself and the plan, in turn, feeds into the risk assessment. A misunderstood risk can create a false sense of security, by providing a risk strategy that may not fully address the problem.
For instance, a risk may be identified in the Windows Rollout project of the Mercury program, which states that there is a possibility of a network test failure that could add 3 weeks to the timeline (refer to Table 3.5 in Chapter 3). However, if the type of network test failure isn’t specified, the strategy of delaying by three weeks may not be accurate. It could also be that other risks, such as the fast-tracking – or running in parallel – of all end-to-end testing, could exacerbate the networking failures, and thereby cause even more delays than expected. The deeper the analysis and cross-checking of risks and projects, the better the outcome will be.
Risk assessment benefits directly from seeking clarity but also influences your project plan in return. Now let’s examine the relationship between stakeholders and driving toward clarity.
Stakeholders and communication
At a first glance, working with stakeholders may not seem to have much need for driving clarity, but this is just as important as the more obvious methodologies we’ve already covered. We think of stakeholders as people or groups we need to communicate statuses to, discuss timelines and blockers with, and so on, and while this is true, they are also great sources of information throughout the project.
In order to get the most out of a stakeholder, you need to fully understand their role in the project or program. Are they merely an interested party, such as a VP of a department, or are they involved in the deliverables directly? If they are involved, what is their role in that involvement? A developer? A manager? A fellow TPM? These questions help determine who your subject matter experts are. A TPM is adept at seeing a problem at multiple levels and can connect a problem that one milestone is having with surrounding work or even other projects within their department.
Take the Windows Rollout project as an example. When getting ready for execution, the networking risk we discussed in Chapter 3 may come up in the design. The list of stakeholders may reveal a subject matter expert in networking from within the Windows Rollout project, or even across the other projects within the Mercury program. If, for instance, the Android Rollout project has a dedicated networking team, they may be of some assistance given that three out of the four TCP/IP layers (Transport, Internet, and Network layers) are going to be largely common across different application layers, or in our case, operating systems. This could be a chance to combine network specialists across the projects, forming a co-op group to help solve common network issues and ensure consistent network solutions for the program. Without knowing who your stakeholders are and what their roles are, this type of opportunity to clarify networking requirements and put in place mechanisms to ease the design and implementation may be missed or take a lot longer to piece together than is necessary.
There are two avenues where you can drive clarity by communicating with your stakeholders. Figure 4.4 shows the relationship between driving clarity and these avenues of communication:
Figure 4.4 – Driving clarity using stakeholder communication
Issue resolution and status updates are the main avenues of utilizing stakeholder communication to drive clarity. In issue resolution, you are communicating in order to get additional input to help solve the issue. This is important as each stakeholder will have a different perspective on the issue and may be able to provide useful information to drive a solution.
Using your existing status cycle to communicate back to stakeholders keeps them up to date as to what is going on in the project or program, and who is working on what. This can help stakeholder teams prepare for milestone deliveries and reduce back-and-forth churn. In the next section, we’ll explore how the lack of these cycles can cause problems.
Risks of excluding stakeholders in clarification strategies
Communication is key to our success. So is our ability to connect the problem with the right people to solve it, and to find out how problems may intersect with one another.
I have found over the years that keeping all stakeholders up to date with all open issues is advantageous for a few reasons. Firstly, it provides the highest level of transparency to everyone involved, thereby building trust. The more the stakeholders know what issues are coming up and how they are being addressed, the higher confidence they’ll have in the project. Secondly, they’ll have information to help resolve open issues. This leads to two main examples in which a lack of communication with stakeholders can cause even more problems.
When it comes to earning trust, it often comes down to the perception that stakeholders have of your ability to deliver on the goals. Your best avenue to control that perception is through status communications. Work with your stakeholders to draft the right message based on your audience. I have had long meetings discussing how a status report needed to show all of the issues, to ensure that the highest-priority issues were clear, and to ensure that the project didn’t come across as in worse shape due to the number of issues.
Aside from the content, it also needs to be consistent. If your communication is promised to come out weekly, and you miss a status or are a day late here and a few days there, this leads to the perception that you are disorganized and have a hard time following through. Even if you have a legitimate reason for missing or delaying – such as waiting on a resolution to an issue to report the most up-to-date status – there’s a good chance it won’t be seen that way. This is so fundamental to what we do as TPMs that consistent communication can come up in performance reviews and promotion documents. It’s a measurable artifact that demonstrates our ability to be an effective communicator – you can literally see a gap in a status, or that dates don’t line up to when they were promised to. It can also lead to micromanaging from your stakeholders!
If stakeholders don’t believe in your ability to manage the project, they may start to challenge your decisions. Chapter 7 will go into more detail on the dos and don’ts of status reporting.
From a problem-solving perspective, not involving your stakeholders can lead to some negative impacts, all involving losing time. Let’s examine two scenarios.
Avoiding wasted effort with clear communication
First up, I want to examine a use case of wasted effort. We’ll use the Mercury program as the stage to discuss this. At a minimum, we have five projects going on in the program at once. Most of this work is contained within their respective operating system environments. However, there are examples of shared code from both the lower network layers, as well as a shared API library for the service itself. In these cases, each project team will be contributing to these shared libraries. As issues arise and problems are investigated, you may end up with multiple groups trying to solve the same problem, or simply working on the same code base at the same time. Without proper communication between teams, this can be missed. Worst-case scenario, you end up with code merges that remove, alter, or override behaviors in unexpected ways. Or you simply end up with time wasted by having two teams working on the same problem. Proper communication can ensure the overlap is noticed, the plan is updated, and the situation is avoided or corrected as quickly as possible.
A good analogy for this is too many cooks in the kitchen. If you’ve ever seen competitive cooking shows, you’ll see multiple chefs in the same shared space and they’re always yelling out something along the lines of coming through, hot plate! You’ve also seen what happens when they don’t do that: plates collide and dishes are ruined. Communication can be the difference between winning and losing!
Reducing churn during issue resolution
The other consequence of poor communication when trying to find clarity is similar to the first example in that it results in wasting time. For instance, there’s a large, mature product that recently involved sending a new set of specifications down via the technical writer. The tester and developer are both testing the software to see whether it fits the specifications. However, it turns out that there are three requirements that logically cannot coexist – any two of them can but not all three. The developer is doing integration testing and finds that one of the requirements breaks, so they fix it, which breaks the third requirement. Now the tester is running their tests, sees an issue, and reports a bug. This is fixed but it breaks requirement two. This goes on and on, as the technical writer, developer, and tester are not communicating. A TPM gets involved due to the delay, gets everyone into a room, and within an hour sees that there is a problem with the requirements, and works with the technical writer to decide which of the three to move forward with. Had these stakeholders communicated about the issues they were facing, this may have come to light much quicker (or, simply had a TPM been involved from the start).
Often in these cases, the missed opportunities are not intentional – you are simply in the weeds trying to unblock your team – but to be an effective practitioner we need to always ensure stakeholders are in the know. It can save you a lot of time and unnecessary work.
As you can see, a lot can go wrong when stakeholders aren’t involved in your quest to clarify. Conversely, a lot can go well when handled correctly. As a TPM, your job is to be a force multiplier; you get the right people in the right place so that a problem can be solved quickly and efficiently. And when you don’t know the right people, or the right place, communicate with your stakeholders to find answers quicker!
We’ve explored how you are always driving toward clarity in every step of a project and looked at examples of how seeking clarity benefits the project and what happens when you don’t dive deeper into a requirement or problem to define it. Now, let’s look at how this may differ in a technical setting.
Finding clarity in the technical landscape
As a TPM, you are often aware of many programs and projects that impact your team or organization. You work with other TPMs, other teams, and leaders to deliver your goals. This gives you both a deep knowledge of where you directly run your projects, as well as breadth in the technical landscape surrounding you.
In a technical setting, we use this depth and breadth to our advantage as we have the ability to look at each problem from a different vantage point, all the way from the street level to the full cityscape. These varying vantage points allow us to connect the dots across projects and programs. Let’s look at a few examples of seeking clarity and connecting the dots in a technical setting.
Let’s explore a technical breadth example. As is often the case, members working on the implementation of a project are highly focused on the project goals. While this is desirable, as it ensures a solid solution to the problem at hand, they might miss how these changes may impact other initiatives. As a TPM, you might be in a position to help drive the technical direction of your team. This involves knowing where your team and technology are headed, as well as the tenets that drive them. This knowledge will help drive your day-to-day direction and your design decisions, by helping you connect problems and solutions across project and program boundaries.
In a recent example, my organization received a request from a client team to look into the behavior of a field we return in our service response. It was behaving incorrectly for an edge case, and they wanted us to fix it as they relied on that field. Our on-call developer was looking into this issue when I came across the ticket. Though it is always a good idea to fix edge case issues in your API responses, for this particular field, the team had decided that, in the long term, they wanted to remove this field from our response. I engaged with the client that submitted the ticket and talked with them about what they were trying to solve. I took this back to our team to help ensure that our long-term vision was not missing a use case, while also providing a different way for the client to achieve their desired behavior without relying on that field. Our on-call developer didn’t know or wasn’t thinking about the long term, they were in triage and trying to solve issues, so this connection was initially missed.
By recognizing that fixing this field went against our long-term goal of removing the field entirely, I was able to steer the client away from using it. We found a solution that aligned with the long-term architecture and thereby removed the throw-away work they would have done in the next year to move away from the deprecated field. Inspecting broadly can help ensure you are influencing not just your project but your organization and driving everyone toward your shared goals. At the same time, we need to ensure we are diving deeply as well. Looking back at project planning, one key handoff is when a task is taken from the project and given to the development team to design and implement. This handoff is a key area to ensure you drive as much clarity as possible. You do this by providing all of the context needed to do the task upfront, and then by asking questions during design and estimation. Often, our project plan estimates are high-level in the beginning and as requirements go through design, we get a more confident estimate that we can then update our timelines with.
However, this isn’t a static process as the capabilities and depth of understanding can vary from developer to developer. So, I always clarify with the developer their estimations starting out, by simply asking how confident they are in the estimate, as well as what elements were included in the estimate (design, code review, testing, and/or deployment), as many new developers will just include the code writing itself. I then follow up by probing the design to see what sort of responses I’m getting. This can help inform me of what a buffer might look like for the developer’s estimates for the given task. In these scenarios, it’s good to remember that a developer’s job is to estimate based on ideal conditions. Though some developers can, it is your job as a TPM to look at how other factors, such as the following, may impact the developer’s ability to deliver the task:
- Are there deployment issues or blockers on the calendar?
- What is the experience level of the developer for the area the task impacts?
- Are there any unknowns or new technologies for this task that may take extra time?
- Are there other projects ongoing that may impact the changes being made?
You will need to go deep into the project and understand how these tasks are connected, the technologies behind them, and the people involved in order to bring the highest clarity to the project plan and ensure the success of the developer in their task.
Summary
In this chapter, we discussed in greater detail how a TPM is constantly driving toward clarity. From project initiation, all the way through to project closing, the TPM is clarifying requirements, assumptions, issues, plans, and estimates to continually steer the project in the right direction.
We looked at how everyone takes thoughts and clarifies them into plans, from building seasonal displays at a retail store, to varying levels of ambiguity in the problem a TPM needs to solve. We also touched on how the level of ambiguity increases the further in your career you get.
We explored how driving clarity is used in all key management areas and tied it together with specific scenarios that you can encounter in a technology space.
In Chapter 5, we’ll use the Mercury program and driving toward clarity to build out a more comprehensive project plan as we dive deeper into project and program planning.