Seven management methods that improve execution

Human history contains difficult projects ranging from the pyramids to the Moon landing. Their results depended on coordinated work by many people and on a system that connected goals, resources, decisions and control. Most readers will not manage a mission of that scale, but nearly everyone participates in projects. This guide compares seven widely used approaches: traditional project management, Agile, Scrum, Lean, Kanban, Six Sigma and PRINCE2.

Project management is the direction and concentration of everything required to obtain an agreed result within time and budget constraints. No two projects are identical, and no single management system fits every situation. The approaches below differ in field of application, degree of detail, scale and formality. For readability, standards, concepts, methods and frameworks are grouped under the broad word “methods”, although they are not technically interchangeable.

• Traditional or classical project management;
• Agile;
• Scrum;
• Lean;
• Kanban;
• Six Sigma;
• PRINCE2.

About project management

Neil Armstrong and Buzz Aldrin are remembered for the first crewed Moon landing, but the Apollo programme depended on the coordinated effort of roughly 400,000 people and thousands of organisations and universities. In 1961, President John F. Kennedy set the objective of landing a person on the Moon and returning safely. At that point, the United States had only brief human spaceflight experience. The objective demanded extensive planning, new technology, money, integration and disciplined cooperation.

Accounts of NASA management describe a central challenge: an enormous amount of work had to be completed inside a short decade. The programme was divided into manageable parts, while organisations responsible for each part had to meet dates and integrate their results. George Mueller, who led the Office of Manned Space Flight, established a management structure that emphasised programme control, systems engineering, testing, reliability and quality, and flight operations.

• Programme control maintained sequence, budget, requirements and relationships among programme elements.
• Systems engineering coordinated new components and the interfaces that made them one system.
• Testing established whether the designed parts worked in expected conditions.
• Reliability and quality checked conformity with requirements and standards.
• Flight operations prepared and controlled the integrated system in actual use.

The model was initially questioned, but it gave specialists and organisations a shared structure. Apollo illustrates the purpose of project management: divide a complex objective into controllable parts without losing the integration that makes the final outcome possible. Historical accounts vary in terminology and attribution, so the example should be read as an illustration rather than a universal formula.

How modern project management emerged

NASA did not invent organised projects. Ancient construction, exploration and public works required planning long before modern documentation. What distinguishes modern project management is the explicit modelling of tasks, dates, resources and dependencies.

A useful analogy is cooking. First obtain the ingredients, then prepare, cook and serve them. A recipe provides a sequence. If a head chef coordinates several dishes and several teams, however, a recipe is not enough: the chef must understand how long each stage takes, when shared equipment is available and which dish must be ready first.

At the beginning of the twentieth century, Karol Adamiecki and Henry L. Gantt developed related visual scheduling ideas. A Gantt chart records activities, duration and timing and can show their relationships. A network of dependent tasks reveals the chain that controls overall duration. You cannot serve a dish before it is cooked; equally, a project activity cannot begin before a genuine prerequisite is available.

Not every project requires the same level of control. Publishing a series of blog articles may care more about a reliable flow—outline, draft, review, revise, proofread and publish—than about minute-by-minute resource optimisation. Agile, Lean or Kanban may suit that environment. Projects with strong deadline, cost or defect-reduction constraints may use classical scheduling, Scrum, Six Sigma or a combination.

Known project-management systems and basic terms

Start by identifying what dominates the project: a fixed date, constrained resources, a regulated process, discovery under uncertainty, a continuous service, or several of these at once. Then select a method or combination whose assumptions match the work.

• Agile is an iterative and incremental set of values and principles for adapting to changing requirements through frequent delivery and collaboration in cross-functional, self-organising teams. Scrum and Kanban are among the approaches influenced by Agile.
• Critical path is the sequence of dependent activities that determines the earliest possible completion date. Delay on that path affects project finish unless the plan changes.
• Event-driven process chain is a diagram that represents business or project activities and the events and resources that enable them.
• Float is the amount of time an activity may move without affecting a defined date. Activities on the critical path normally have zero total float.
• Milestone is a significant event marking the completion of a stage or decision point. In a Gantt chart it is commonly represented as a zero-duration item.
• Project manager is the person accountable for coordinating planning, execution and closure with the project team and stakeholders.
• Resources include time, equipment, material, information, people and funding needed to perform the work.
• Scope defines the work and deliverables required to produce the agreed result.
• Sprint is a fixed-length Scrum event, normally one month or less, during which a usable product increment is created.
• Traditional project management commonly uses a staged or predictive life cycle in which major phases follow an approved sequence.

