Key Takeaways
Every project moves through the same four phases that overlap
The universal arc of any project. Whether you are launching a website, moving a department, or building robotic arms for a space station, the work travels through four stages: planning (defining the real problem, stakeholders, and objectives), build-up (assembling the team, scheduling, budgeting), implementation (executing, monitoring, fixing problems), and closeout (evaluating, closing, capturing lessons).
They bleed into each other. You start planning with a ballpark budget and rough end date, then revise both as the build-up and implementation phases surface new information. Each phase demands different skills: planning rewards task analysis, build-up rewards delegating and team building, implementation rewards conflict management, and closeout rewards follow-through. Recognizing which phase you are in tells you which muscle to flex rather than defaulting to whatever feels urgent.
What's useful about this phased map is that it counters the amateur's instinct to jump straight to a Gantt chart. The guide insists scheduling belongs in build-up, not planning. This echoes systems thinking: front-loading definition reduces expensive rework downstream. The overlap point matters too. Rigid stage-gating can create the illusion of finality when reality keeps shifting. The framework's honesty about revision (revisiting budgets as understanding deepens) aligns with modern rolling-wave planning, where you detail near-term work precisely and leave distant work coarse until knowledge arrives.
Solve the real problem, not the symptom you noticed first
Dig beneath the presenting complaint. An IT manager asked to build a new database might rush to fix the frustrations she personally felt, like slow reports. The guide warns that this produces solutions that are too simple, too complex, or solve the wrong thing. Before designing anything, ask what data is truly needed, who uses it, and how urgently.
Framing widens your options. A consultant quoted in the book reframes "our riveting equipment runs too slowly" into "our manufacturing cost is too high," which suddenly permits redesigning the product to need fewer rivets. Defining the problem first, another expert argues, buys you more degrees of freedom in solving it. Cognitive bias research shows decision makers anchor on how they initially frame a topic, so a sloppy first framing quietly narrows everything that follows.
This is the project management version of the doctor treating disease rather than symptom. The rivet example is a small masterpiece of reframing, and it connects to Theodore Levitt's classic marketing insight that customers buy quarter-inch holes, not quarter-inch drills. The danger the guide underplays is analysis paralysis: some teams hide in problem-definition to avoid the risk of committing. The healthiest practice pairs rigorous framing with a bias toward small experiments, so understanding and action reinforce each other rather than one stalling the other.
A signed charter prevents the disaster of unspoken expectations
Lila's cautionary tale. A project manager named Lila improved order fulfillment by a third and cut costs 12%, hitting every goal her team set. Her sponsor was still disappointed: he had wanted a sweeping reorganization and bigger savings. He simply never said so. The fix is a charter, a short written document naming the sponsor, the benefits, the objectives, the time frame, the budget, and the manager's authority, signed at the top.
Specify ends, leave means to the team. A good charter states what success looks like in measurable terms, then hands the how to the people you recruited for their competence. Objectives should be SMART: specific, measurable, action-oriented, realistic, and time-limited. Instead of "fast, accurate," pin down whether one error in 1,000 or one in 10,000 is acceptable.
Lila's story is the guide's most human moment, and it dramatizes a truth organizational psychologists call the expectation gap. Ambiguity is not neutral; it defaults to the most powerful person's private assumptions, which surface only at judgment time. The charter functions like a contract that forces the sponsor to think, which is precisely why busy sponsors resist creating one. The book's separation of ends from means echoes Richard Hackman's team research: over-specifying method wastes the expertise you hired. The quiet risk is treating the charter as frozen when complex projects demand it evolve through negotiated amendments.
Break the work into a Work Breakdown Structure before scheduling
Subdivide until tasks cannot be split. The Work Breakdown Structure (WBS) is a planning tool that repeatedly asks "what must be done to accomplish this?" until you reach tasks small enough to estimate in dollars and person-hours. A typical WBS runs three to six levels deep; only enormous projects approach twenty. The book illustrates it with a server migration broken into obtain equipment, provision, test, go live, test again, and decommission, each with subtasks and durations.
Why it matters. Many projects fail because they bite off more than they can chew or overlook a chunk of work entirely, grossly underestimating time and money. The WBS is your defense against both. Crucially, in planning you ignore sequence; you build the framework of what, then handle the order later during build-up scheduling.
The WBS is the unglamorous backbone of project discipline, and its power is decomposition, the same principle that lets programmers tackle vast software by breaking it into functions. Cognitive science supports it: humans estimate small, concrete tasks far more accurately than large abstract ones, a partial antidote to the planning fallacy Daniel Kahneman documented, where people chronically underestimate durations. The book's honesty about padding estimates openly is refreshingly practical. One limitation: a WBS captures known work beautifully but is blind to the unknown unknowns that plague genuinely novel projects, which is why it pairs best with explicit risk exercises.
Run a premortem: imagine the project already failed, then explain why
Prospective hindsight beats polite silence. Psychologist Gary Klein's premortem flips the postmortem. Instead of dissecting a corpse after death, the team assumes at the outset that the project has already failed spectacularly, then everyone privately writes down every reason why. Research by Deborah Mitchell and colleagues found that imagining an event has already happened boosts the ability to correctly identify causes by 30%.
It gives dissenters cover. In one session, a quiet engineer finally admitted an algorithm would not fit on field laptops, nearly sinking a military project. The developers, it turned out, had a shortcut they had been too shy to mention. In another, someone surfaced a corporate deadline no one had raised in a 90-minute kickoff. The premortem legitimizes the reservations people normally swallow for fear of seeming impolitic or disloyal.
The premortem is one of the most portable ideas in this collection, and its genius is social, not analytical. It reframes criticism as a game everyone is invited to win, dissolving the loyalty pressure that silences doubters. This connects to Irving Janis's groupthink research and to Amy Edmondson's work on psychological safety: teams underperform not from lack of knowledge but from fear of voicing it. The 30% figure should be held loosely, given it rests on a single 1989 study, but the mechanism is robust across domains. The technique costs minutes and can save millions, an asymmetry that makes skipping it hard to justify.
Guard scope fiercely, but bend when a real opportunity appears
Distinguish purpose from scope. A project's purpose is the broad benefit (boost holiday sales 40%); its scope is the specific deliverables the team controls and agreed to produce. Scope creep is the slow accumulation of small tweaks that quietly bust the schedule and budget. Defenses include a change control board for large projects, a rule that any change exceeding 5% of a line item's budget triggers a formal request, and caps on new features.
Not all creep is bad. During construction of a Harvard residence hall, adding ten guest rooms initially looked like creep. A return-on-investment analysis showed the extra rooms would pay for themselves through the larger income stream, so the add-on was approved. The test is not "does this change the plan?" but "does disciplined analysis show it creates more value than it costs?"
The guide resists the macho posture that all change is weakness. That nuance matters, because rigidly frozen scope is how organizations ship products the market no longer wants. The real skill is building boundaries clear enough that only serious proposals survive the filter, which is a governance design problem more than a willpower problem. This mirrors options thinking in finance: a well-defined baseline makes the value of deviating computable. The 5% threshold and change control board are bureaucratic scaffolding that, applied to a tiny project, would suffocate it, which the book wisely notes by exempting sub-million-dollar efforts.
Time-box the work so calendars enforce your priorities
Three steps to reclaim hours. Time-boxing tackles the fact that no one gets more than 24 hours a day. First, list everything you and the team want to accomplish this week, month, or quarter. Second, estimate how long each item truly takes, which one CEO called the step that keeps him honest, because when he misses an estimate he can diagnose why. Third, block off that time on the calendar, like reserving four hours every Tuesday and Thursday for a month to write a business plan.
The hidden benefits. A full calendar forces honest tradeoffs: a team member with no open blocks must decline extra requests or renegotiate priorities out loud. Time-boxing sharpens your estimating over time and, crucially, lets you spot and kill unproductive initiatives that quietly devour hours.
Time-boxing has since become a cornerstone of agile methods and the Pomodoro technique, and its deeper value is making the invisible visible. Unscheduled intentions compete with everything; a calendar block converts a vague wish into a defended commitment. Behavioral economists would note it exploits precommitment, binding your future self the way Ulysses lashed himself to the mast. The estimating-improvement loop is the underrated payoff: comparing predicted to actual durations is deliberate practice against the planning fallacy. The risk is rigidity. Over-boxed calendars leave no slack for the interruptions and discoveries that knowledge work generates, which is why the guide sensibly urges building in leeway.
Find your critical path and protect the tasks that sit on it
Not all tasks are equal. The Critical Path Method (CPM) identifies which tasks must finish on time for the whole project to hit its deadline, because they form the longest chain of dependencies. In the book's auto example, designing then building and testing external components then testing the vehicle is the critical path; the internal-components path has two days of slack. Delays on slack tasks cost nothing until the slack runs out, but any slip on a critical task slips the entire project.
Tools serve communication. A Gantt chart shows start and end dates at a glance but hides dependencies. A PERT chart maps dependencies and milestones. Working backward from immovable deadlines, like an annual report that needs two weeks at the printer, tells you when each deliverable must be ready.
CPM, developed in the 1950s for industrial projects, remains powerful because it directs scarce attention. Its lesson is counterintuitive: finishing non-critical tasks early does not speed the project, so heroics there are wasted. This is a project-level version of the theory of constraints, where only work on the bottleneck improves the whole system. The subtler modern critique comes from Eliyahu Goldratt's critical chain method, which argues that task-level padding gets squandered through Parkinson's law and should be pooled into project buffers instead. Still, the core discipline of knowing which delays actually hurt is indispensable, and most failed schedules ignore it entirely.
When uncertainty is high, build in fast iterative loops, not one big bet
The big-bang trap. The REACH case study dramatizes it: Canada rushed $1.2 billion robotic arms to the space station on a compressed parallel-development schedule, hit the deadline and budget, but the arms failed their first real repair and an astronaut had to fix a solar array by hand. Commentators split, but the deeper lesson is that no amount of upfront perfection can foresee every issue in genuinely complex work.
Adapt instead. Cisco's rapid iterative prototyping runs small tasks as probes, learns from each, and adjusts. Sponsors act like venture capitalists, funding in stages as information arrives rather than dumping resources upfront. Ellipsus used what-if planning to prototype two rival standards before choosing. Carlson used chunking to split a rejected $15 million reservation system into standalone pieces; its voice chunk alone later earned $40 million a year.
This is where the guide meets modern agile and lean startup thinking head-on. The insight that experimentation requires tolerating failure, and that government agencies avoid experimentation because failure ends careers, is a sharp piece of institutional analysis. It explains why bureaucracies produce spectacular big-bang flameouts while startups iterate to success. The venture-capital sponsor model is essentially real-options theory applied to management: each stage buys the option, not the obligation, to continue. One caveat the REACH debate surfaces honestly: iteration is not always cheap or safe. For a one-shot object 350 kilometers up, or a bridge, the build-test-learn loop has hard physical and ethical limits.
Report bad news as risks to objectives, and give options
Monitor to control, not just observe. Ray Sheen's five steps are track activities, collect performance data, analyze whether the plan still holds, report to stakeholders, and manage changes. He uses ten-minute pulse meetings covering only tasks started or finished since the last one, and buddy checks where a teammate quickly verifies work. During a crisis when a facility's power failed three days before launch, he pulsed the project every three hours instead of weekly.
Speak the stakeholder's language. Executives care about business goals, not technical detail. One leader bored his reviewers with 30 minutes of design talk when five minutes of "on schedule, no new risks" would have served. When delivering bad news, frame it as a specific threat to project objectives and always attach response options with their risks, letting stakeholders choose which risks the business accepts.
The distinction between monitoring and controlling is the crux: data without response is theater. Sheen's insistence on framing problems as risks-plus-options is emotionally intelligent management, because it converts a manager who brings problems into one who brings decisions, preserving credibility. This aligns with research on upward communication, where messengers of bad news are punished unless they arrive with a path forward. The stoplight dashboard he describes is powerful but famously gameable: watermelon projects, green on the outside and red within, are a known pathology. Effective monitoring therefore depends as much on psychological safety as on reporting formats, so people surface reds before they metastasize.
Stop chasing sunk costs; the money is already gone
The bus-stop trap. If a high-profile product is failing and the market has shifted, spending another dime to recoup your $10 million is the wrong move. Sunk costs are investments you can never recover, and Max Bazerman likens throwing more after them to waiting at a bus stop for hours: at some point you admit the bus is not coming. This nonrational escalation of commitment is a cognitive bias.
How to escape it. Judge the quality of the decision, not the outcome, so people stop fearing blame for good-at-the-time calls. Gather outside evidence and devil's advocates to counter the urge to justify past choices. Set precise targets in advance for how much time and money you will invest before demanding results. As Buffett quipped, when you are in a hole, stop digging.
The sunk-cost fallacy is among the most replicated findings in behavioral economics, and the guide's practical framing is strong. The distinction between decision quality and outcome quality is what poker players call resulting, judging a choice by how it turned out rather than by what was knowable when it was made. Organizations that punish acts of commission more than omission actively breed escalation, since doing nothing hides the error while changing course triggers scrutiny. One intriguing nuance the book cites: Dilip Soman found people resist sunk costs less when the investment is time rather than money, and grow more susceptible as they learn to convert time into dollars, a warning that financial literacy can sometimes amplify a bias.
Success means hitting your charter's goals, not finishing every task
Close on benefits, not the Gantt chart. Ray Sheen recalls a project remembered as one of his best that was poorly planned and ran 10% over budget, rescued entirely in closeout because the launched product met market needs and sold beyond expectations. Stakeholders care about business benefits, not adherence to the critical path. Validate that the charter's goals were met, then wind down one of three ways: hand off to yourselves, terminate, or integrate into another group.
Then harvest the learning. A post-evaluation, held as discovery not blame, captures lessons while memory is fresh. On multi-year projects, gather lessons after each phase, because by the end the original team has scattered. Tools like the punchlist of final action items and the scope creep parking lot keep last-minute requests from derailing closure. Above all, celebrate before critiquing.
The closeout phase is where most organizations grow lazy, treating shipped as done and skipping the reflection that compounds capability. The guide's point that lessons-learned reports are seldom read is bracingly honest, and its fix, converting lessons into action items baked into the next project's checklists and templates, is what learning organizations actually require. Reflection without embedded change is nostalgia. The insistence on celebration before criticism reflects sound behavioral science: recognition reinforces the discretionary effort you will need next time, and leading with blame teaches teams to hide problems. The blame-free after-action review is a discipline the U.S. military formalized precisely because fear corrupts honest debriefs.
Analysis
This is a business how-to anthology, not a single-thesis argument, assembled by Harvard Business Review from Pocket Mentor guides, Harvard Business Essentials, and reprinted HBR articles by named experts including Gary Klein, Ron Ashkenas, Ray Sheen, and Clayton Christensen. Its structure follows a clean four-phase spine (planning, build-up, implementation, closeout), which makes it easy to navigate but also uneven in voice and depth, since chapters range from checklists to a fictional case study with dueling commentaries. The difficulty in summarizing it lies in that heterogeneity: it is less a book with an evolving idea than a toolkit of loosely coupled techniques.
The collection's enduring value is its refusal to reduce project management to scheduling software. Its recurring theme, threaded through Lila's charter failure, the premortem, and the sunk-cost chapter, is that projects fail for human and cognitive reasons far more than technical ones: unspoken expectations, silenced dissent, escalation of commitment, and confusing motion with progress. This puts the guide in quiet conversation with behavioral economics and organizational psychology, decades before those framings became fashionable in management writing.
Where it shows its 2011 vintage is the tension between traditional plan-driven control (WBS, CPM, Gantt) and the adaptive, iterative methods it gestures toward through Cisco and the REACH debate. Modern agile has largely won that argument for software and product work, and a contemporary reader will notice the guide hedging rather than committing. Yet its instinct to match method to uncertainty, heavy planning for predictable work, fast loops for novel work, is exactly right and more sophisticated than either camp's purists.
The practical reader should treat this less as a doctrine and more as a diagnostic menu: know which phase you are in, which cognitive trap threatens it, and which single tool defuses that trap. Its greatest gift is teaching managers to define the real problem, disappoint sponsors early with honest estimates, and measure success by delivered benefit rather than tasks checked off.
Review Summary
HBR Guide to Project Management receives mixed reviews, with an average rating of 3.79 out of 5. Many readers find it a good introduction to project management, praising its concise and practical approach. It's particularly helpful for beginners or those seeking a refresher. The book covers project phases, offers useful frameworks, and includes real-life examples. Some experienced project managers find it too basic, while others appreciate its value as a quick reference. Readers highlight its clarity, organization, and applicability to various industries.
People Also Read
Glossary
Charter
Signed document defining project scopeA concise written document, signed by the sponsor, that spells out a project's nature, benefits, objectives, expected time frame, budget, and the project manager's authority. It forces senior management to articulate what success looks like up front, specifying the ends while leaving the means to the project team, thereby preventing costly misunderstandings about expectations later.
Work Breakdown Structure (WBS)
Hierarchy of subdivided project tasksA planning tool that repeatedly asks what must be done to accomplish a goal, subdividing the project into progressively smaller tasks until each is small enough to estimate in dollars and person-hours. Typically three to six levels deep, it prevents teams from overlooking work or underestimating time and cost. Sequence is ignored at this stage.
Premortem
Imagining failure before startingA risk technique by Gary Klein where, at a project's outset, the team assumes it has already failed spectacularly and each member privately writes every plausible reason why. Using prospective hindsight, it surfaces reservations people normally suppress for fear of seeming impolitic, and it sensitizes the team to early warning signs.
Critical Path Method (CPM)
Longest chain of dependent tasksA scheduling technique that identifies the tasks which must finish on time for the whole project to meet its deadline, forming the longest chain of dependencies. Tasks off the critical path carry slack and can absorb delay harmlessly, but any slip on a critical-path task delays the entire project.
Scope creep
Uncontrolled accumulation of project changesThe tendency, often driven by stakeholder pressure, to permit small changes that exceed a project's agreed scope and collectively wreck the schedule, budget, or quality. Defenses include change control boards, thresholds triggering formal change requests, and caps on new features. Not all creep is bad if disciplined analysis shows a change creates more value than it costs.
Time-boxing
Blocking calendar time for tasksA productivity technique with three steps: list what you want to accomplish, estimate how long each item takes, then block off that time on your calendar. It forces honest prioritization, improves time estimation over repetition, and exposes unproductive initiatives that consume disproportionate hours.
Rapid-results initiatives
Small fast slices delivering valueSmall vertical projects that quickly deliver a mini-version of a big project's end result in under 100 days, drawing people from different functions to work together. They combat white space, execution, and integration risks by ironing out kinks early on a small scale and serving as models for larger rollout.
Sunk costs
Unrecoverable past investmentsInvestments of money or time that can no longer be recovered. Chasing them leads to nonrational escalation of commitment, a cognitive bias. Sound decisions ignore prior investment and focus on the present situation, judging decision quality rather than outcome, and setting predefined targets for when to stop.
Tollgate review
Phase-gate go or kill decisionA decision meeting, also called a stage-gate or phase-gate review, used when a project runs in discrete phases. The team summarizes the completed phase and presents a plan for the next, and stakeholders decide whether to approve, redirect, or cancel the project, allocating resources if it proceeds.
Scope creep parking lot
Deferred list of extra ideasA running list where additional ideas or features proposed during a project are parked rather than acted on, so they are neither lost nor allowed to derail the current plan. At closeout the list is reviewed to create follow-on proposals for future phases or releases.
FAQ
What's "HBR Guide to Project Management" about?
- Comprehensive Guide: The book is a comprehensive guide to managing projects effectively, providing tools and strategies for project managers at all levels.
- Four Phases: It outlines the four phases of project management: planning, build-up, implementation, and closeout, detailing the activities and skills needed for each phase.
- Practical Advice: The guide offers practical advice on choosing the right team, avoiding scope creep, and using tools like Gantt and PERT charts.
- Expert Contributions: It includes insights from leading experts and case studies to illustrate real-world applications of project management principles.
Why should I read "HBR Guide to Project Management"?
- Trusted Source: The guide is published by Harvard Business Review, a trusted brand in business education, ensuring high-quality content.
- Skill Enhancement: It helps enhance your project management skills, making you more effective in leading projects and achieving goals.
- Problem-Solving: The book addresses common project management challenges and provides solutions to overcome them.
- Career Advancement: By mastering the techniques in this guide, you can improve your career prospects and become a more valuable asset to your organization.
What are the key takeaways of "HBR Guide to Project Management"?
- Phased Approach: Understand the importance of managing projects through distinct phases, each with specific tasks and objectives.
- Stakeholder Management: Learn how to identify and manage stakeholders effectively to ensure project success.
- Scope and Flexibility: Gain insights into setting project scope and knowing when to be flexible to accommodate valuable changes.
- Lessons Learned: Emphasize the importance of capturing lessons learned to improve future project management practices.
How does the book define the four phases of project management?
- Planning Phase: Focuses on defining the project’s objectives, scope, and resources, and identifying stakeholders.
- Build-Up Phase: Involves assembling the team, planning assignments, and creating a schedule and budget.
- Implementation Phase: Centers on executing the project plan, monitoring progress, and managing any issues that arise.
- Closeout Phase: Entails evaluating project performance, capturing lessons learned, and formally closing the project.
What is "scope creep" and how does the book suggest managing it?
- Definition: Scope creep refers to the uncontrolled expansion of project scope without adjustments to time, cost, and resources.
- Planning: The book advises setting clear project boundaries and involving stakeholders in defining the scope.
- Change Control: Implement a change control process to evaluate and approve any changes to the project scope.
- Communication: Maintain open communication with stakeholders to manage expectations and prevent unauthorized changes.
What tools does the "HBR Guide to Project Management" recommend for scheduling?
- Gantt Charts: Useful for visualizing the project timeline and tracking progress against the schedule.
- PERT Charts: Help in identifying task dependencies and the critical path to ensure timely project completion.
- Critical Path Method (CPM): A technique to identify the sequence of crucial tasks that determine the project duration.
- Draft Schedule: Start with a draft schedule and optimize it by identifying bottlenecks and reallocating resources as needed.
How does the book suggest handling project meetings effectively?
- Purpose and Agenda: Clearly define the meeting’s purpose and provide an agenda in advance to keep discussions focused.
- Participation: Invite only those who can contribute or benefit from the meeting, ensuring productive discussions.
- Follow-Up: Summarize outcomes and action items post-meeting to reinforce decisions and maintain momentum.
- Inclusivity: Encourage participation from all attendees to gather diverse perspectives and foster team collaboration.
What is the "adaptive approach" to project management mentioned in the book?
- Iterative Process: The adaptive approach involves iterative cycles of planning, executing, and evaluating to manage uncertainty.
- Fast Cycles: Emphasizes short lead times and early value delivery to incorporate feedback and learning into the project.
- Flexible Staffing: Staff projects with adaptable individuals who can respond to changes and learn quickly.
- Venture Capital Model: Sponsors support projects in stages, similar to venture capitalists, to reduce uncertainty and manage risks.
What are some common reasons for project failure according to the book?
- White Space: Gaps in the project plan where necessary activities are overlooked.
- Execution Issues: Team members fail to carry out tasks properly, leading to delays and quality issues.
- Integration Failure: Even when tasks are completed, the project fails to deliver intended results due to poor integration.
- Scope Creep: Uncontrolled changes to the project scope that disrupt timelines and budgets.
How does the book recommend capturing lessons learned from a project?
- Formal Sessions: Conduct formal lessons-learned sessions or postmortems to document insights and improvements.
- Continuous Improvement: Use the lessons to refine project management processes and enhance future project performance.
- Team Involvement: Involve the entire team in identifying what worked well and what didn’t to gain diverse perspectives.
- Documentation: Record lessons in a centralized location for easy access and reference by future project teams.
What are the roles and responsibilities of a project manager as outlined in the book?
- Problem Identification: Define the central problem and determine project objectives and scope with input from stakeholders.
- Planning and Scheduling: Develop and oversee the project plan, schedule tasks, and allocate resources effectively.
- Monitoring Progress: Track project activities, manage risks, and ensure the project stays on track to meet objectives.
- Team Leadership: Coordinate team activities, mediate conflicts, and ensure all members contribute to project success.
What are the best quotes from "HBR Guide to Project Management" and what do they mean?
- "Defining the problem first gives you greater degrees of freedom in solving it." This emphasizes the importance of understanding the core issue before jumping into solutions, allowing for more creative and effective problem-solving.
- "Success means achieving the goals in your charter and scope statement—not necessarily finishing all the tasks on your Gantt chart." Highlights the focus on achieving project objectives rather than merely completing tasks.
- "The purpose of teams is not to meet and discuss. It’s to act and produce results." Stresses the action-oriented nature of project teams, where the ultimate goal is delivering tangible outcomes.
- "Don’t get hung up on compliance with the original plan." Encourages flexibility and adaptability in project management to achieve the best results.
About the Author
Other books by Harvard Business Publishing
Download PDF
Download EPUB
.epub digital book format is ideal for reading ebooks on phones, tablets, and e-readers.
