Book summary “Making Things Happen”: summary

Introduction

You face the daunting task of turning vague ideas into real products while managing shifting requirements, tight deadlines, and unpredictable people. Project management often feels like navigating chaos without a map, where traditional frameworks fail to solve daily friction. Scott Berkun addresses this struggle by arguing that effective project management relies on clear priorities, rigorous schedules, transparent communication, and trust rather than bureaucratic checklists.

The book explores the universal constants of engineering and leadership, moving from the historical roots of building things to the practical realities of scheduling and planning. You will learn how to define project visions, manage creative ideas, structure team communication, and handle crises when plans inevitably go sideways.

• How do you build schedules that actually work instead of serving as wishful thinking?
• What separates a useful project vision from empty corporate jargon?
• How do you maintain trust and make things happen when pressure mounts?

1. History and the Role of Project Management

Project management is not a sacred or entirely novel art. Modern engineering shares a core set of concepts and challenges with the builders of ancient structures.

Project management is not a novel art; modern engineering shares universal constants with builders across history.

By studying fields like the Egyptian pyramids, Roman aqueducts, the Hubble Space Telescope, and the Boeing 777, you can recognize universal constants across eras and technologies:

• requirements;
• designs;
• constraints;
• schedules;
• budgets;
• customers.

You approach these constants best with shoshin, or a beginner's mind. Failures are the most powerful source of progress in engineering and project management, provided organizations have the courage to study them openly. Failures force people to pay attention and re-examine forgotten assumptions. Rather than hiding from or punishing failure, teams should harvest lessons from past mistakes to prevent future disasters. The Boeing Company has kept a black book documenting lessons learned from design and engineering failures since the company was formed.

A Brief History of Project Management

Observing high-intensity environments outside of software development provides practical insights into team coordination, task management, and triage. Busy professional kitchens operate with extreme precision, coordination, and intensity under tight spatial and temporal constraints. Hospital emergency rooms utilize expert teams to handle high-stress decision making and invented the process of triage. At Microsoft, a dedicated program manager bridges the gap between technical engineering teams and business or marketing divisions. Jabe Blumenthal first played the program manager role on a product called Multiplan, which later became Microsoft Excel. Out of more than 80,000 total employees, Microsoft eventually employed 5,000 program managers. They act as line-level generalists who drive the project from day one of planning to final testing, holding authority across functional hierarchies in a matrix organization.

The Balancing Act of Project Management

Effective project managers must master a set of conflicting attitudes and develop the intuition to apply them as different situations require. Tom Peters identifies several key dilemmas that project managers must balance:

• having high emotional investment while suppressing personal ego;
• being an autocrat when speed is needed versus a delegator;
• tolerating early ambiguity while pursuing later perfection.

Project managers under pressure often retreat into administrative bureaucracy, mistakenly treating tracking processes and checklists as the project itself. When leaders confuse process with goals, they spend excessive time on spreadsheets, tables, and whiteboards instead of engaging directly with their team. On the Internet Explorer 4.0 project, Scott Berkun built an elaborate spreadsheet and covered his office whiteboards with checklists until his boss intervened, telling him to manage the team rather than the checklists. Managers are not hired to contribute a linear amount of work like individual workers, but to amplify the value of everyone around them. Your true function is similar to a sports coach, contributing through settling arguments, shielding the team from politics, providing high-level plans, or finding clever workarounds.

Management by Walking Around

Project managers can use their wide perspective and casual check-ins to transfer timely information and catch status realities early. By regularly walking the halls and dropping in on team members, you gain a wider perspective of the project. You understand both business and technical views, helping connect disparate pieces of information across the team. During the 5.0 version of the Internet Explorer project, the author dropped by Fred's office and overheard him arguing with Steve about a compatibility issue with the new List View control. Because the author had just visited Bill's office down the hall and saw the same problem already fixed, he connected them, saving the team a half-day of wasted effort.

2. The Truth About Schedules

Schedules serve three distinct purposes: external commitments, forcing functions, and progress tracking tools.

All schedules act as contracts confirming delivery dates for customers. They foster psychological connections and dependencies through a forcing function. They also break large efforts into manageable chunks for better tracking and questioning.

Three Purposes of Schedules

The rule of thirds dictates that project time should be roughly divided into three equal parts for design, implementation, and testing. For every day spent writing production code, a day should be spent planning and designing. You should also plan a day to test and refine. Imbalances are acceptable only if they are deliberate.

