## Metadata - Author: [[Harvard Business Review]] - Full Title: HBR Guide to Project Management - Topics: [[Business development]], [[Strategy]], [[Management (Index)]] - Category: #books ## Summary ### Characters in project management * Sponsor * Champions the project at the highest level in the company * Must have accountability for the project’s performance * Project manager * Receives authority from the sponsor * Identifies the central problem to solve and how to tackle it * Plans and schedules tasks, manages all project phases * Team leader * For large projects – in small projects, same as the project manager * Initiate, model, negotiate, listen, coach * Team member * Criteria for membership * Technical skills * Problem-solving skills * Interpersonal skills * Organizational skills * Each member must contribute to the team’s work and should receive clear benefits. * The goals of the project team and those of its individual members must align with organizational objectives. ### Phase 1: Planning * Written charter * Purpose (why): State the project’s benefits to the organization. * Specific, measureable objectives (what): Briefly describe the project’s ends, but leave the means open to the project team. * Scope: Define what should be within scope and what should not. * Expected time frame (when): Set a reasonable deadline. * Budget and resources available (who) * Project manager’s authority * Fuzzy front end: Manage the initial phase of a complex project * Create a “map” of the people who will be affected in some way by the project. Sketch out how they relate to one another and to the project, then do a political analysis of the key players. * Get input from key stakeholders to get a robust understanding of what needs to be done. * Have conversations with people who are affected by the project, and identify what’s in for them. * Work backward: Imagine what the ideal end state would look like, then work back to put in as much of it as you can given the time, budget, and political realities. * Project premortem: Identify risks at the outset * Prospective hindsight—imagining that an event has already occurred—increases the ability to correctly identify reasons for future outcomes. * Critiquing session: The premortem operates on the assumption that the “patient” has died, and so asks what did go wrong. The team members’ task is to generate plausible reasons for the project’s failure. * Make it safe for dissenters who are knowledgeable about the undertaking and worried about its weaknesses to speak up. * Project creep * The dilemma: How do you stay open to improvements without succumbing to “creep,” in which small tweaks add up to budget- or schedule- busting modifications? * Beware of haste. * Differentiate scope from purpose * Purpose is the general benefit the project will provide to the organization. * Scope comprises the particular elements (or product attributes) that the project team can control and has agreed to deliver. * Scope statement: Make sure the project’s boundaries are sharply delineated and the impact of potential alterations or slippage can be quickly calculated. * Require conscious discussion and approval before significant changes can occur. * When considering a scope change, make sure your stakeholders fully understand the purpose of the change, and how it affects everything. ### Phase 2: Build-up * Set priorities before starting the project * Clarify the assignment: Do not start any activities until your stakeholders have blessed your charter. * Organize your troops: Get people engaged quickly so they feel ownership of the project. Ask for their input and treat them as partners rather than temporary subordinates. * Time-boxing * First, list everything you and your team members want to accomplish in a given period. * Second, estimate how much time each item will require. * Third, block off the appropriate amount of time for each item. * Scheduling the work * Examine relationships and dependencies between tasks. * Develop a list of activities or tasks, and plot out their sequence by determining which ones are critical to achieving the desired final outcome. * Critical Path Method (CPM) * Identify which tasks are critical—those that must be completed on time for the project to meet its deadlines. * Create a list with three columns: Activity (“A, B, …”), Requirement (“B completed”), Time to Complete (“4 days”). * Plot the relationship and sequence of activities in a network diagram. **** * The critical path is the one which takes the longest. Tasks on the critical path determine total project duration. * Gantt chart * Shows when activities should begin and end. * Does not spell out relationships between tasks. ![[Pasted image 20221112101725.png]] * Performance Evaluation and Review Technique (PERT) * Illustrates the critical path and lays out the project milestones. **** * Assign each task a deliverable—for instance, “compose rough draft of survey questions.” * Use deliverables to create a schedule with realistic due dates. * Identify bottlenecks that could upset the schedule. * Determine ways to remove bottlenecks, or build in extra time to get around them. * Establish control and communication systems for updating and revising the schedule. * Keep all stakeholders involved in and informed of the project’s progress and any schedule modifications. * Project roadmap * Objectives of a project roadmap * Simple presentation of the project’s goals, crucial steps, and timeline – anyone should understand it within 3 minutes. * No detailed information, no jargon, just plain language. * Quickly communicate the plan, create shared understanding, manage expectations. * Demonstrate the use of capacity available. * Draw attention to important issues. * Elements of a project roadmap * Status of the document: draft, signed off (by whom?) * Project goals * Timeline with information about when what will happen * High-level titles for big deliverables * Don’t go into detail * Ordered chronologically, maybe by project phases * Maybe separated into different workstreams that happen in parallel * Milestones of key events with expected time of arrival (ETA) * Individual responsibilities and point of contact * Flag areas of high risk and opportunity * SWOT: strengths, weaknesses, opportunities, threats * PESTLE: political, economical, social, technological, legal, environmental * Flag areas with constraints and dependencies * Launch the project * The launch represents the very first project milestone and has symbolic value. * Launch with an all-team meeting. * Engineer time where people get to know each other before the start of the project. * Welcome everyone aboard. Acknowledge and thank all those who will contribute to the project. * Ask your sponsor to say a few words. Have him articulate _why_ the project’s work is important and _how_ its goals are aligned with larger organizational objectives. * Make introductions. Unless people are already familiar with one another, they probably won’t know who has which skills. Map everyone’s skills and figure out the full portfolio of capabilities. * Make sure everyone knows how each teammate contributes. * Share the charter. Explain the goals, deliverables, and timetables you’ve documented. * Seek consensus. Get everyone to agree on what the charter means. * Describe the resources available. * Describe incentives. What will members receive, beyond their normal compensation, if the team meets or exceeds its goals? * Everyone explains how they’ll use the project to develop one critical skill (mutual vulnerability), plus ideas about how people can help each other. * Manage time across teams, and talk about everyone’s competing priorities up front. * At the outset, schedule several full-team meetings at critical junctures. Example: at halftime. Make attendance mandatory, and give every teammate a piece of the meetings to run. * Establish norms of behavior. * Attendance. The team cannot make decisions and accomplish its work if members fail to show up for meetings or joint work sessions. * Interruptions. Turn cell phones off during meetings and work sessions. Also, make it clear that people are not to interrupt others. * Sacred cows. Agree that no issues will be off-limits, and that team members should not be reluctant to discuss them. * Disagreements. Encourage team members to vent disagreements in constructive ways. * Confidentiality. Members will discuss them freely only if what is said within the team stays within the team. * Action orientation. The purpose of teams is not to meet and discuss. It’s to act and produce results. Make that clear from the beginning. * Knowledge transfer. Highlight the benefits of sharing, and provide processes and technology to facilitate it. ### Phase 3: Implementation * Effective project meetings * Before the meeting * Make sure a meeting is even necessary. If you can accomplish your goal efficiently without calling one (via e-mail, for example), do so. * Clarify the meeting’s objective. * Sound out key participants on important agenda items ahead of time. * Invite only people who have something to contribute or who can learn from the discussion. * Provide an agenda in advance that clearly supports the objective. * Insist that people get up to speed on the issues before they arrive, bring relevant materials with them, and show up ready to contribute to the discussion. * Running the meeting * Restate the meeting’s purpose. * Make sure people contribute equally. * Keep the discussion centered on the key issues. * End with confirmation and an action plan that includes a clear time frame. * Following up * Send out a note summarizing the meeting’s outcomes. * Remind individuals of their tasks and deadlines. * Offer support to anyone who may be overwhelmed with other work or may struggle with a task. * Project adaptation and rapid iterative prototyping * Approach tasks iteratively. Engage in small incremental tasks, evaluate the outcomes of those tasks, and make adjustments. * Have fast cycles. Short lead times allow an iterative approach. * Emphasize early value delivery. Small, early deliverables encourage feedback and the incorporation of learning into subsequent activities. * Staff the project with people who can adapt. Some people are faster learners than others and are more amenable to change. * Monitoring and controlling * Track project activities * Check in with team members regularly to make sure they’re completing their tasks and meeting quality standards. * Use “buddy checks” to verify that tasks are done properly. When someone completes an activity, another team member looks at the results to confirm that the person who did the work hasn’t accidentally overlooked something or misunderstood the requirements. * Collect performance data * Seek out performance data through short pulse meetings, where team members share status updates on activities and assess risks. Limit these meetings to 10 minutes and discuss only the tasks started or finished since the last meeting. * Do weekly pulse meetings. When a project is in crisis mode, increase the meeting frequency. * Analyze performance to determine whether the plan still holds * Knowing the critical path will help you decide which issues warrant a schedule change. * Report progress to your stakeholders * Creating a project dashboard is a great way to summarize your objectives and show stakeholders whether the project, as currently planned and managed, will achieve them. * Manage changes to the plan * Meeting your objectives trumps everything else. Don’t get hung up on compliance with the original plan. * If you propose major changes to your stakeholders, spell out the costs and risks of adopting them and those of sticking with the original plan. * When making large-scale revisions, record them (along with the rationale) on some type of change log in the project records. * Change management * If employees agree on goals but disagree on how to achieve them, use leadership tools: vision, charisma, salesmanship, and role modeling. * If employees disagree on both goals and how to get there, use power tools: threats, hiring and promotion, control systems, and coercion. * If employees agree on both goals and how to get there, use culture tools to counter complacence. In particular, use “disaggregation”, separating the organization into entities that each have their own agreed-upon goals and plans for achieving them. * If employees disagree on goals but agree on how work should be done, use management tools: measurement systems, standard operating procedures, and training. * Escalation of commitment * Don’t make choices merely to justify past decisions. Gather external evidence to support your choices and consult as many outside sources and devil’s advocates as you can. * Focus on the quality of the decision, not the quality of the outcome. * When you find yourself in a hole, the best thing you can do is stop digging. ### Phase 4: Closeout * Handing off authority and control * Success means achieving the goals in your charter and scope statement, not necessarily finishing all the tasks on the project plan. * The “punchlist”: The team meets with the stakeholders and reviews the results of project activities. During that review, everyone helps identify remaining tasks, which you put on a “punchlist” of final action items. * The “stakeholder handshake”: Meet with your key stakeholders to compare the project’s accomplishments with the charter or scope statement, and ask them to agree on whether the project is indeed finished. * The “scope creep parking lot”: During project execution, stakeholders may have proposed additional ideas. Ideally, you’ve captured those items in a list so they’re not lost but they also haven’t derailed the plan. Now that you’re closing the project, it’s time to review this list so you can create follow-on proposals for your stakeholders. * Celebrate your team’s achievements. * Capturing lessons learned (postmortem) * An effective lessons-learned process encourages continuous improvement * It’s important to capture learning while the experience is still fresh. * Evaluate the business case * Has the project delivered on its promised result? * Were the original assumptions and project justifications accurate? * Evaluate the project plan * Was the project plan reasonable and appropriate for the project goal and business conditions? * Were the cost and schedule estimates accurate? * Which risks were not anticipated, which ones were improperly rated, and which response approaches were inadequate? * Did the practices established for team and stakeholder communications work out well? * Evaluate the project-management methodology * Were the organization’s project-management procedures and systems beneficial? * Evaluate individuals’ performance * What feedback do I need to give team members on their performance (good or bad), and what should I tell their supervisors? * Apply the insights right away by updating checklists, tweaking review processes, and making any other necessary adjustments before the next project launches.