The Project Lifecycle

The bridge to nowhere

In 2005, the US Congress approved $398 million for a bridge in Alaska connecting a town of 8,000 people to an island with 50 residents. The project became the poster child for government waste — not because the engineering was bad, but because nobody asked the fundamental question in Phase 1: "Should we even build this?"

That is what the project lifecycle prevents. It forces you to ask the right questions at the right time — before you pour concrete (or write code) on something nobody needs.

Every successful project — from building a skyscraper to launching an app — follows the same five phases. Skip one, and you get a bridge to nowhere.

Phase 1: Initiation — "Should we even do this?"

This is the most important phase that gets the least attention. You are answering ONE question: Is this project worth doing?

The business case is your project's birth certificate. If it cannot justify its own existence in a one-page document, it should not exist.

There Are No Dumb Questions

What if the CEO just says "build it" without a business case?

Many projects start this way — and many of them fail. Your job as PM is to gently push for clarity: "Great idea — let me draft a quick charter so we are all aligned on scope and success criteria." You are not blocking the CEO. You are preventing the project from derailing in month 3 because nobody agreed on what "done" looked like.

Phase 2: Planning — "How will we do this?"

Planning is where most of your PM effort goes. A well-planned project does not guarantee success — but a poorly planned one guarantees failure.

The Work Breakdown Structure (WBS)

The WBS takes a big, scary project and breaks it into small, manageable pieces. It is like slicing a pizza — the whole pie is overwhelming, but one slice at a time is doable.

Example — Mobile app project WBS:

• Level 1: Mobile Order Tracking App
  • Level 2: Design
    • Level 3: User research, wireframes, UI mockups, design review
  • Level 2: Development
    • Level 3: Backend API, frontend app, push notifications, testing
  • Level 2: Launch
    • Level 3: App store submission, marketing, user onboarding

Each Level 3 item becomes a work package — small enough that one person or team can own it, estimate it, and deliver it.

The critical path

The critical path is the longest sequence of dependent tasks. It determines the MINIMUM time the project can take. If any task on the critical path is late, the whole project is late.

Tasks NOT on the critical path have float — they can slip a few days without affecting the deadline. Understanding the critical path tells you where to focus your attention.

Risk planning

Every project has risks. The PM's job is not to eliminate risk (impossible) but to identify, assess, and plan for the most likely and most impactful ones.

Phase 3: Execution — "Let's do it"

Execution is where the plan meets reality. As a PM, your job during execution is NOT doing the work — it is enabling the team to do their best work.

PM responsibilities during execution:

• Assign tasks and ensure everyone knows their role
• Remove blockers ("The API team has not responded — let me escalate")
• Facilitate communication (standups, status updates, stakeholder meetings)
• Manage scope changes through the change control process
• Track progress against the plan

Phase 4: Monitoring & Control — "Are we on track?"

You planned for 12 weeks. It has been 6 weeks. Are you halfway done — or 30 percent done with 50 percent of the budget spent? Monitoring answers this.

Key metrics to track:

Earned Value Management (EVM) — the professional way to answer "how are we doing?":

• Planned Value (PV): How much work should be done by now
• Earned Value (EV): How much work IS done by now
• Actual Cost (AC): How much have we spent

If EV < PV, you are behind schedule. If AC > EV, you are over budget. Simple.

There Are No Dumb Questions

What do I do when the project is off track?

You have four levers: add resources (rarely works — "9 women cannot have a baby in 1 month"), reduce scope (often the best option), extend the timeline (if the sponsor agrees), or improve efficiency (remove bottlenecks, automate, simplify). Choose one. Do not pretend everything is fine.

Phase 5: Closing — "What did we learn?"

The most neglected phase. Everyone wants to celebrate (or forget) and move on. But closing is where organizational learning happens.

Closing activities:

• Formal handoff to operations or the client
• Final documentation and lessons learned report
• Post-project retrospective with the team
• Release resources (people, budget, tools)
• Celebrate successes and acknowledge the team
• Archive project documents for future reference

Back to the bridge to nowhere

The $398 million Alaska bridge — connecting 8,000 people to an island of 50 — became a national symbol of waste because nobody asked "should we even build this?" during Phase 1. A proper initiation phase would have required a business case justifying the investment, a feasibility study evaluating alternatives, and a stakeholder register identifying who actually needed the bridge. The engineering was never the problem. The missing question was.

Key takeaways

• Every project follows 5 phases: Initiation, Planning, Execution, Monitoring, Closing
• Initiation is the most important — if you cannot justify the project, do not start it
• The WBS breaks scary projects into manageable pieces
• The critical path determines the minimum project duration — focus attention there
• Monitoring uses metrics (schedule variance, cost variance, EVM) to answer "are we on track?"
• Closing and lessons learned are where organizations learn — do not skip them
• 70 percent of project failures trace back to poor planning or skipped initiation