Traditional project management

Dividing a process into stages makes it manageable. A traditional predictive approach places major phases in a deliberate sequence: a later phase relies on outputs approved earlier. The pattern suits work with stable requirements, costly physical dependencies or formal approval gates. A roof cannot be completed before its supporting structure exists.

A common life cycle contains five broad phases:

1. Initiation. The project manager, team, sponsor and relevant stakeholders clarify the need, intended result, constraints and high-level requirements.
2. Planning. The team defines work, sequence, schedule, budget, resources, risks, quality criteria, communications and stakeholders. The plan becomes a controlled basis for execution, not a prediction that can never change.
3. Design or development. In technical projects, specialists define the form of the solution and the means of creating it, such as architecture, materials or technology.
4. Implementation and testing. The main product is created and checked against the agreed requirements. Progress is monitored using relevant measures, and defects discovered during testing are corrected.
5. Monitoring, handover and closure. The team obtains acceptance, transfers the result, records lessons and closes obligations. Software and service projects may continue into support and improvement rather than ending with a single handover.

These phases are a foundation, not a compulsory number. A small project may use three, while a complex programme may have many gates. An iterative form can treat each stage as a smaller project while retaining the overall order. Gantt charts, network plans, spreadsheets and specialist tools such as Microsoft Project or Primavera can support the plan.

Advantages. The objective and boundaries are established early. Planning gives the team an organised path, makes resource needs visible and provides time for verification. For stable engineering, construction, procurement or regulatory work, formal stages reduce ambiguity and make accountability clear.

Disadvantages. The approach can react poorly when requirements change frequently. A large design approved too early may be expensive to revise after implementation has begun. Predictive management should not be confused with refusing all change; it needs an explicit change-control path and appropriate contingency.

Agile

A strictly sequential approach cannot serve every environment. Preparing one dish may follow a simple order; operating a restaurant requires many items to advance in parallel while demand changes. Agile addresses uncertainty through small increments, feedback and adaptation.

Instead of decomposing the whole project only into large sequential stages, the team delivers small valuable parts. Analysis, design, development and testing happen for each part, while initiation and high-level direction apply to the product as a whole. A completed increment can be reviewed or used earlier, and learning from one iteration can change later work without reopening every completed component.

The term Agile became widely associated with the 2001 Manifesto for Agile Software Development. The manifesto emphasised people and interaction, working software, customer collaboration and response to change while recognising value in processes, documentation, contracts and plans. Agile is therefore not one detailed management method. It is a set of values and principles from which frameworks and organisational practices are built. Scrum, Kanban, Crystal, LeSS, SAFe and Nexus represent different ways of applying related ideas.

Advantages. Short feedback cycles improve adaptation. The principle “responding to change over following a plan” is valuable for innovative products, services and other open-ended work where important information appears during development. Incremental delivery can expose a mistaken assumption before the whole budget is spent.

Disadvantages. Because Agile does not prescribe a complete operating model, an organisation must create or select one. That requires experience, persistence, training and changes to funding, roles and governance. Calling ad hoc work “Agile” does not create agility. Teams still need a product goal, technical discipline, prioritisation, quality standards and protection against constant interruption.

Scrum

Scrum is a lightweight framework for generating value through adaptive solutions to complex problems. Early versions emerged in the 1980s and the framework has evolved. It combines empirical control—transparency, inspection and adaptation—with a clearly defined cadence and accountabilities.

Work needed for the product is held in a Product Backlog and ordered by the Product Owner. The Scrum Team selects work that supports a Sprint Goal and creates a usable Increment inside a Sprint lasting one month or less. A stable Sprint length gives the team a regular rhythm and limits the time before feedback. The Product Owner represents product value and stakeholder needs; the Scrum Master helps the team and organisation understand and use Scrum; Developers create the Increment. Current Scrum terminology describes accountabilities rather than a project leader who assigns every task.

Five recurring events structure inspection and adaptation:

• Product Backlog refinement. Although refinement is an ongoing activity rather than a formal Scrum event, the team regularly clarifies, splits, orders and estimates future items so that likely work is sufficiently understood.
• Sprint Planning. The team establishes why the Sprint is valuable, what can be done and how the selected work will be created. The result is a Sprint Goal and Sprint Backlog owned by the Developers.
• Daily Scrum. Developers inspect progress toward the Sprint Goal and adapt their plan in a short daily session. Detailed problem solving can continue afterward with the people involved.
• Sprint Review. The Scrum Team and stakeholders inspect the outcome and changed environment, discuss what was learned and adapt the Product Backlog. It is a working session, not merely a ceremonial demonstration.
• Sprint Retrospective. The team examines effectiveness, relationships, tools and the Definition of Done and selects improvements for the next cycle.

