crcarlson.com

Project Management

9-Oct-2025

“Those that do not study the mistakes of the future are doomed to repeat them for the first time.”

Ken M

Figure 1. Project Management was essential for creating Intuitive’s da Vinci 5

Project management is a disciplined framework of problem-solving methods for achieving goals with the best use of resources. Engineers apply it to create new products, researchers to investigate new questions, executives to drive corporate strategy, and individuals to reach personal goals. I have applied project management to building medical devices such as the da Vinci 5, developing web-based software, and hosting multi-course holiday dinners.

While many factors influence performance, one pattern stands out: high performers manage projects well and low performers do not. For small projects, project management techniques are helpful and often applied informally. As projects grow more complex or communication less effective, formal methods become essential.

Project management has been an enabling capability throughout my career, and 30 years since my first introduction, is still central to my daily work. I consider myself fortunate to have learned the fundamentals from two great mentors: Prof. Andy Frank and Rob Younge. In this essay, I outline the process I use to manage projects, highlight common errors, and suggest practical mitigations.

Creating a Project

Figure 2. Creating a project is a creative and iterative process. Each step informs the others and the plan converges.

The first idea to keep in mind is that every project begins with a creative, iterative process to reach the best plan, and the same process applies when things go off course. Keeping an open mind and seeking better ways to achieve goals, project after project, builds capability and makes one formidable over time.

In the following sections I will describe each step as well as common errors made by those new to the subject.

  1. Identify Leader, Stakeholders, and Goals
  2. Core Team and Required Resources
  3. Work Breakdown Structure and Plan Proposal
  4. Optimize Plan
  5. Execute and Adapt
  6. Close Project and Lessons Learned

Identify the Leader, Stakeholders, and Refine the Goals

Figure 3. Identify the leader, stakeholders, and refine the goals.

Identify the Project Sponsor: The project sponsor champions the need for the project and allocates the resources required to achieve its goals.

Identify the Leader: Every project begins by naming a leader, someone both responsible and accountable for delivering the goals. In a small company, this may be the founder or head of engineering. In a larger company, it may be a director or subsystem leader.

Identify Stakeholders: Next, identify the stakeholders, anyone with a vested interest in the outcome or influence over project success. In a small company, the leader or CEO may be the only stakeholder. In a larger organization, subject-matter experts, resource managers, or the product release manager may all be stakeholders. As Tony Fadell noted of the iPod project, alignment with senior leadership, Jobs in that case, was crucial. Executive alignment is essential for any large initiative.

Refine the Goals: With a leader and stakeholders in place, the next step is to refine the goals. Early goals are often vague, overconstrained, or misdirected. An essential discipline for any project is to ensure the goals are worth achieving. The leader should capture intent, define outcomes in measurable, functional terms, and avoid unnecessary constraints on how to achieve them. Framing goals this way broadens problem-solving scope and creates opportunities for more valuable solutions than initially imagined.

Well-defined goals also translate the project vision into intermediate objectives that guide the team’s efforts and serve as leading indicators of success. Tracking intermediate goals provides valuable feedback to act upon during execution and demonstrates concrete progress toward the project’s expected outcomes.

Common Errors

Lack of Stakeholder Alignment: If stakeholders view the project’s proposed outcomes as failing, no level of team performance can produce success. This usually arises due to failing to identify relevant stakeholders, ignoring stakeholder input, or silent stakeholder disagreement. Mitigations include thorough stakeholder search, holding a desired-outcomes review with all stakeholders present, strengthening requirements-gathering skills, and building a culture of co-creation and commitment to agreed goals.

Inadequate Leadership: Projects without a clear, accountable leader with available bandwidth often stall or fail. Either appoint a qualified leader with the needed availability or delay the start until one is identified.

Appointing a leader who lacks commitment or the required skills also leads to poor performance. Mitigations include assigning a mentor, strengthening the team with experienced members, or selecting a new leader.

It is essential for the project sponsor to check in frequently at the start to confirm the right leader and core team are in place while changes are still inexpensive.

Poor Goal Framing: Draft goals may not be specific, measurable or relevant and may only partially reflect the expectations of the stakeholders. [As Elon Musk has emphasized, the worst mistake is to have engineers solving the wrong problem.] Work with the stakeholders to clarify the intent of the goals using a checklist such as SMART1

