1. Plans
1.1. The truth about schedules
1.1.1. Schedules serve three functions: allowing for commitments to be made, encouraging everyone to see her work as a contribution to a whole, and enabling the tracking of progress. Even when schedules slip, they still have value.
1.1.2. Big schedules should be divided into small schedules to minimize risks and increase the frequency of adjustments.
1.1.3. All estimates are probabilities. Because schedules are a collection of estimates, they are also probabilities. This works against schedule accuracy because probabilities accumulate (80% x 80% = 64%)
1.1.4. The earlier that estimates are made, the less accurate they are. However, rough estimates are the only way to provide a starting point for better ones.
1.1.5. with skepticism, not optimism. Invest in design to shed light on assumptions and generate reliable confidence.
1.2. How to figure out what to do
1.2.1. Different projects demand different approaches to planning.
1.2.2. How planning is done is often determined by who has what authority. Requirements, design, and budget are the three kinds of project authority that impact planning.
1.2.3. There are some common deliverables for planning projects: marketing requirements documents, vision/scope documents, specifications and work breakdown structures.
1.2.4. The most powerful way to plan a project involves use of three equal perspectives: business, technology, and customer. The customer perspective is often the most misunderstood and misused.
1.2.5. Asking questions forces good thinking and directs planning energy effectively.
1.2.6. The process of defining requirements is difficult, but there are good references for how to do it well.
1.2.7. Problem statements and scenarios are a simple way to define and communicate requirements. They are easily converted into design ideas without losing clarity about what's important and what isn't.
1.3. Writing the good vision
1.3.1. Vision documents distill other planning materials into a single, high-level plan.
1.3.2. Writing things down serve the author and the team. It provides the basis for discussion and a point of reference that doesn't rely on our fallible memories.
1.3.3. The amount of detail in your vision document varies with the nature of the team and the project.
1.3.4. Team goals should derive from goals defined in the vision. Individual goals should derive from the team goals.
1.3.5. Good visions are simple, goal driven, consolidated, inspirational, and memorable.
1.3.6. Volume does not equal quality. It takes more effort to be concise than not.
1.3.7. Keep the vision alive by asking questions about the utility of the vision to daily decisions on the project.
1.4. Where ideas come from
1.4.1. Many teams don't properly manage the time between requirements and specifications.
1.4.2. Quality requirements and design explorations are the best use of that time.
1.4.3. Ideas are good or bad only in relation to goals or other ideas.
1.4.4. Constraints are useful in finding ideas, but thinking outside the box isn't neccessarily the answer. Sometimes the best solution is finding a clever way to work within the constraints.
1.4.5. Questions, perspectives, and improvisational games are tools for finding new ideas.
1.4.6. The best place to start with design ideas is the customer experience.
1.4.7. Ideas develop into designs through conversations between different people with different kinds of expertise.
1.5. What to do with ideas once you have them
1.5.1. Ideas have their own momentum. It will take longer to reign in creative work than you expect. Changes will cascade through a project.
1.5.2. Create checkpoints for creative work to track and manage it. Common checkpoints include proof-of-concept, idea groupings, three alternatives, two alternatives, and one design.
1.5.3. Use affinity diagrams to consolidate ideas.
1.5.4. Prototypes enable the project to confront issues early and learn from mistakes without significant risk.
1.5.5. Use iterations, or the periodic refinement of a prototype, to ask questions, evaluate progress, and decide on the next steps.
1.5.6. Create an open-issues list to track questions that need to be resolved before specifications can be completed.
2. Skills
2.1. Writing good specification
2.1.1. 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.
2.1.2. Specs solve only certain problems. Team leaders should be clear on what problems they are trying to solve with specs, and what problems need to be solved through other means.
2.1.3. Good specs simplify. They are primarily a form of communication.
2.1.4. Specifiying is very different from designing.
2.2. How to make good gedisions
2.2.1. There is an important skill in meta-dicision making, or decisions about which decisions to invest time in.
2.2.2. Size up decisions before spending too much time on them.
2.2.3. Look for the zone of indifference and opportunities for effective use of singular evaluation.
2.2.4. Use comparative evaluation for the decisions worthy of more investment.
2.2.5. All decisions have emotional components to them whether we admit it or not.
2.2.6. Pros and cons lists are the most flexible method for comparative evaulation. They make it easy to involve others and get additional perspectives on decisions.
2.2.7. Information and data do not make decisions for you.
2.2.8. You improve at decisions making by reviewing past decisions and exploring them for lessons and opportunities for better tactics.
2.3. Communication and relationship
2.3.1. Projects happen only through communication. In modern times, speed isn't the communication bottleneck, quality is.
2.3.2. Relationships enhance and accelerate communication.
2.3.3. There are several frameworks fo how people communicate with each other. PMs should be familiar with them so that they can diagnose and resolve communication breakdowns.
2.3.4. The are several common communication problems, including assumptions, lack of clarity, not listening, dictation, personal attacks, and blame.
2.3.5. Role definition is the easiest way to improve relationships.
2.3.6. Ask people what they need in order to do their best work. Ways to do this include: listening, clearing roadblocks, teaching, and reminding them of goals.
2.3.7. Releationships and communication are not low-priority work. They are essential to all of the individual activities that take place during a project.
2.4. How not to annoy people: process, email and meetings
2.4.1. PMs are prone to annoying others. Some of it is avoidable.
2.4.2. People get annoyed for many reasons. Often, it's when they feel their time is wasted, when they are treated like idiots, or when they are expected to endure prolonged tedium and mistreatment.
2.4.3. Good processes have many positive effects, including accelerating progress and preventing problems. But, they are difficult to design well.
2.4.4. Non-annoying email is concise and actionable, and it quickly allows readers to determine whether they are impacted enough to need to read more than the subject line or first sentence.
2.4.5. Meetings run well when someone facilitates them.
2.4.6. Frusttrating meetings occur when the goals are mismatched to the type of meeting.
2.5. What to do when things go wrong
2.5.1. No matter what you do, things will go wrong.
2.5.2. If you can stay calm and break problems down into pieces, you can handle many difficult situations.
2.5.3. There are some common situations to expect, which include oversights, being forced to do stupid things, resource shortages, low quality, direction changes, personnel issues, and threats of mutiny.
2.5.4. Difficult times are learning opportunities. Make sure you and your team take the time to examine what happened and how it could have been avoided.
2.5.5. Taking responsibility for situations, regardless of who causes them, always helps to expedite resolving the problem.
2.5.6. In extreme situations, go into damage-control mode. Do whatever it takes to get the project to a known and stable state.
2.5.7. Negotiation is useful not only in a crisis situation, but also in management. Good negotiators work from people's interests, not their positions.
2.5.8. Have clear lines of authority at all times. People should know who has decisionmaking power before a crisis occurs.
2.5.9. People respond to pressure in different ways. Be observant and open in how you help the team deal with the different kinds of pressure.
3. Management
3.1. Why leadership is based on trust
3.1.1. Trust is build through effective commitments.
3.1.2. Trust is lost through inconsitent behaviour on matters of importance.
3.1.3. Use the granting of authority and trust to enable people to do great work.
3.1.4. 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.
3.1.5. Use delegation to build trust on your team and to ensure your team against adversity.
3.2. Making things happen
3.2.1. 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.
3.2.2. 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.
3.2.3. There is a bright yellow line between priority I work and everything else.
3.2.4. Things happen when you say no. If you can't say no, you effectively have no priorities.
3.2.5. The PM has to keep the team honest and close to reality.
3.2.6. Knowing the critical path in engineering and team processes enables efficiency.
3.2.7. You must be both relentless and savvy to make things happen.
3.3. Middle-game strategy
3.3.1. Mid-game and end-game correspond to the middle and the end of the project.
3.3.2. If on any day the project is not going well, it's your job to figure out what's wrong ans resolve it. Repeat this throughout mid-game.
3.3.3. 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.
3.3.4. 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.
3.3.5. 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.
3.3.6. The coding pipeline is how work items are managed during implementation. There are aggressive and conservative ways to manage the pipeline.
3.3.7. Milestone-based planning and the coding pipeline provide opportunities to make safe course corrections for projects.
3.3.8. Change control is how you throttle the rate of medium- and low-level change on a project.
3.4. End-game strategy
3.4.1. Big deadlines are a series of small deadlines.
3.4.2. Any milestone has three smaller deadlines: design complete (specs finished), feature complete (implementation finished), and milestone complete (quality assurance and refinement finished).
3.4.3. Defining exit criteria at the beginning of milestones improves the team's ability to hit its dates.
3.4.4. 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.
3.4.5. You need elements of measurement to track the project. Common elements include daily builds, bug management, and the activity chart.
3.4.6. You need elements of control to project level adjustments. Common elements of control include review meetings, triage, and war team.
3.4.7. The end of end-game is slow, mind numbing process. Give yourself and your team the benefit of learning from what went well and what didn't.
3.4.8. 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. Give yourself stories to tell for years to come.
3.5. Power and politics
3.5.1. Politics are a natural consequence of human nature. When people work together in groups, there is limited amount of authority, which must be distributed across different people with different desires and motivations.
3.5.2. All leaders have political constraints. Every executive, CEO, or president has peers of 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.
3.5.3. There are many different kinds of political power, including rewards, coercion, knowledge, referent and influence.
3.5.4. Power is misused whet 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 misuese of power.
3.5.5. To solve political problems, clarify what you need. Identify who has it, and then assess how you might be able to get it.
3.5.6. If you are involved in project management, your are defining a political playing field around you. It's up to you to decide how fair or insane it is.