For a web development project given six weeks to launch, the time should be roughly divided into three parts to make calculations about when work can be completed.

• Break the available time into three parts—one for design, one for implementation, and one for testing.

Why Schedules Fail

Schedule estimation errors scale dramatically based on how early in the project the estimation is done. Early schedule estimates can be off by massive margins because hundreds of decisions have yet to be made. Precision in dates does not equal accuracy, and estimation accuracy only improves as the project moves into implementation. Early estimates suffer from a 400% maximum error range, while implementation swings sit at 20%.

Because schedules are collections of independent probability estimates, the likelihood of meeting overall deadlines decreases multiplicatively over time. The probability of a series of independent events occurring is the multiplication of the likelihood of each individual event. This compound probability means schedule slips create a snowball effect over time. Finishing a chapter has a 9 out of 10 probability, but the total probability of finishing two consecutive chapters drops to 81/100.

Establishing explicit baseline confidence intervals helps make the quality of estimates concrete. You need to agree on how accurate estimates should be and how missed estimates will be managed.

• Establish baseline confidence intervals for estimates (A guess equals 40 percent confidence in accuracy, a good estimate equals 70 percent, and a detailed and thorough analysis equals 90 percent).

Making Schedules Work

To make schedules work, milestone length must match project volatility. You must combine vision optimism with schedule skepticism.

• Match milestone length to project volatility.
• Be optimistic in the vision and skeptical in the schedule.
• Bet on design as insurance against ignorance.
• Plan checkpoints for add/cut discussions.
• Inform the team about planning philosophy.
• Gauge the team's experience with the problem space.
• Gauge the team's confidence and experience in working together.
• Take on risks early in the schedule.

3. Planning and Requirements

Successful project planning requires balancing business, technology, and customer perspectives instead of favoring a single viewpoint.

The Three Perspectives

The business perspective focuses on P&L accounting, costs, revenue, competition, and strategy. The technology perspective focuses on materials, engineering quality, and construction. The customer perspective focuses on user needs and behaviors. None of these can exist without the others, and true success happens at their intersections.

Scott Berkun recalls working as the program manager for web-search features on Internet Explorer 4.0, where engineers and business development people argued for weeks without stepping back to evaluate their hidden philosophies.

Project planning is heavily influenced by how four specific types of authority are distributed across team members:

• requirements authority;
• design authority;
• technical authority;
• budget authority.

Most planning frustrations occur when there is disagreement or ignorance regarding these authorities. The complexity of authority distribution dictates the amount of planning effort required. Marketing encompasses more than mere promotion and consists of four foundational elements: product, price, placement, and promotion. In MBA terms, product and price involve creative processes to develop a profitable offering matching customer needs. Placement determines how customers acquire the product, while promotion spreads the word to influential people and potential customers.

Common Bad Planning Methods

Teams often fall into lazy, counterproductive habits during the planning phase instead of conducting proper research.

• repeating what was done last time;
• focusing entirely on unfinished features from previous releases;
• copying competitors feature-for-feature;
• chasing trendy technologies;
• relying on the flawed assumption that building a great product automatically attracts users.

Customer Research and Requirements

Relying on a single customer research method is a major mistake because each method is only suited for measuring specific attributes. Projects should combine multiple research methods to counteract individual biases.

• Focus groups allow extended dialogue but yield difficult-to-analyze discussions.
• Surveys provide broad trends at low cost but suffer from low reliability.
• Site visits offer memorable observations of true customer experience.
• Usability studies quantify ease of use in controlled environments.
• Market research captures business views and revenue projections but ignores behavioral motivations.

Requirements are best established by first translating customer research into pure problem statements and then converting them into user scenarios. Problem statements are concise, one- or two-sentence descriptions capturing end-user issues strictly from the customer perspective without prescribing engineering or business solutions. Once formulated, these problems are converted into feature statements or scenarios describing what a customer will be able to accomplish.

4. Visions and Where Ideas Come From

Large projects require a structured hierarchy of goals spanning the entire project, specific component teams, and individual contributors. A proper goal structure prevents people from losing focus over long periods. Project Hydra uses a top-down structure where the main web site vision is divided into team responsibilities for search, accounting, inventory, HR, and travel.