Narrow Goal Framing: Draft goals may include a proposed solution as a way of communicating the desired outcome2, but the best solution may not be knowable without investing in the project. The best course is to translate the intent of the stakeholders in terms of desired outcomes rather than write down literal stakeholder requests.

Cut and Paste Goals: Draft goals may be copied from analogous projects, or otherwise created in a way that while easy to draft as a goal, may add unnecessary cost, complexity or time to completing the project. e.g. it is common to get generic goals based upon what has worked in the past or “best practice” rather than goals thought through in the context of this project. The mitigation is to map the specific project’s goals from first principles to the intent of the stakeholders and remove all unnecessary requirements.

Superficial Goals: Another common error is writing goals that are easy to accomplish or easy to measure rather than goals that matter most. This can disguise a lack of real progress behind positive but shallow indicators3. The mitigation is to hold a stakeholder review of the proposed project goals with the prompt : “Are these the most relevant goals to our intent? Do these goals reflect high performance? Are our incentives aligned?” Often the SMART or similar framework is again helpful.

Designate Core Team and Required Resources

Figure 4. Designate core team and required resources.

Designate the core team: the core team is the group of individuals whose combined skills cover the competencies needed to achieve the project goals, either directly or by proxy through other resources. These members usually devote a large share of their time to the project and interface with others as required.

Figure 5. Potential connections between people on a project grows as N^2.

For small colocated teams, the core team may be the same as the full team because communication costs are low. But, as the networks in Figure 5 show, unorganized communication cost grows with the square of the team size4. Once the team grows beyond five or six people, it is often worth it to adopt a core-team strategy that reduces coordination complexity.

Figure 6. A Core Team structured so that each person has a maximum of 5 connections to manage and most fewer.

One way to manage larger team complexity is to organize across domain, functional, physical, or other subsystems. Figure 6 shows an example of how three core team leaders coordinate the work of 3 people each as well as coordinate with the two other core team leads. The result is that four people have one connection to manage, two people have two, three people have three, three people have five and the project has sixteen connections total versus the potential maximum of sixty six.

Creating the core-team structure that maximizes efficiency while leveraging organizational expertise is itself a creative and rewarding exercise.

Identify the Required Resources: Once the core team is identified they work together and with their subteams to form an initial forecast of the required and available resources.

Common Errors

Inadequate Resourcing: In complex projects, teams without sufficient expertise may misinterpret requirements, mis-scope the work, or miss opportunities for optimization. To mitigate this risk, the project leader should draw on stakeholders and their networks to surface overlooked competencies. Stakeholders, in turn, should review the team’s capabilities and close gaps or adjust the project scope.

Over-Resourcing: Over-resourcing can stem from many causes: inattentive management, inexperience in estimating needs, preference for comfort over performance, excessive risk aversion, or status tied to team size. To manage this, project leaders and core team leads should review proposed resources and evaluate their fitness for purpose. Consistently poor allocators should be mentored to improve or removed from the role.

Inefficient Team Structure: For larger teams, poorly defined interfaces and expectations create two risks: teams spend excessive time in low-bandwidth communication, or the organization misses out on critical information. Both lead to lower performance such as higher costs and longer timelines.

Unclear Roles and Responsibilities: Teams without clearly defined roles and responsibilities risk poor performance through lack of accountability, low urgency, and poor prioritization and resulting tradeoffs.

A common example is teams self-organizing into democracies and over-including solutions from each team member long after clear implementation choices should have been made.

The best mitigation is to assign roles and responsibilities early and for the leader to define distinct project phases for idea generation and solution selection. One comprehensive framework for this is the RACI Matrix5.

Create the Work Breakdown Structure and Plan Proposal

Figure 7. Create the work breakdown structure and plan proposal.

Think of planning as iterative: early drafts carry low resolution and certainty, later iterations greater detail and confidence.

Work Breakdown Structure (WBS): A WBS decomposes the project into progressively smaller elements until reaching discrete work packages. Each package must be clear enough to assign, track, and measure. This ensures all necessary work is captured and tied to the project’s objectives.

Creating a WBS is especially difficult for novel projects. Subject-matter experts must break down problems from first principles, propose solutions, and explain not only what they recommend but why. These “whys” are essential for optimizing the plan in the next step. Expect this work to demand serious time and creativity.

This process benefits from thoughtful core team design. Breaking the problem into smaller, manageable parts and assigning each to a focused core team accelerates progress and reduces errors by narrowing scope and lowering complexity.

