A few months ago, I was in a sprint review in Vietnam, coffee in hand, trying to follow three conversations at once.
A junior Business Analyst asked me: “Can you explain the full project lifecycle in a way that actually helps me on Monday morning?”
Great question. Hard question.
I have worked as Product Owner, Business Analyst and later as Product Manager since 2017. I have shipped projects in Vietnamese startups, hybrid teams, and now in Germany for my Master Degree in BIS (Business Information System) and Software Engineering at Heilbronn University. But I realized something uncomfortable: I had never written a practical version of the lifecycle. Most guides say what each phase is, but not where teams fail, what each phase costs, and what to do when reality does not match your slide deck. The five core process groups are a strong baseline, but teams still need practical translation for day-to-day decisions [R1].
So this post is my honest version. Simple language. Real costs. Real failure points.
And yes, one reminder before we start: Ordnung muss sein (there must be order). If you skip project structure, chaos will find you anyway.
Quick Summary (Read This First)
If you only remember one thing, remember this: the six phases are not bureaucracy. They are risk control built on standard process-group logic (initiating, planning, executing, monitoring/controlling, and closing) [R1].
| Phase | Key Question | Main Deliverable | Typical Failure |
|---|---|---|---|
| 1. Initiation | Should we do this at all? | Project charter | Building because competitor built it or the CEO says so |
| 2. Planning | How exactly will we do it? | Plan + requirements + scope | Vague requirements |
| 3. Execution | Are we building the right thing? | Working product increments | Communication breakdown |
| 4. Monitoring & Controlling | Are we still on track? | Metrics + change logs | Problems detected too late |
| 5. Closing | Did we finish properly? | Handover + lessons learned | Team moves on too fast |
| 6. Support & Maintenance | Can this survive in production? | Ops runbook + backlog | No budget after launch |
A Fast Timeline Example (12-Week Project)
| Week | What Actually Happens |
|---|---|
| 1 | Initiation: problem framing, feasibility check, sponsor alignment |
| 2-3 | Planning: requirements workshops, scope line, risk plan |
| 4-9 | Execution: build in sprints, QA, demo loops [R2] |
| 4-11 | Monitoring in parallel: velocity, bug trend, budget burn [R4] |
| 10-11 | Closing prep: handover docs, training, acceptance |
| 12+ | Maintenance starts immediately: incident handling, patches, improvements [R3][R5] |
PlantUML Diagram
Why Projects Really Fail (Before We Enter the Phases)
People often say projects fail because of code quality. Sometimes true. But in my experience, the bigger cause is decision quality.
- Wrong problem selected – Important !
- Unclear scope
- Delayed escalation
- Missing ownership
- No maintenance plan
Kein Plan, kein Projekt (no plan, no project). It sounds dramatic, but most budget leaks begin with unclear planning, not with syntax errors.
Failure-Cost Ledger (From Real Patterns I Have Seen)
These numbers are personal experience estimates from delivery projects I worked on, not a universal benchmark.
| Failure Event | Immediate Impact | Cost Impact | Time Impact | Root Cause |
|---|---|---|---|---|
| Built wrong checkout flow | Rework of core user journey | ~32,000 USD | +8 weeks | Requirements too vague |
| Added unplanned features in sprint | Team context switching | ~11,000 USD | +3 weeks | No change control gate |
| Key developer left mid-release | Knowledge gap and blocked QA | ~7,500 USD | +2 weeks | No backup ownership |
| Closed project without retro | Same mistakes repeated next project | Hidden cost (high) | Ongoing | Skipped closing phase |
| No post-launch monitoring | Incidents detected by users | Trust loss + support overload | Ongoing | Missing maintenance setup |
1) Initiation: “Should We Build This?”
Initiation is where teams save months or lose months, and it maps directly to formal project-start discipline in PMI guidance [R1].
If this phase is weak, every later phase gets expensive.
What good initiation includes
- Problem statement in one sentence
- Target user group
- Business outcome and measurable success criteria
- Feasibility check: technical, financial, operational
- Stakeholder map with decision authority
A practical test I use: if your team cannot explain the project goal in 30 seconds, you are not ready.
Common traps
- “Competitor launched this feature” panic mode
- Jumping to solution before validating the problem, very common.
- Ignoring hidden decision-makers (finance, legal, operations), often skipped by many teams.
Must-have outputs before phase exit
- Project Charter (1-3 pages)
- Initial risk register (top 5-10 risks)
- Stakeholder register
2) Planning: “How Will We Deliver Without Burning the Team?”
Planning is where project confidence is built, especially when scope and baselines are explicit [R1].
This is the phase where people say, “Can we move faster by skipping documentation?” My answer is simple: you can move faster for one sprint, then slower for three months.
Langsam und sauber ist schneller (slow and clean becomes faster).
What strong planning looks like
- Requirements engineered with clear acceptance criteria
- Scope line that says what is in and what is out
- Work breakdown structure with owners
- Delivery schedule with milestones
- Risk response plan with triggers
Vague vs engineered requirements
| Quality Level | Requirement Example |
|---|---|
| Vague | “Users should get fast notifications.” |
| Engineered | “When order status changes, system sends push notification within 30 seconds; if push fails 3 times, fallback to SMS.” |
PlantUML Diagram
Must-have outputs before phase exit
- Project plan
- Requirements baseline
- Scope baseline
- Risk management plan
3) Execution: “Build It, Test It, Communicate Constantly”
Execution is the visible part of the iceberg.
Everyone sees code commits and demos. Fewer people see the coordination load behind them.
What separates healthy execution from chaotic execution?
- Clear daily ownership
- Fast blocker escalation
- Mandatory code review
- Real QA (automated + manual)
- Stable sprint rituals
Sprint rhythm that works
- Sprint planning
- Daily standups (15 minutes, max)
- Mid-sprint risk check
- Demo and retrospective [R2]
If your standup is always status theater, you are losing signal. Ask this question every day: “What is blocked, and who can unblock it today?”
The human side (often underestimated)
Projects fail when knowledge is trapped in one person.
Fix it early:
- Pair programming on critical modules
- Shared runbooks
- Cross-review across skill levels
PlantUML Diagram
4) Monitoring and Controlling: “Reality Check, Every Week”
This is not a final phase. This runs in parallel.
Monitoring means measurement.
Controlling means decisions based on measurement. For software delivery teams, this is strongest when you combine flow metrics (DORA-style) with service reliability goals (SLO/SLI thinking) [R4][R5].
Metrics that are actually useful
| Metric | Signal | Red Flag |
|---|---|---|
| Sprint velocity | Throughput stability | >20% drop for 2 sprints |
| Bug trend | Quality direction | Rising 3 weeks in a row |
| Scope change count | Requirement stability | >3 major requests per sprint |
| Burn rate | Budget health | >15% above plan |
| Team morale | Delivery sustainability | Silence in standups + low retro input |
Change control in one sentence
Every scope change must include impact on time, cost, and risk, which aligns with formal change-control intent in project management practice [R1].
If someone says “just one small feature,” respond with numbers and good backup data, not opinion.
So passt das (this is how it works): no impact assessment, no scope approval.
5) Closing: “Finish Properly, or Repeat Mistakes”
The most skipped phase in startups is closing. In Scrum-like delivery, this usually appears as weak sprint review and retro follow-through [R2].
Teams launch and run to the next project. Documentation is incomplete. Lessons are undocumented. Six months later, new team members ask: “Why is this system built like this?” Nobody remembers.
Closing checklist that protects future teams
- Formal handover completed
- User training done
- Acceptance sign-off captured
- Lessons learned documented
- Ownership transferred for operations and support
Retro questions that produce real learning
- What worked better than expected?
- What broke and why?
- What should be changed in the next project from day one?
If the team is too polite in open discussion, use anonymous input first, then discuss patterns as a group.
PlantUML Diagram
6) Support and Maintenance: “The Longest Phase”
Maintenance is not optional. It is where product trust is earned. Historical software engineering literature has long shown maintenance as a major share of lifecycle effort and cost [R7].
Many teams budget only for build and launch. Then incidents start, and nobody owns the backlog.
Typical monthly maintenance budget (startup scale)
| Activity | Why it matters |
|---|---|
| Hosting and monitoring | Service availability |
| Bug fixing capacity | User trust and retention |
| Security patching | Risk reduction [R3][R6] |
| Performance tuning | Experience quality |
| Small enhancements | Product competitiveness |
Minimum operating setup after launch
- Error tracking (for example: Sentry)
- Uptime alerts
- Incident severity model [R5]
- On-call ownership
- Weekly maintenance triage [R3]
Skeptical View: “Is This Too Much Process for a Startup?”
Fair question. I hear this often.
My answer: you do not need heavy process, but you do need phase discipline.
Small teams can keep this lightweight:
- Initiation: one clear charter page
- Planning: one living requirements document
- Execution: one board + one definition of done
- Monitoring: five metrics reviewed weekly
- Closing: one retrospective and one handover pack
- Maintenance: one owner and one routine
You are not adding ceremony. You are reducing expensive surprises.
FAQ
1) Do teams follow all six phases in strict order?
Usually no. Agile teams loop through planning, execution, and monitoring repeatedly. The six phases still exist; the cycle is just shorter [R2].
2) What phase is most ignored?
Closing. Teams ship and move on. The price is repeated mistakes and poor onboarding for new team members.
3) How do I convince leadership to invest in planning?
Show rework cost from your own projects. One strong internal case study is more persuasive than ten generic arguments.
4) Is this model valid for AI products too?
Yes, but feasibility and data-readiness checks become even more important because uncertainty is higher. The control mindset is similar: define measurable outcomes and reliability targets early [R5].
5) What is the one metric I should never ignore?
Team signal quality. If people stop speaking clearly in standups and retrospectives, project risk is rising. Believe with me on this!
References
[R1] Project Management Institute. (n.d.). Process groups: A practice guide. https://www.pmi.org/standards/process-groups
[R2] Schwaber, K., & Sutherland, J. (2020). The Scrum Guide: The definitive guide to Scrum: The rules of the game. Scrum Guides. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
[R3] Souppaya, M., & Scarfone, K. (2022). Guide to enterprise patch management planning: Preventive maintenance for technology (NIST SP 800-40 Rev. 4). National Institute of Standards and Technology. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf
[R4] DevOps Research and Assessment. (n.d.). DORA’s software delivery performance metrics. https://dora.dev/guides/dora-metrics-four-keys/
[R5] Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (Eds.). (n.d.). Service level objectives. In Site Reliability Engineering. Google. https://sre.google/sre-book/service-level-objectives/
[R6] OWASP Foundation. (2021). OWASP Top 10: A06 vulnerable and outdated components. https://owasp.org/Top10/
[R7] Watson, A. H., McCabe, T. J., Wallace, D. R., & Bryan, D. M. (1996). A software project management focus for software engineering standards (NIST SP 500-235). National Institute of Standards and Technology. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication500-235.pdf
Big Picture Diagram
PlantUML Diagram
TL;DR
- Six phases still matter: Initiation, Planning, Execution, Monitoring and Controlling, Closing, Support and Maintenance.
- Planning and Closing are the most skipped and most expensive to skip.
- Monitoring is parallel, not a final checklist.
- Maintenance needs budget from day one.
- Strong communication quality prevents more failures than perfect tools.
Final Note
I am still learning this in every project.
Small sample size, real bias, still evolving.
But if this article helps one team avoid one expensive rework cycle, it did its job.
If you are currently building Apps and Products, here is the practical line I would keep:
Gruendlich planen, pragmatisch liefern (plan thoroughly, deliver pragmatically).
Mong duoc nghe gop y cua ban (I would love to hear your feedback). Share your own project stories.
Stay curious. Stay honest.
Le Cuong – Product Manager and Business Analyst since 2017. I focus on turning messy delivery into repeatable systems with practical documentation, measurable trade-offs, and continuous improvement.
Related reading
Read the relevant post here:
Pingback: 3 triple constrains trong quản lý dự án là gì? - PMLeCuong
Pingback: How I owned the project management tool transition at Anduin Transaction. - PMLeCuong