A high-level project vision must simplify decisions, contain goal-driven intentions, and remain memorable to the team.

Scott Berkun calls this the vision. You can apply it by keeping high-level goals between three and five.

• Simplify by making the vision a rulebook used constantly for decisions.
• Keep high-level goals between three and five.
• Consolidate supplemental thoughts into a single accessible reference.
• Anchor inspiration in a real-world problem rather than just technological challenges.
• Make it memorable through direct and honest writing.

Writing Well and Visualization

Leadership documents require a single primary author rather than a committee to maintain clarity, conciseness, and a strong voice. Committees produce bloated, jargon-laden, and pompous writing because they obscure ideas through volume. The Continental Congress formed a committee in 1776, but tasked Thomas Jefferson with drafting the Declaration of Independence.

Visions should include visual images, mock-ups, or prototypes because pictures provide faster access and greater clarity than words. The Palm Pilot handheld organizer team used specific goals for size, cost, simplicity, and PC synchronization.

• Size: Fit into a shirt pocket and be light enough not to seem unwieldy.
• Cost: Less than a luxury paper organizer ($300 USD).
• Simplicity: Should be as simple as paper, turn on instantly, and use simple conventions.
• Sync with PC: Use the PC as a common point of interaction for the customer.

Generating Ideas and Questions

Generating bad ideas is a mandatory prerequisite for discovering successful designs.

You must expect early mistakes to build momentum. Minoxidil was originally a medication for high blood pressure that failed its initial context but succeeded as a hair loss treatment.

• Yes, and.... When someone offers a thought, your first attempt must be to continue his line of thinking and move it forward or redirect it.
• No half-assing. Stand behind what you say without apologizing or declaring that you are not good at being creative.
• No blocking questions. Do not put ideas and people on the defensive with judgmental questions like Why the hell would you do that?.
• Make the other guy look good. Do not keep score or credit; reward people who help amplify and draw out the best ideas from others.

5. Managing Ideas and Specifications

Managing design requires a gradual dimmer switch approach to transition from creative exploration into specifications.

Treating design like an on-off switch disorients the team. You must act like a dimmer switch, guiding the group through a gradual shift from exploring many choices to narrowing down options.

Idea Checkpoints and Prototypes

Establishing clear intermediary checkpoints helps you navigate the fuzzy and subjective problem space. Breaking the creative phase into milestones gives the team a frame of reference to measure progress and handle scope shifts.

• Vision and proof-of-concept: Deliver a proof-of-concept prototype with the vision document.
• Idea groupings/lists: Organize and consolidate the initial wave of new ideas.
• Three alternatives: Narrow possible design directions down to three to five alternatives after the halfway mark.
• Two alternatives: Research and prototype until two clear directions remain.
• One design: Make a final direction choice.
• Specification: Document the single chosen design.

Affinity diagrams help teams visually group messy idea pools into manageable buckets. Lists promote linear thinking and become unmanageable with many items. Using Post-it notes on a wall allows people to focus on relationships and move options freely.

Scott Berkun encountered a massive problem space tracking features on the Internet Explorer 4.0 project, where requirements filled an entire whiteboard.

• Write each idea on a Post-in note described in just a few words and place it on a wall.
• Have the lead designer, project manager, or small team take a first cut at organizing the notes.
• Allow others to move ideas between groups, change group names, and remove duplicates.
• Aim for four or five groups that cover different ground or imply different directions.

Writing Specifications

Prototypes serve as the natural next step in design by letting you explore alternatives without taking on the risks of full implementation. They do not need to be elaborate; a napkin sketch works for early questions.

• Pick the most promising idea from each group and try to combine them in one design.
• Do small prototypes for each group to see where they go.
• See how far remodeling the architecture or adding customization takes the design.
• Allow the designer to use experience and intuition to decide what to use in a first stab.
• Make a list of the hardest or most important design questions, and make prototypes to answer them.

User interface prototypes must be built from the top down, starting with what users see before planning technical details. Planning databases before creating screen mock-ups wastes production-quality work.

• Start with what users will see and the sequence in which they will see it.
• Involve usability and design experts as early as possible.
• Wait for promising sketches or mock-ups before engineers explore implementation.
• Do as little work as necessary to get the needed information using any tool like paper, HTML, or Flash.

Decision Making