Figure 8. Example Gantt Chart with dependencies.

Map Dependencies: Mapping dependencies defines how tasks and deliverables rely on one another, making relationships explicit. This identifies critical paths, parallel work, and bottlenecks to be optimized.

Risk Register: A risk register catalogs potential risks, noting their likelihood, impact, and mitigation strategies. While systematic risk reduction and forecasting often implicit deliverables, it is worthwhile making them explicit by creating work packages and tracking visible progress.

Figure 9. Example Risk Register with likelihood and impact ranking.

Plan Proposal: The plan proposal consolidates the goals, timeline, resources, and risks into a coherent roadmap. At first it acts as a starting point for the project plan optimization, and once optimized, It functions as both an alignment tool for stakeholder approval and a guide for the team’s execution.

Common Errors

Getting Started Difficulty: As with any creative, iterative process, teams often struggle to begin or focus on the wrong level of detail for the maturity of the plan. Mitigations include holding a brainstorming session with the core team, starting high-level before refining details, working backward from the end goal, and running a short-term “plan for the plan” to resolve uncertainties.

Lack of Buy-In: When team members or stakeholders doubt the value of planning and underinvest, project performance suffers. Mitigations include building alignment on planning’s value, reviewing case studies that link planning to higher performance, and replacing chronic low performers.

Cut and Paste Errors: Borrowing past WBS or plans without tailoring includes irrelevant tasks and overlooks gaps. Mitigations include leveraging older plans only as references for understanding first principles and mentoring support for cut and pasters.

Lazy Models: Inaccurate estimates of cost, time, or effort set projects up to miss expectations. While uncertainty is inherent in forecasting, forecasting skill improves with deliberate practice. Mitigations include seeking expert input, mentoring junior team members, and replacing chronic poor forecasters.

Poor Requirements Ownership: Requirements assigned to departments, included for historical reasons, or burdened with excessive safety factors should be examined closely6. Most optimization processes depend on tradeoffs, and without an accountable owner for each requirement, those tradeoffs cannot be negotiated effectively. The mitigation is to assign a qualified individual to represent each requirement.

Poor Risk Management: Skipping structured risk identification leaves the project vulnerable to surprises that increase costs and delay value creation. Mitigations include conducting risk management workshops, creating a risk register, and ensuring that the important risks have effective mitigation strategies in place.

Lack of Named Resources: Assigning work to teams or departments instead of individuals obscures responsibility and accountability. Similarly, assigning work to individuals that are over committed is also not practical. Mitigations include assigning each work package to a specific person and confirming availability.

Contingency Build Up: A common low-level risk management strategy is to add contingency to individual work packages. This can waste opportunity when tasks finish early and dependent work is not ready to proceed. A better practice is to hold moderate contingency at the program level and allocate it only when other mitigations have been exhausted.

Catastrophizing: Overemphasizing worst-case scenarios paralyzes decision-making, extends schedules and consumes excess resources. Mitigations include alignment on expectations around risk tolerance, and evaluating top risks with probability and impact scoring in collaboration with subject matter experts

Optimize the Plan

Figure 10. Optimize the plan.

An optimized project plan achieves the goals with the most effective use of resources. Prioritization should follow a clear order: enterprise mission first, departments second, and individuals third. Creating such a plan is a creative exercise, the team must evaluate many possibilities before choosing the best course of action.

Optimization begins by auditing the quality of the plan proposal. If the proposal lacks sufficient quality, the optimization process will yield the wrong result.

Review the Work Packages: Subject-matter experts should examine each level of the WBS. Do the estimates reflect first-principles thinking and the judgment of high performers? Are outcomes achieved with the best use of resources? If not, refine.

Review the Dependencies: Are critical dependencies captured? Can dependencies be decoupled with interface design or other design decisions? Are paths and bottlenecks explicit, and are the principles governing them well understood? If not, refine.

Review the Risks: Are the risks identified, and are the mitigations meaningful? Is there a clear priority order for risks with forecasted retirement dates to track? If not, refine. With these checks in place, full plan optimization can begin.

Shorten the Critical Path: Using the dependency map and first-principles analysis of each task, seek opportunities to shorten the critical path to the desired outcomes. Techniques include removing non essential activities, accelerating bottlenecks, increasing iteration speed, starting critical activities at risk, running parallel solutions, and consulting with experienced high performers for proven examples.

