Project Life Cycle and Organizational Influences

A project life cycle is the sequence of phases a project goes through from start to finish. It gives everyone a common roadmap, so you know what to do next and when to celebrate. There is no single ‘right’ life cycle; different projects need different approaches. Typically, a life cycle includes four generic phases: starting the project (initiation), organising and preparing (planning), carrying out the work (execution), and closing the project (closure). Each phase produces a key deliverable, like a project charter or a final report.

Why do we need a project life cycle? Without one, a project would be chaotic – like baking a cake without a recipe. You would miss steps, waste resources, and probably end up with a mess. The life cycle ensures that critical activities (like getting approval before spending money) happen in the right order. It also gives stakeholders checkpoints to review progress and decide whether to continue.

Now let’s talk about project phases. A phase is a major chunk of work that produces one or more deliverables. For example, the ‘design phase’ produces blueprints, and the ‘build phase’ produces the actual product. Phases are often sequential, meaning you finish one before starting the next. However, some life cycles use overlapping phases – for instance, you might start testing a feature before it is completely built. The key is that each phase ends with a review to check if the project is on track.

But a project does not exist in a vacuum. It happens inside an organisation, and that organisation’s structure heavily influences how the project is managed. The three main types are functional, matrix, and projectised.

In a functional organisation, the company is divided into departments, like ‘Marketing’ and ‘Engineering’. Each employee has a clear boss (the department manager). Projects are usually done within a single department. The project manager has very little authority; they are more of a coordinator. Team members still report to their functional manager, who controls their pay and promotions. This structure works well for routine work, but it can slow down cross-department projects because you need to get approvals from multiple bosses.

In a projectised organisation, the entire company is organised around projects. Each project has its own team, and the project manager has full authority over the team members, budget, and decisions. This is common in construction and software development firms that take on one contract at a time. The downside? When the project ends, team members might be reassigned or let go. There is less job stability, but the project manager has real power to get things done.

In a matrix organisation, you get a hybrid. There are still functional departments, but people are assigned to projects too. They report to two bosses: their functional manager (who handles career matters) and the project manager (who handles project work). Matrix organisations come in three flavours: weak, balanced, and strong. A weak matrix gives the project manager little authority (like a functional organisation), a balanced matrix shares authority, and a strong matrix gives the project manager a lot of authority (almost like a projectised organisation).

Why does this matter for CAPM? Because the organisational structure determines the project manager’s power, the availability of resources, and how conflict gets resolved. The exam loves to test your ability to identify which structure is being described and how it affects a project manager’s role.

Finally, let’s talk about organisational process assets (OPAs) and enterprise environmental factors (EEFs). OPAs are the internal tools and knowledge you inherit from past projects – like templates, lessons learned, and policies. EEFs are the external conditions you cannot control – like industry standards, market conditions, or government regulations. Both influence how you run your project. For your exam, remember that OPAs are things you can use, while EEFs are things you must adapt to.

Imagine you are a newly hired project manager at a medium-sized software company called ‘AppForge’. Your first assignment is to deliver a new mobile banking app. The company has a strong matrix structure, meaning functional managers (like the head of Development and the head of Testing) still exist, but you have significant authority over the project team.

Step one: you attend a kick-off meeting with the functional managers to negotiate for team members. Because it is a strong matrix, you have the power to request specific people. You secure a senior developer and a junior tester. Your project now has a life cycle of its own. You choose a predictive (waterfall) life cycle because the banking regulations are strict, and the requirements are fixed from the start.

Step two: you plan the phases. You break the project into four phases: requirements, design, build, and test. Each phase has a gate review. For example, after the design phase, you present the architecture to the Chief Technology Officer (CTO) for approval. If the design is not approved, the project does not move forward. This is the organisational influence of having a strong CTO who enforces quality standards.

Step three: during the build phase, the developer runs into a problem that requires a decision from the legal department (an external factor – an EEF). You contact the legal team, but because the company has a functional structure for legal, you need to go through the Head of Legal. This slows things down. You learn that in a matrix, you still have to navigate functional silos for support functions like legal and HR.

Step four: you hold weekly status meetings. The functional managers attend to ensure their people are not overworked. You resolve a conflict when the tester’s manager wants her to work on two projects at once. Because it is a strong matrix, you have the final say on project priorities.

Step five: at project closure, you archive all documents in the company’s shared drive (an OPA). You also write a lessons-learned report that will help future project managers. The organisational influence here is clear: without the strong matrix structure, you would not have had the authority to manage the project effectively.