An open-issues list is an essential tool for tracking unresolved questions, prioritized by their potential impact on engineering. You maintain this list on a whiteboard to drive unanswered questions to resolution.

• Start with a rough list of unanswered questions and grow its detail as specifications are written.
• Assign the name of the person driving the issue next to each item.
• Divide the list into two priorities: things needed before specifications and things that can wait.

Specifications should be divided into distinct types of information to ensure appropriate authors write the right details.

• Draft a requirements specification to outline requests and obligations as victory conditions.
• Create a feature specification describing behavior from the customer perspective.
• Detail the engineering approach in a technical specification for complex components.
• Generate a work-item list of programming assignments broken down into daily estimates.

6. Communication and Process

Projects depend on informal peer conversations, clear role definitions, and non-annoying processes rather than strict hierarchies.

Communication progresses through five increasingly difficult states: transmitted, received, understood, agreed, and converted to useful action. Effective communication requires going deep into these states, as simply transmitting a message or having it received guarantees neither comprehension nor compliance. Project managers must diagnose where communication fails within this model.

In 2001: A Space Odyssey, astronaut Dave transmits a request to open the pod bay door to Hal, who receives and understands the request but refuses to agree, leaving Dave helpless.

Projects depend on peer-to-peer relationships and informal conversations rather than strict military hierarchies to achieve synchronicity and buy-in. Bullying or demanding commands kill motivation and reduce the probability of getting people's best work. Engaging in dialogue and practicing management by walking around (MBWA) builds trust and gives leaders advanced insight into team issues.

Scott Berkun observed early Microsoft managers Ken Dye and Joe Belfiore spending significant time chatting in people's offices, realizing later that these conversations were vital investments in people and information.

Project communication frequently breaks down due to predictable behavioral traps that managers must identify and resolve.

• Clarify assumptions at key points when commitments are made and confirm them again before deadlines.
• Break down ideas into smaller pieces and use stories or analogies to reach clarity.
• Accept the possibility that others know something you don't rather than forcing a position.
• Separate underlying issues when someone responds with displaced negative feelings.

Communication States and Relationships

Role definition sessions eliminate ambiguous expectations and flush out historical baggage between project managers and team members. Because every team member carries baggage and assumptions from previous project manager experiences, formal role clarification is essential.

• Sit down with one person you work with and make three lists on a whiteboard.
• List 1: Things you are primarily responsible for.
• List 2: Things both of you share responsibility for.
• List 3: Things the other person is primarily responsible for.
• Discuss where items belong to flush out assumptions and baggage.

Asking team members how to help them do their best work improves performance, boosts morale, and uncovers hidden obstacles. Managers rarely talk about how hard people work or what their best work looks like.

• Ask anyone directly: What can I do to help you do your best work?
• Use leadership tools such as listening, clearing roadblocks, teaching, and reminding team members of goals.
• Prioritize assisting direct contributors ahead of secondary political or bureaucratic matters.

The author recalls how programmers on the Windows team who initially shrugged off the question would return a week later with great suggestions that helped the entire development team.

Process and Email Practices

Tracking work and making decisions inevitably causes friction, but managers can minimize annoyances by avoiding treatment as an idiot or untrustworthy. As teams grow larger, project management activities risk annoying people through bureaucracy, excessive tracking, or rigid rules.

Good processes must accelerate progress, prevent problems, and make actions measurable while remaining adaptable. A process is any repeatable set of actions meant to ensure work is done a certain way.

• Ask: What is the least intrusive, least annoying, and least expensive way to make sure that X, Y, and Z never happen again?
• Define processes through small-group pilots involving receptive individuals before wider rollouts.

When burdened by top-down bureaucratic processes, project managers can shield their team, bet against the process, or ignore it.

• Shield your team by absorbing annoying trivia and administrative paperwork yourself.
• Bet against the process by rallying the team around a counterproposal and agreeing to adopt the process only if targets are missed.
• Ignore distant bureaucratic things to force a dialogue or prove their irrelevance.

Effective project email requires optimizing for communication efficiency, offering clear actions, and avoiding narratives or play-by-plays.

• Be concise, simple, and direct; step away and reread important emails before sending.
• Offer a specific action and a clear deadline.
• Prioritize issues and avoid giving a play-by-play narrative or background history.
• Sequester FYIs into separate discussion aliases or mark them with low priority.
• Use the telephone or a hallway walk instead of an elaborate multi-part email exchange.