With this level of insight into the mechanics of speed to value, the program leader may propose alternative goals or resourcing to stakeholders, with explicit tradeoffs.

While optimizing the critical path maximizes value creation over time from known facts and assumptions, in parallel, risk management maximizes the probability the project will perform to plan.

Accelerate Risk Reduction: With risks prioritized and their effect on the critical path understood, seek opportunities to de-risk the program earlier for the smallest investment. Common techniques include building appropriately lower fidelity prototypes faster and cheaper, resourcing for rapid iteration, and using already proven solutions where innovation is not essential.

Iterate: Each proposal may modify the goals, critical path, dependencies, or risk register. Continue iterating until the plan is optimized.

Common Errors

Optimizing the Wrong Things: Teams will often optimize around artificial constraints instead of the enterprise value drivers. For example the team may overemphasize staying on budget when in reality the budget is negotiable, team member preferences when the mission of the enterprise is higher priority, or predictability over higher performance. Mitigations include education on managing stakeholders and tradeoffs, alignment on mission priority and expectations for risk tolerance.

Unoptimized Bottlenecks: Time spent optimizing bottlenecks is almost always a good return on investment. Yet teams often underinvest when they lack control or subject matter expertise, such as when relying on an external vendor, are uncertain about de-risking strategy, or rely on expert estimates not grounded in first principles. Additional techniques to shorten critical paths include vertical integration, learning from proven analogs, negotiating or sourcing alternative vendors, or increasing spend to reduce time.

Unidentified Near-Critical Paths: Standard analysis highlights a single critical path, diverting attention from near-critical paths that may become active during execution. This can be costly: surprise upside on the main path may leave the enterprise unprepared to capture acceleration, while downside on a near-critical path may delay the program. The mitigation is straightforward but requires discipline: invest effort in optimizing near-critical paths alongside the primary one.

Delayed Risk Reduction: Scheduling mitigation or testing tasks late in the timeline delays information vital to optimization. Surprise upsides and downsides alike can create avoidable sunk costs. An extreme example would be waiting until commercialization for the first customer feedback on a product, when changes are far more expensive than at the prototype stage. The mitigation is to pull risk-reduction activities forward as much as feasible.

Figure 11. Two different approaches to retiring risk. Planning to retire risks later in the program consumes more resources or takes longer and often both.

Execute the Plan and Adapt to New Information

Figure 12. Execute the plan and adapt to new information.

Execute Project: Project execution is carrying out the project plan through coordinated tasks and resource allocation. The focus is on delivering outputs while staying aligned with schedule, cost, and quality targets.

Track: Project tracking creates a factual record of work completed. It gives teams and leaders the data needed to measure performance and compare results against the plan. On a regular basis update the progress against tasks, critical path, and risk register.

Figure 13. Example project status indicator for Week 2 compared to Week 1, areas under stress should be problem solved with the core team.

Communicate: Communication should render tracking information into easily digestible forms that provide the necessary insight to control the project. Common renderings include Gantt charts with critical paths identified, risk register charts, burn down charts, and major milestone status dashboards to support regular status reports.

Adapt to New Information: Adapting to new information means revising tasks, priorities, or scope when information, new risks, or opportunities emerge. The project team is expected to maximize the project value to the enterprise in the context of changes in the environment. For each change, the critical path and risk register should be reevaluated and the plan re-optimized as warranted.

Common Errors

Abdication: Project leaders may mistakenly disengage and assume the plan will unfold as assumed. But, project execution is a dynamic process that requires active leadership to achieve the best outcomes. Project leaders should use tracking tools, stay up to date with progress, and take part in creative problem-solving to respond to both upside and downside surprises.

Inaccurate or Partial Reporting: A common and dangerous error, especially when compensation is tied to performance, is overemphasizing successes and hiding failures. This bias delays bad news, prevents adaptation with new insights, and destroys value. Mitigations include setting clear expectations for transparency, independently verifying results, and removing chronic offenders.

Lack of Accountability: When task ownership is uncertain or regular progress is not monitored, deviation from the schedule may go by unnoticed. Every deliverable should have a named owner responsible for progress and regular reporting so the team can adapt effectively when required.

