Note: While reading a book whenever I come across something interesting, I highlight it on my Kindle. Later I turn those highlights into a blogpost. It is not a complete summary of the book. These are my notes which I intend to go back to later. Let’s start!

  • The Boeing Company, one of the largest airplane design and engineering firms in the world, keeps a black book of lessons it has learned from design and engineering failures.

  • A forcing function is anything that—when put in place—naturally forces a change in perspective, attitude, or behavior. So, schedules are important forcing functions for projects. If used properly by a PM, schedules force everyone to carefully think through the work they need to do.

  • Rule of thirds: Break the available time into three parts: one for design, one for implementation, and one for testing.

  • A big project should be a sequence of smaller projects, all using rule of thirds.

  • Milestone length should match project volatility. The more change that is expected, the shorter the milestones should be. Small milestones set the team up for easier mid-game adjustments.

  • Be optimistic in the vision and skeptical in the schedule.

  • Plan checkpoints for add/cut discussions.

  • Take on risks early. If you know that Sally has the most complex component, deal with those challenges up front in the schedule. The bigger the risk, the more time you’ll want on your side in dealing with it.

  • All estimates are probabilities. Because schedules are a collection of estimates, they are also probabilities. This works against schedule accuracy because probabilities accumulate (80%×80% = 64%).

  • Most planning frustrations occur when there’s disagreement or ignorance about these issues.
    • Who has requirements authority? Someone has to define the requirements and get them approved by the necessary parties (client or VP).
    • Who has design authority? Similar to requirements, someone has to define the design of the work itself.
    • Who has technical authority? Technical authority is defined by who gets to choose which engineering approaches are used, including programming languages, development tools, and technical architecture.
    • Who has budget authority? The ability to add or remove resources to a project can be independent from other kinds of authority.
    • How often will requirements and designs be reviewed, and how will adjustments be decided? The answer depends heavily on previous questions.
  • Documents required:
    • Marketing requirements document(MRD): This is the business or marketing team’s analysis of the world.
    • Vision/scope document: A vision document encapsulates all available thinking about what a project might be into a single composition. If an MRD exists, a vision document should inherit and refer heavily to it.
    • Specifications: These capture what the end result of the work should be for one part of the project. Good specifications are born from a set of requirements.
    • Work breakdown structure (WBS): While a specification details the work to be done, a WBS defines how a team of engineers will go about doing it. What work will be done first? Who will do it? What are all of the individual pieces of work and how can we track them?
  • A good business perspective means that the team has answers for the following questions:
    • Why is this project needed for our business?
    • What unmet needs or desires do our customers have?
    • What features or services might we provide that will meet those desires and needs?
    • On what basis will customers purchase this product or service?
    • What will motivate them to do so?What will it cost (people/resources)? Over what time period?
    • What potential for revenue (or reduced organizational operating costs) does it have? Over what time period?
    • What won’t we build so that we can build this?
    • Will it contribute to our long-term business strategy or protect other revenue-generating assets? (Even nonprofits or IT organizations have a business strategy: there are always bills to pay, revenue to obtain, or revenue-generating groups to support.)
    • How will this help us match, outflank, or beat competitors?
    • What are the market time windows that we should target for this project?

  • A requirement by definition is anything the team (and client) agrees will be satisfied when the project is completed.

  • Create an open-issues list to track questions that need to be resolved before specifications can be completed.

  • Specs should do three things: ensure that the right product gets built, provide a schedule milestone that concludes a planning phase of a project, and enable deep review and feedback from different individuals over the course of the project.

  • Good specs simplify. They are primarily a form of communication.

  • Specifying is very different from designing. There should be clear authority for who writes and has control over the spec. Closing the gap is one approach to managing open issues and to accelerate the end of the specification process. A review process is the simplest way to define and control spec quality.

  • Singular evaluation makes sense for situations where the difference between a great solution and a decent solution isn’t important. Klein describes these situations as being in the zone of indifference because the decision maker is indifferent to major aspects of the outcome as long as a basic criterion is met.

  • Good decision makers don’t waste time optimizing things that don’t need to be optimized. As Tyler Durden says, “That which doesn’t matter truly should not matter.”

  • Comparative evaluation is best for complex situations that involve many variables, have consequences that are difficult to grasp quickly, or require a high quality outcome. New situations or problems that are strategic in nature are prime candidates for comparative evaluation. The more that is at stake in a decision, and the less familiar everyone is with the nature of the options, the more appropriate a comparative evaluation is. With teams, comparative evaluation is the best framework to use if you have to convince others or want their participation in the decision-making process. Comparative evaluation forces you to make relative arguments and develop deeper rationales for action, which is useful for group discussion and communication.

  • Good email should:
    • Be concise, simple, and direct.
    • Offer an action and a deadline.
    • Avoid giving a play-by-play.

  • Never reprimand in real time. The worst thing in the world, especially during a crisis, is for a manager or leader to reprimand someone while the issue is still unresolved. It solves nothing, and it minimizes the probability that the problem will be solved because the person who knows the most about the issue (the blamed) is made to feel guilty and defensive.

  • Trust is built through effective commitments. Trust is lost through inconsistent behavior on matters of importance. Use the granting of authority and trust to enable people to do great work. Granted power comes from the organizational hierarchy. Earned power comes only from people’s responses to your actions. Earned power is more useful than granted power, although both are necessary. Use delegation to build trust on your team and to ensure your team against adversity. Respond to problems in a way that will maintain people’s trust. Support them during crises so that they bring issues to you instead of hiding them.

  • Every engineering work item should map to a feature, and every feature should map to a goal. If a new work item is added, it must be matched against features and goals.

  • Buy people coffee and tasty things. This sounds stupid, but I’ve found that people I’ve argued with for days on end are somehow more receptive over a nice cup of coffee at a local coffee shop. Change the dynamic of the relationship: no matter how much you like or don’t like the person, make the invitation and invest the 20 seconds of effort it requires.

  • Everything can be represented in an ordered list. Most of the work of project management is correctly prioritizing things and leading the team in carrying them out.The three most basic ordered lists are: project goals (vision), list of features, and list of work items. They should always be in sync with each other. Each work item contributes to a feature, and each feature contributes to a goal. There is a bright yellow line between priority 1 work and everything else. Things happen when you say no. If you can’t say no, you effectively have no priorities. The PM has to keep the team honest and close to reality. Knowing the critical path in engineering and team processes enables efficiency. You must be both relentless and savvy to make things happen.

  • Mid-game and end-game correspond to the middle and end of the project. If on any day the project is not going well, it’s your job to figure out what’s wrong and resolve it. Repeat this throughout mid-game. Projects are complex non-linear systems and have significant inertia. If you wait to see acute problems before taking action, you will be too late and may make things worse.When your project is out of control, you are flying behind the plane, which is a bad place to be. Sanity checking is the easiest way to stay in front of the plane. There are both tactical and strategic sanity checks. Consider how to take action to correct a situation in the safest way possible. The larger the action, and the further along the project is, the more dangerous the actions are. The coding pipeline is how work items are managed during implementation. There are aggressive and conservative ways to manage the pipeline. Milestone-based planning and the coding pipeline provide opportunities to make safe course corrections for projects. Change control (DCRs) is how you throttle the rate of medium- and low-level change on a project.

  • Big deadlines are a series of small deadlines. Any milestone has three smaller deadlines: design complete (specs finished), feature complete (implementation finished), and milestone complete (quality assurance and refinement finished). Defining exit criteria at the beginning of milestones improves the team’s ability to hit its dates.Hitting dates is like landing airplanes: you need a long, slow approach. And you want to be ready to take off again quickly, without having to do major repairs.You need elements of measurement to track the project. Common elements include daily builds, bug management, and the activity chart. You need elements of control to project level adjustments. Common elements of control include review meetings, triage, and war team. The end of end-game is a slow, mind-numbing process. The challenge is to narrow the scope of changes until a satisfactory release remains. Now is the time to start the postmortem process. Give yourself and your team the benefit of learning from what went well and what didn’t. If fortune shines on you, and your project makes it out the door, be happy. Very, very happy. Many people, through no fault of their own, never get that far. Plan a grand night. Do ridiculously fun and extravagant things (including inviting this author to the party). Give yourself stories to tell for years to come.

  • Instead of saying “I need another programmer,” understand that you can honestly say, “To achieve goals X and Y, my team needs another programmer. Our project plan didn’t anticipate the three requests that came in last week, and as a result, our goals are currently at high risk.”

  • Politics are a natural consequence of human nature. When people work together in groups, there is a limited amount of authority, which must be distributed across different people with different desires and motivations. All leaders have political constraints. Every executive, CEO, or president has peers or superiors who limit their ability to make decisions. In general, the more power a person has, the more complex the constraints are that they must work within. There are many different kinds of political power, including rewards, coercion, knowledge, referent, and influence. Power is misused when it’s applied in ways that do not serve the project goals. A lack of clarity around goals, unclear resource allocation or decision-making processes, or misunderstandings can contribute to the misuse of power. To solve political problems, clarify what you need. Identify who has it, and then assess how you might be able to get it. If you are involved in project management, you are defining a political playing field around you. It’s up to you to decide how fair or insane it is.