The author describes receiving private 'Good email' notes from Microsoft VPs as a reward for crafting simple, strong, and clear arguments during heated cross-hierarchical debates.

Running Better Meetings

Meetings easily degrade into bloated wastes of time unless actively managed, and they require a dedicated facilitator to guide participants through structured questions without pushing personal opinions. Meetings consume massive person-hours, making them expensive compared to individual computer work. A 1 hour meeting with 10 people costs 10 person-hours.

• Establish a host position by clarifying the agenda and introducing people right away.
• Carefully choose where you sit, as sitting at the head or center gives the most authority while the corner gives the least.
• Listen and reflect by restating what participants say to refine their points collaboratively.
• Direct the conversation by keeping it on track using the agenda and managing who speaks.
• End the conversation by having a threshold for when an issue should be resolved elsewhere by specific owners.

Scott Berkun describes an intense Windows architecture debate where conflicting diagrams were sketched out wildly until group manager Hadi Partovi stood up, quietly wrote a list of questions on the whiteboard, and led the team through them one by one without offering his own opinion.

Meetings fail when their size does not match their goals, and organizers must choose the correct meeting type for the specific problem being solved. Interactive discussions cannot scale beyond eight people because dominant personalities take over.

• Use highly interactive discussion for depth and intimacy with small to medium groups of 2 to 8 people.
• Use reporting or moderate discussion to share knowledge or get high-level feedback with medium to large groups of 5 to 15 people.
• Use status and project review to summarize project status and present leadership directives with medium to large groups of 10 to 100 people.

Recurring meetings often outlive their usefulness and waste time, but they can be controlled by implementing an opt-in agenda rule. Scott Berkun notes that some buildings at Microsoft had conference-room scheduling systems entirely clogged up by abandoned recurring meetings.

• Keep recurring meetings on schedule and ask everyone to check email for an agenda five minutes before starting.
• Hold the meeting only if a solid agenda was sent out by the organizer.
• Cancel the meeting for that week via email if there is no agenda.
• Cancel the recurrence entirely if no meeting occurs for more than three or four weeks.

7. Handling Crises and Building Trust

Leadership is based on trust rather than high-drama heroics, serving as essential insurance against project adversity.

Adversity is normal on successful projects. Resiliency matters more than trying to avoid risks completely.

In 1996, Scott Berkun experienced a disastrous review meeting working on parental control features for IE 3.0. Nine out of ten experienced developers and architects were deeply disappointed by his answers. This taught him a harsh trial-by-fire lesson about thorough preparation.

When unexpected disasters strike, a systematic rough guide helps teams stay resilient. Panic makes crises worse.

• Calm down by controlling fear, anger, and frustration before acting.
• Evaluate the problem in relation to the project by determining the true percentage of risk and eliminating assumptions.
• Calm down again and find safe ways to express emotions before returning to the problem.
• Get the right people in the room by pulling key stakeholders together immediately and keeping the group small.
• Explore alternatives by delegating research with clear urgency expectations.
• Make the simplest plan by choosing the best available option and breaking it into straightforward steps.
• Execute the plan with specific checkpoints and hourly, daily, or weekly reviews.
• Debrief after the fire is out to generate a list of lessons learned.

Emotional Toolkit and Trust

Pressure acts as a constraining force with fixed limits. Pushing a team past its maximum performance threshold leads to burnout rather than better results.

Gerald Weinberg published Quality Software Management Volume 1: Systems Thinking in 1996. His performance curve shows team output increasing with pressure up to a point. After that, performance flattens and the team eventually snaps or redlines.

• Release pressure by giving people an afternoon off.
• Play an impromptu game of touch football in the parking lot.
• Adjust the workload or schedule to something sane.

Virginia Satir developed a psychological model for human feelings. When you experience a primary feeling like sadness, you can quickly develop a secondary feeling like anger about that first feeling.

The hero complex drives individuals to compulsively create or sustain dangerous situations. Heroes operate on the flawed belief that planning is unnecessary.

• Push hard for a policy of review around heroic acts.
• Hold a public discussion of what could have been done to avoid the situation.
• Distribute rewards for those who find a way to prevent that kind of situation from occurring again.

Trust is earned through consistent behavior, competence, and fairness. Watts S. Humphrey published Managing the Software Process in 1989. His work shows that a valid commitment requires willingness, weighed resources, and mutual bounds.

