Whether a project follows a waterfall life cycle or an agile life cycle, it will usually involve several fundamental types of activity:
- Planning what needs to be done
- Designing how it will be delivered
- Executing the actual work
- Verifying and validating whether the results meet the requirements
Different frameworks may use different terminology or divide these activities into more detailed components, but the underlying logic does not fundamentally change.
The most important difference between waterfall and agile is not that one includes planning, design, and validation while the other does not. The real difference lies in the scale at which these activities occur, the time horizon over which they are performed, and how long the project must wait for feedback.
Waterfall: Large-Scale, Concentrated Activities
In a waterfall project, planning, design, execution, and validation are usually organized as relatively large phases.
A project may begin with a concentrated period of requirements analysis and overall planning, followed by detailed design. Once the design is largely complete, large-scale development or implementation begins. Testing, acceptance, and final validation are then conducted after most of the construction or delivery work has been completed.
The defining characteristic of this approach is that similar types of work are highly concentrated.
Planning is concentrated in the planning phase. Design is concentrated in the design phase. Execution is concentrated in the implementation phase. Verification and validation are concentrated toward the end of the delivery process.
Each phase may continue for a relatively long period and produce a comparatively complete set of outputs before handing them over to the next phase.
This does not mean waterfall projects have no risk management, inspection, or adjustment. The challenge is that their feedback cycles are usually longer. When an early assumption, requirement, or design decision is incorrect, the problem may not be fully exposed until late in implementation or even during final acceptance.
Agile: The Same Activities Distributed Across Smaller Iterations
Agile does not eliminate planning, design, execution, or validation.
Instead, it reduces their scale and distributes them across a series of iterations or sprints.
Within every sprint, the team still needs to plan what it intends to complete. It still needs to design how the selected functionality or solution will be implemented. It still needs to perform development, configuration, or delivery work. Finally, it must review, test, and validate the resulting increment.
The same categories of work still exist, and similar activities may still be concentrated within a limited period. The difference is that the amount of work handled each time is much smaller.
As a result, the team does not need to wait until the entire project is complete before discovering whether its direction is correct. Each completed increment creates an opportunity for feedback, allowing the team to adjust its subsequent plans according to actual results.
Agile therefore does more than shorten the work cycle. More importantly, it shortens the distance between making a decision and validating that decision.
Different Life Cycles, but the Same Fundamental Management Logic
Planning, design, execution, and validation are fundamental to project delivery. For this reason, neither PMI nor other project management and agile frameworks can simply remove these activities.
A framework may reorganize them, change their scale and frequency, alter their sequence, or allow some of them to occur concurrently. But it cannot pretend that a project no longer requires planning, design, execution, or verification.
Without planning, a team will struggle to establish a shared direction.
Without design, execution can lose structure.
Without execution, every method remains only a concept.
Without verification and validation, the team cannot demonstrate that the results genuinely meet the requirements.
This is the foundation of how I understand project process management:
Methods may change, but the basic realities on which delivery depends do not disappear simply because the name of the framework changes.
I Do Not Make Projects Serve a Framework
I am not committed to only one project management framework. I do not reject a method simply because it is described as “traditional,” nor do I assume that another method must be superior simply because it is described as “agile.”
Waterfall, Scrum, Kanban, Nexus, and different hybrid delivery models are all tools for solving project problems.
The real questions are:
- How stable or uncertain are the requirements?
- How many external dependencies does the project have?
- Is the team capable of frequent collaboration and feedback?
- Can the deliverables be divided and validated incrementally?
- How much flexibility is permitted by the site conditions, contracts, and acceptance mechanisms?
- Which approach can deliver value with lower cost, lower risk, and greater reliability?
When requirements are stable, the technical approach is mature, and phase boundaries are clear, stronger upfront planning may be more effective.
When requirements are uncertain, feedback is frequent, and deliverables can be validated progressively, short iterative cycles are usually more appropriate.
When the same project contains both stable engineering work and highly uncertain software work, a hybrid approach is often more reasonable than forcing every workstream into a single life cycle.
My Core Principle: Respect Reality and Use What Actually Works
If I had to describe my core management philosophy, I would not name a particular framework.
It would be this:
Respect reality, learn from proven experience, and select the approach that is most appropriate for the current environment.
I refer to established frameworks and respect successful practices, but I do not treat any method as an untouchable doctrine.
When an approach fits the project, reduces waste, controls risk, improves collaboration, or produces more reliable results with greater efficiency, I will consider using it.
When evidence shows that a better option exists, I will adjust the original approach.
For me, frameworks should serve the project. Projects and teams should not be forced to carry unnecessary costs merely to preserve the formal completeness of a framework.
Project management ultimately has to deal with real requirements, real constraints, real teams, and real delivery outcomes.
Methods can be combined and adapted, but making decisions according to facts and results is the management principle I will not change.