Advantages. Scrum is useful where a team needs frequent usable results and expects requirements to evolve. Regular communication and collective ownership help people share experience. Small increments are easier to inspect, and defects or weak product assumptions can be corrected earlier than in a large infrequent release.

Disadvantages. Scrum demands a cohesive, capable and self-managing team, active product ownership and organisational support. Older descriptions often prescribe five to nine members; the current Scrum Guide says the Scrum Team is typically ten or fewer. Regardless of number, excessive size and narrow silos increase coordination cost. Scrum is not automatically suitable for every physical or highly sequential project, and merely renaming meetings and managers does not implement the framework.

Lean

Agile states values for adapting, while Lean adds a way of thinking about value, flow and waste. Work is divided into manageable pieces, and each piece moves through an operating flow appropriate to the product. Unlike a strict Sprint boundary, Lean can support several items moving continuously, provided work in progress and capacity are controlled.

Lean asks the organisation to specify customer value, understand the value stream, create flow, let demand pull work and pursue continuous improvement. The objective is not simply to make every person appear busy; it is to shorten the path from need to valuable outcome while protecting quality. A local improvement that overloads the next stage is not a system improvement.

Advantages. Lean offers more than abstract flexibility. Value-stream analysis, small batches, built-in quality and systematic removal of delay can make a project faster and more reliable. It combines adaptability with operational discipline.

Disadvantages. Detailed analysis for every item may cost more than it saves, and a generic Lean description does not provide the exact workflow for a particular project. Without strong product direction and communication, teams may optimise one step, cut necessary resilience or treat Lean as a cost-reduction campaign.

Kanban

Kanban makes flow visible and manageable. The method has roots in Toyota’s production system and the replenishment signals observed by Taiichi Ohno. In knowledge work, tasks are represented by cards that move through explicit workflow states. The system visualises demand, constrains work in progress and encourages improvement based on observed flow.

Unlike Scrum, Kanban does not require Sprints or prescribe Scrum accountabilities and events. Existing roles and processes can be the starting point. A team may use a physical or electronic board, but the board alone is not the method. Policies, work-in-progress limits, service expectations, blocked-work handling and feedback loops turn visualisation into a management system.

• Cards. Each work item contains the information needed to understand its objective, ownership, class of service and current state.
• Work-in-progress limits. A state has a defined capacity. Reaching the limit exposes a bottleneck and encourages the team to finish or unblock work before starting more.
• Continuous flow. New items enter according to priority and available capacity rather than an arbitrary desire to keep everyone occupied.
• Continuous improvement. Flow measures and feedback support kaizen: repeated, evidence-based changes to the system.

Advantages. Kanban suits collaborative teams and continuous services. It provides clear information about load, queues and blocked work. Explicit limits reduce multitasking and make bottlenecks visible. Because it starts with the current process, adoption can be gradual.

Disadvantages. It still requires capable people, shared policies and product prioritisation. An unmanaged board can become a passive list of overdue cards. A fixed-date project can use Kanban, but the team also needs forecasting and schedule control; lack of Sprint deadlines does not remove external commitments.

Six Sigma

Six Sigma is a disciplined, measurement-oriented approach to reducing variation and defects. It was developed at Motorola in the 1980s and later adopted widely. It is often combined with Lean, but their emphases differ: Lean focuses on value and flow, while Six Sigma applies structured analysis and statistical thinking to quality and process capability.

The source article presents the five-step DMEDI cycle for design and improvement:

1. Define. State the problem or opportunity, current situation, customer need, boundaries and desired result.
2. Measure. Decide which reliable data are needed, how they will be collected and which indicators represent success.
3. Explore. Analyse alternatives and causes, then design an approach capable of meeting requirements within time and funding constraints.
4. Develop. Build and refine the selected solution through a detailed, controlled sequence and establish evidence of progress.
5. Control. Sustain the improvement, monitor performance and document lessons and standards for the project and organisation.

Other Six Sigma contexts commonly use DMAIC—Define, Measure, Analyse, Improve and Control—for improving an existing process. The choice of cycle depends on whether the team is improving a current process or designing a new one.

Advantages. The approach provides an explicit algorithm, measurable goals, analytical correction and continuous improvement. It supports broad understanding of a complex process, careful use of resources and difficult projects with many quality problems. Decisions are expected to be supported by evidence rather than intuition alone.