Coach Rob Elkins pulled Scott Berkun aside during basketball practice at the Samuel Field Y in Douglaston, New York. He gave Berkun the green light to shoot whenever appropriate, which made Berkun play with much higher intensity and loyalty.

• Identify specific things you are concerned about and ask the team member to check in on those points.
• Ask what the team member needs and negotiate support.
• Direct people to focus on making things happen instead of seeking approval.

Power and Politics

Organizational politics is an inevitable by-product of human life. In 1997, Berkun learned his first major lesson about politics from Chris Jones, group program manager for Internet Explorer.

Thomas Quick published Power Plays: A Guide to Maximizing Performance and Success in Business in 1985. The Random House College Dictionary was published in 1999.

During Internet Explorer 2.0, Berkun worked with a senior level 13 programmer named Bill who treated him with sarcasm. Berkun was a 23-year-old program manager. He earned Bill's trust rather than using granted autocratic power.

• Clarify what you need in terms of resources, authority, influence, goal adjustment, or expertise.
• Manage up by aligning expectations, resources, and involvement levels with your manager.
• Identify who has the power to give what you need by looking beyond the org chart.
• Understand the perspective of the person holding power by mapping their goals to project requirements.
• Identify who the powerful person trusts and respects to use their influence.

8. Execution, Strategy, and Making Things Happen

Project management centers on creating and maintaining clear, ordered lists of priorities to eliminate confusion and drive progress. A project manager collects requirements, features, and bugs and orders them by importance to provide a shared framework of logic.

Things happen when you say no, maintain ordered priority lists, know the critical path, and remain relentless.

Scott Berkun notes a case where a feature request to support the Esperanto language on a website search engine was permanently rejected with a firm no. You must force any new addition to be justified against project goals.

• Collect things that must be done like requirements, features, and bugs.
• Put them in an order of importance to the project.
• Ensure every engineering work item maps to a feature, and every feature maps to a goal.
• Force any new addition to be justified against project goals.

Priorities and the Critical Path

Critical path analysis reveals where bottlenecks lie so that delays in dependent components do not stall priority 1 work. You can apply this method to engineering tasks, human relationships, decision-making processes, and review procedures.

• Map out work items to show which items are dependent on which others.
• Identify the bottlenecks and critical points in engineering and team processes.
• Focus team attention directly on the elements and decisions central to progress.
• Distribute authority across the team to remove non-engineering bottlenecks and bureaucratic overhead.

Middle-Game and End-Game Strategy

Mid-game occurs in the middle of the overall schedule when some elements work while others fail. Because multiple things happen simultaneously, maintaining clarity becomes difficult, and energy and stress levels peak as margins of error shrink.

• Ask tactical questions once a day regarding goals, commitments, and daily work alignment.
• Ask strategic questions once a week regarding milestone probabilities, required adjustments, and top project risks.

10 Key Ideas

1. Modern project management shares universal constants like requirements and budgets with historical builders, making failures powerful sources of progress when studied openly.
2. Schedules serve three distinct purposes as external commitments, forcing functions, and progress tracking tools, with early estimates suffering from a 400% maximum error range.
3. Successful project planning requires balancing business, technology, and customer perspectives instead of favoring a single viewpoint, combining multiple research methods to counteract individual biases.
4. A high-level project vision must simplify decisions, contain goal-driven intentions, and remain memorable to the team, keeping goals between three and five while utilizing visual images and mock-ups.
5. Managing design requires a gradual dimmer switch approach to transition from creative exploration into specifications, where generating bad ideas serves as a mandatory prerequisite for discovering successful designs.
6. Projects depend on informal peer conversations, clear role definitions, and non-annoying processes rather than strict hierarchies, requiring leaders to diagnose communication failures across five distinct states.
7. Handling crises systematically requires calming down, evaluating the true percentage of risk, pulling key stakeholders together into a small group, and executing the simplest plan.
8. Leadership is based on trust rather than high-drama heroics and serves as essential insurance against project adversity, where trust is earned through consistent behavior, competence, and fairness.
9. Organizational politics is an inevitable by-product of human life that requires project managers to manage up, look beyond the organizational chart, and understand the perspectives of powerful people.
10. Things happen when you say no, maintain ordered priority lists, know the critical path, and remain relentless in forcing new additions to be justified against project goals.