Poor Communication: Adaptation and productivity depend on clear and accurate communication. Common failures include delayed or misrepresented status, weak visualization, or failing to communicate at all. Mitigations include pointed status updates, strong visualizations, and channels that deliver the right information to the right people at the right time.

Low-Bandwidth Meetings: When information is not shared efficiently, teams often default to large meetings where most of the time is wasted. The mitigation is to reduce overhead by creating deliberate communication channels such as small core team meetings, clear communication expectations for leaders, and shared tools such as Confluence or Smartsheet.

Failing to Act: Teams sometimes continue executing against outdated assumptions when new information is available. This can happen when the project leader is over-delegating or too disengaged. To perform at a high level, teams must evaluate new information quickly and adapt as necessary. While this may require extra investment in plan review and optimization, the investment is often worthwhile.

Emotional Decision-Making: Overly emotional reactions to new information can be an expensive distraction. Team leaders must evaluate incoming information objectively and choose the course of action that optimizes outcomes with available resources. Performative or illogical responses add cost at best and divert focus from execution.

Changing Plan without New Information: Conversely, some leaders change goals, priorities, or methods arbitrarily, destabilizing execution. This may occur within the team or at the stakeholder level. Changing goals without cause triggers re-planning, creates sunk costs, and damages morale. Mitigations include deliberate stakeholder alignment during goal setting and rendering the costs of arbitrary changes, typically longer timelines, higher expenses, and lower team engagement.

Close the Project and Lessons Learned

Figure 14. Close the project and lessons learned.

Close the Project: Project closure is the end of execution. It ensures that the goals are measured, the deliverables are handed off, and the resources are made available for future projects. For significant projects that perform well, a celebration is a great way to recognize and encourage a high performing culture.

Reflect on Lessons Learned: An after project review analyzes the successes, failures, and surprises of the project. Documenting and sharing these lessons ensures future projects benefit from the experience and strengthens organizational performance. Consider holding a lessons learned debrief sessions for members inside and outside of the core team and updating internal training, procedures, templates, etc. where applicable.

Common Errors

Grading Errors: Some teams declare success while missing the spirit of the objectives; others declare failure when the spirit is met but the letter is not. Both errors are harmful. Easy graders weaken the link to negative feedback that corrects errors in planning and execution, while hard graders push teams toward conservative, rigid approaches. Mitigations include documenting goals carefully, creating a change process that enables adaptation, using tiered measures that capture both execution and results, and reviewing goals with the judgment of skilled practitioners who weigh both execution and outcome.

Failing to Learn: Many teams skip reflecting on mistakes and lessons learned, wasting a valuable opportunity. Every practice has an experience curve, and ignoring lessons is missing the opportunity to move up the curve. Mitigations include incentivizing a learning culture, holding structured debriefs to analyze root causes, focusing on problems rather than people, and documenting actionable improvements.

Failing to Teach: Lessons often remain within the core team and are lost to the broader organization. One cause is reluctance to expose mistakes for fear of harming relationships, another is the extra effort required beyond project closure. Mitigations include reinforcing a learning culture, creating and sharing case studies, publishing findings in knowledge bases, and consulting subject-matter experts on future projects.

Acknowledgements

Special thanks to Federico Barbagli, Raghavendhar Gautham, Vinay Malur, and Matt Roelle for reviewing drafts of this essay.


  1. SMART is an acronym for Specific, Measurable, Achievable, Relevant and Timebound. 

  2. Stakeholders, like customers, can’t always articulate what they want. Clayton Christensen writes about this in his book Competing Against Luck - C.M. Christensen, K. Dillon, et al. (2016) "Customers don’t want to buy a quarter-inch drill. They want a quarter-inch hole." 

  3. This is especially common when the team incentive plan is misaligned and, consciously or unconsciously, the project team is seeking to maximize value to themselves vs. value to the enterprise. 

  4. This is an example of Metcalfe’s law applied to human networks. 

  5. While a good mental model, my experience is that teams that rely heavily on RACI structures would benefit from trust building activities. 

  6. Elon Musk said this best – "Question every requirement. Each should come with the name of the person who made it. You should never accept that a requirement came from a department, such as from “the legal department” or “the safety department.” You need to know the name of the real person who made that requirement. Then you should question it, no matter how smart that person is. Requirements from smart people are the most dangerous, because people are less likely to question them. Always do so, even if the requirement came from me. Then make the requirements less dumb."Elon Musk - Walter Isaacson (2023)