More on this book
Kindle Notes & Highlights
by
Adam Josephs
Started reading
January 13, 2023
creating a common understanding, throughout your team, on how you communicate—what you say, how you listen, and what you measure—is paramount.
Project: An activity with a beginning, an end, and a measurable goal.
changes to your project plans become exponentially more expensive as time passes.
Optimistic procrastination: The natural, default, human tendency to behave as if everything will go smoothly, and because we’re busy now, we’ll deal with potential problems and risks later, when we have time.
Risk Up Front is focused on shifting the sense of urgency to the front of the project in order to force issues to be identified and addressed early—when it is less expensive.
The key to making your “cost of being late” useful is to make it measurable. Reduce all the impacts to actual amounts of profit lost or savings forgone. Be accurate where you can, but even a round number or a best guess, widely understood throughout the team, will change the way you deploy resources and mitigate risks.
Accountability: “Singular ownership of a result.” Transparency: “Team-wide clarity of what is so.” Integrity: “Do what you say.” Commitment: “It will be so, even in the face of circumstances.”
Language, driving values through conversation; Structures, including how you spend money and deploy resources; Practices, reliably repeated or triggered activities and tools; Metrics, the results you choose to measure.
Risk Up Front is a methodology for reliably scaling complex adaptive teams.
Risk Up Front intentionally makes the start of the project slower, more systematic, and more comprehensive, because this is the time when making changes is least expensive.
The goal of “planning” is to create a plan. The goal of the commitment phase is to define the project and identify and mitigate risk sufficiently to achieve robust commitment to the project definition—tasks extraneous to that goal should be deferred.
In Risk Up Front, we define quality as the result that achieves customer-perceived satisfaction.
Are you deciding who should join your project team as you go along? On a RUF project, you list these individuals by name at the beginning.
Each team member will share what she believes to be the “top two” biggest risks to the project. This exercise ensures transparency, especially in uncovering risks in habitually overlooked areas of the project.
Our rule of thumb is a project will need three to five definition meetings spread over the first 25–30 percent of the project timeline to settle the project tradeoff and achieve commitment. These meetings are big, long, and often messy. But essentially, the entire team will be identifying what stands in the way of their commitment and identifying and assigning the tasks that will get those things out of their way, who will own them, and by when they will be done. As soon as a definition meeting answers yes to the fundamental question regarding their commitment to the project, the commitment
...more
Good metrics are meaningful, measurable, and manageable.
The “just do it” aspect of practices is the key to removing blind spots. Consider code reviews. If you only schedule a code review when you discover and fix a bug in a code library, you risk that your code library will still contain bugs because of things you didn’t know you didn’t know. To mitigate this risk, you would identify whether a library is “critical” and rigorously schedule a code review every time any critical library changes.
Assigning a task to a department is inadequate.
RUF has a specific definition of accountability—singular ownership of a result. This requires that everything that needs to get done has an accountable owner, and every accountable owner is committed to doing what she said she will do.
Before writing down the name of a team member as owning an action item, that individual must agree to take responsibility for it. Do not assign an item to a person who is not in the room. Only an individual can accept accountability, not a functional group. Assign accountability to people by name, not by their job titles. The process of asking for consent when assigning ownership and handling the resulting yes or no is an important part of any meeting.
If you’re starting a new organization, consider having the team members, as they design their individual accountabilities, think about what accountabilities should be adopted by the entire team to “set the standard” for their work.
RUF fully expects that the project documents, at the early stages of the commitment phase, will be full of statements that are placeholders, untested hypotheses, misunderstandings, and outright mistakes. This is normal. As you are reviewing and clarifying those statements, ask yourself if you will be able to test whether they are so. If your commitments are unclear or untestable, then the team will find itself arguing later about whether stuff is done or not.
Think of the impact in terms of how management would view it. If it were to delay the project, how long might it be delayed? If it were to cause a feature to fall out, what’s the loss in value of losing that feature? Why would management care? It’s not uncommon, after distinguishing the impact of a risk, that you realize your risk isn’t as bad as you thought it was—even if it happened, the project would still succeed. Or you might discover it’s far worse.
Your team culture should reflect two things: that identifying risks is required of all team members, and when team members identify risks, they are the bearers of “good news,” not “bad news.”
We push anyone on a team who identifies a risk to come up with several potential mitigating actions at the time she submits it. Our rule of thumb: at least five. A proposed mitigation might resolve a risk, or it might partially resolve a risk, or it might make team members smarter about steps they should take next to resolve the risk. It might address the cause as a suggestion that the current circumstance be changed. It might reduce the effect of the risk—for example, by funding a backup plan. Finally, it could address the impact—for example, by changing who is the target customer, and making
...more
Prioritize your risks based on familiarity, not severity. The risks you have the least experience with are the most dangerous.
We see in this example specific failures of accountability, transparency, integrity, and commitment. Here’s another question to think about. Who is accountable on this project for ensuring these failures are actually rectified? Who cares that these elements are missing? You? Jackie? Pramila? Ichiko? The engineer from QA who wasn’t in the room? The fact is, if you don’t have the organizational structures and practices that establish these issues front and center before the team on day one, it doesn’t matter, because these issues will land squarely in their blind spot. That is why structure is
...more
The first step to getting this process under control is to be clear whether a project has started or not. Even while your team has its list of projects you are considering—future projects, possible projects—you will want to label explicitly which are your active projects so there is no confusion.
Do not expend the project team’s time and effort on projects that aren’t active. Do not live in a world where you have projects that are sort of active. Do not let there be confusion about whether a project is active or not. If a project is blocked from making progress, use your resources to get it unblocked (if it is worth doing), or abandon it, and perhaps, if appropriate, propose to initiate it later.
Don’t let a decision to prematurely terminate a project pass quietly. For projects that are abandoned, make clear to the team why the decision was made. If there is a forward-looking plan to pursue that opportunity, make that clear too.
If you own any deliverable, any action item, or any risk on which the project’s success depends, you are on the project team.
Core team: People on the core team form a subset of the project team. They are required at all weekly accountability meetings and definition meetings. Think of the core team as the set of team members that can speak to “90 percent of the deliverables and 90 percent of the risks and issues” on the project.
These track leaders form the leadership team of the project. They must cooperate as colleagues who will support one another to ensure the entire project is working and will be successful. The project leader manages the other track leaders to ensure progress and success on the project. This limits the number of track leaders a project can have—we find that eight is the practical maximum. Track leaders, of course, are on the core team.
When you as a project leader start a project, you will write down your best guess as to who should be on the core team. You may have to negotiate with other teams, identify alternatives, horse-trade resources, whatever. Remember, our rule of thumb is the core team should be able to speak capably to about 90 percent of the deliverables and risks the project will entail. Even without knowing exactly what the project will ultimately require, we find this provides a useful guide.
Changes to team membership, just like any other project changes, are less expensive when made early. Your aim is that team membership should be stable during the delivery phase.
When the core team comes together for the first definition meeting and starts to surface risks and make tradeoffs, they may identify additional individuals who will need to be involved. Over the course of the commitment phase, as the team adjusts what is in and out of scope, and as the team uncovers issues that it was blind to, the composition of the project team can be expected to change.
We emphasize this because it is one of the fundamental premises underlying Risk Up Front: you have no greater tool than the empowered and accountable cross-functional project team for making corrections to your project. You must leverage this from the start of your project, and you will continue to rely on it throughout the course of your project. Substantial, complex projects require a core team, tracks, and track leaders. On smaller projects, t...
This highlight has been truncated due to consecutive passage length restrictions.
The first step to having better meetings starts before the meeting happens: Decide and transparently communicate three things: What does the meeting need to accomplish to be successful? Who is the owner who requires that result? Exactly who must participate to achieve that result?
However, if you’re calling the entire team to tell you the status of what they’re working on, and the other participants don’t see why they should care, you’re not going to have a good meeting. Competent meeting owners make their meetings worth their participants’ time.
If it turns out she is unable to attend, abort the scheduled meeting, and reschedule it when the required participants are all available. Teams will often “do their best with the people who showed up,” but this is unproductive: if you have the meeting (or pretend to have the meeting) anyway without all the required participants, it means you will end up having that meeting twice—going through it again when the missing participant is in the room.
An excellent meeting starts with an excellent invitation. The invitation should account for the essential components of a meeting to review: What is the result the owner needs? Who are the people who must be present to get that result? What do they need to do to prepare so they’re ready to get that result?
Owners take responsibility for not letting anyone feel her time is wasted in participating in your meetings.
This also means you’ll want to schedule one meeting to solve one problem. Then schedule a separate meeting to solve another problem.
Take care that nobody is sitting “outside the group” (say, against the wall). All participants are equal. As people are speaking, they can speak from their seat, stand, or move to the front of the room (e.g., if they are presenting something in detail).
The recorder is not “taking minutes.” She needs to capture only the results: conclusions, decisions, issues raised, action items assigned, and so on. For long meetings, let different people volunteer to record, because it’s harder to participate while you are recording.
For this to work, even with senior participants in the room, a good facilitator begins a meeting by stating the goal of the meeting and requesting explicit permission of all the participants to let her drive them toward that goal. This gives the facilitator cover to interrupt the action and get the meeting back on track when she notices a conversation (or monologue) is not moving the participants toward their goal.
DKDK meetings are fragile—the moment participants notice an issue has been revealed, like moths to a flame they will immediately derail the meeting to address that issue. But that is counter to the goal of the DKDK meeting, which is to identify issues, not resolve them.
The project statement communicates in no more than three pages the target customer, the measures of success (from the point of view of both the customer and the organization), and project end date. In other words, the Why, What, and When of the project.
If you find you have to say things to “explain” your meaning, you have lost. Keep that in mind as you are deciding whether the language in your project statement is clear.
This three-question process is ideal for having a team review any document, any action item, and any risk entry in any meeting. It is not just for the definition meeting read-through.