Disadvantages. Measurement can become bureaucracy, and poorly chosen indicators can optimise the wrong outcome. An unclear goal creates conflicting priorities. A slogan that everything can always be improved may prevent the team from recognising satisfactory completion. Lessons are valuable only if the organisation actually reuses them. Customer satisfaction, business objective, ethics and long-term product value must remain connected rather than being reduced to one quality figure.

PRINCE2

PRINCE2 originated in United Kingdom government project practice and was introduced under that name in 1989. The acronym stands for Projects IN Controlled Environments. It is a structured project-management method that combines staged control, continued business justification and management by exception. The method has been revised since its original release, so teams should use the guidance corresponding to the version adopted by their organisation.

PRINCE2 does not attempt to supply industry-specific technical knowledge or every specialist technique such as Gantt scheduling, work-breakdown design or software engineering. It focuses on the management system. Traditional descriptions organise that system around seven principles, seven themes and seven processes; newer guidance uses closely related practices. In all versions, the method must be tailored to the project’s scale, risk and context.

Three practical questions establish direction:

• Business: Is the project still worthwhile and achievable?
• Product: What exactly will be created and how will acceptance be judged?
• Resource: Are enough people, time and funds available to reach the objective?

Its process model can be understood through seven management areas:

1. Starting up a project. Confirm that a viable project exists, appoint key roles, capture the outline business case and prepare the decision to initiate.
2. Initiating a project. Build the project-initiation documentation, controls, strategies and stage plan that provide a shared basis for management.
3. Directing a project. The Project Board makes key decisions and remains accountable for overall success without taking over day-to-day management.
4. Controlling a stage. The project manager assigns work, tracks progress, manages issues and risks and reports exceptions when forecast tolerance for time, cost, scope, quality, risk or benefit will be exceeded.
5. Managing product delivery. The project manager and team managers agree work packages, deliver products and report completion and quality.
6. Managing a stage boundary. Results and forecasts are presented to the Project Board so it can assess continued justification and authorise the next stage or corrective direction.
7. Closing a project. Confirm acceptance, evaluate performance, hand over products, record follow-up actions and recommend formal closure.

Advantages. PRINCE2 can be tailored to different organisations; defines roles and responsibilities; focuses on products and acceptance; separates management levels; protects business justification; divides work into manageable stages; and emphasises experience and continual learning.

Disadvantages. It does not replace specialist product-development practices or technical tools. A mechanical implementation can produce excessive documentation and decision delay. Tailoring is not optional: controls must be proportionate, and the method must be integrated with the delivery approach actually used by the team.

Choosing the management system that fits

Project management has no immutable recipe or universal answer. Finding a single method that exactly fits is unusual. Most organisations select a foundation and tailor it, sometimes combining elements from several systems. A predictive plan may govern an overall regulated programme while Scrum guides uncertain product development, Kanban manages support work and Six Sigma addresses a recurring quality problem.

Begin with the project objective and constraints rather than a fashionable label. Ask:

• How stable are requirements and how costly is change?
• Does the work produce one final result or a continuous stream of value?
• Which date, budget, safety or regulatory limits cannot move?
• How frequently can customers and users provide reliable feedback?
• What skills, decision rights and capacity does the team actually have?
• Which quality and outcome measures will reveal success or failure?

A custom system requires effort, but it should not become an arbitrary mixture. Define roles, artefacts, events, policies, measures and escalation paths; then test whether they help delivery. Keep useful controls, remove ceremony that produces no decision or evidence, and record why a practice changes.

Learning from experienced practitioners

Methods become useful through practice. Case studies, professional standards and experienced managers can show how an approach behaves under real pressure, but reputation is not a substitute for evidence. Examine what problem was being solved, what constraints applied and whether the reported result can transfer to your environment.

The original article recommends the author’s book on the practical path for beginning project managers, drawing on work associated with organisations such as Nissan, Alfa-Bank, Burger King, Nestlé and Bayer. Treat such experience as one source among several: compare it with current framework guidance, your organisation’s data and the needs of the people doing the work.

Conclusion

Traditional management, Agile, Scrum, Lean, Kanban, Six Sigma and PRINCE2 are not contestants in a universal ranking. Each encodes assumptions about change, flow, quality, governance and feedback. The right choice is the one whose assumptions match the project and whose implementation produces transparent, testable control.

NASA historian Roger Launius has observed that management was among the hardest problems in sending people to the Moon. The lesson is still relevant: technical ambition becomes a delivered result only when people, decisions, dependencies and evidence are coordinated. Choose consciously, tailor proportionately and improve the system as the project teaches you.