Project life-cycle, does such a thing exist? Can we really imagine that projects in different environments, using different technologies and working on different outputs, can share a common life-cycle? It is quite simple to imagine that every company has got its own project life-cycle or even more than one depending on the project's typology, the degree of innovation, etc. For example, car manufacturers know they have to design different components like the gearbox or the cockpit. They must take care of performances like the aerodynamics and manage different phases like the integration, the crash test, and the commercialization. It is easy to understand that companies producing different products, like helicopters, or delivering services like a bank, will have their own life-cycles which encompass all the previous knowledge they developed in the field. What is more interesting, though, is to understand that there is a common project life-cycle for each project, not depending on the different outputs, companies, or industries. If we look at projects by far enough, they all go through the same list of different macro-activities: initiating, planning, executing, controlling, and closing. We can briefly analyze these activities by looking at the output we should expect from them. The output of the planning activity is the project master plan. It is essential to underline that such a plan goes far beyond a simple Gantt chart. Planning a project doesn't mean defining its schedule and milestones. This is certainly important, but not enough. A proper plan should encompass different perspectives and views of the project. The minimum set of plans must cover the Scope Management Plan, the Time Management Plan, and the Cost Management Plan. Besides that, other aspects to be planned can be: risk, procurement, quality, communication, Human resource management and Stakeholder management. As a consequence, the plan is a multidimensional tool that will be further analyzed in future classes. After planning, we can start the executing activities. The final output of these activities will be the output verified by the team and ready for customer validation. Only the customer, indeed, can validate the output. This means that the executing phase can encompass every needed test to verify the output before submitting it for validation. In parallel to the executing macro-activity, there is the controlling one. The final aim of controlling is often misunderstood. One could think that the final objective of Controlling is to assess if the project is ahead or behind schedule and over or under cost. This assessment is essential indeed, but it is not the final aim of the controlling. We do control projects to support our decisions, but hardly it is wise to make decisions looking at the project's current state. Consider a two-year project, for example, where the delay penalties start to be effective after four weeks of delay. Suppose we control the project after the first month and verify a delay of one week. In that case, we could ask ourselves if this delay is critical and quickly answer negatively as the penalties start only after four weeks of delay. The right question to ask, though, should be a different one. Penalties will be paid looking at the final delay and not at the intermediate ones. We should ask ourselves what will be the final delay and look for a way to estimate it starting from the actual that data we have. What we really know is that we delayed one week in the first month. If we go on at this rate, we might delay 24 weeks at the end of the project, and this would be a disaster. Thus, we must consider that the controlling activities' final aim is not to simply assess the time or cost variance at an intermediate point of the project but to use these data to estimate the final project cost and time to support the next decisions. Speed up, reduce the scope, terminate the project, re-negotiate with the client might be possible options in our case. The last macro-activity of the life-cycle is the closing. Many different activities compose this macro-phase. First, the customer must validate and accept the project output and, if it is needed, reworks and fine-tunings must be performed. Also, during this phase, all the contracts with external providers and agreements with internal resources must be closed. Probably the most critical activity of the closing, though, is also the most neglected one. This is the time in which we can critically assess and review the project. We can learn from our mistakes and capitalize on the experience we collected. In other words, this is the right time for collecting the lessons learned and making them available for future projects. This step is often neglected, though, first because the closing of a project is often overlapped with the critical early phases of a new one, and second because re-analyze possible mistakes and write them into documents is sometimes difficult and outside our comfort zones. I'm sure that many of you noticed I skipped the first macro-activity of the life-cycle: initiating. I wanted to discuss it as last because of its nature. If all the other macro activities are under the project manager's direct responsibility, this first one is not. The project manager is an operational role responsible for satisfying the customer and delivering the right scope respecting the boundaries of time and cost. This will imply making many decisions but one: the decision to activate the project. Projects don't just happen; they start after a phase in which someone performs a careful analysis to decide whether or not to start them. This decision is purely strategic. Companies and organizations do not have infinite resources. Doing a project in many cases implies not doing other possible alternative ones. Even if we do not currently have an alternative, choosing to commit our resources to an initiative will block us from the possibility of accepting other ones in a future period of time. Thus, the decision to commit to a project is relevant, almost not reversible and impacts for a long time. In other words, this is a strategic decision that cannot be made by the project manager but requires the involvement of different levels of the organization. The initiating macro activity is complex to be tracked and requires the collaboration of different actors at different hierarchical levels. Unfortunately, this implies that the initiating macro-activity is still poorly managed in many companies, becoming one of the main reasons for poor-performing projects.
