The general model follows the logic of Initiating, Planning, Executing, Controlling and Closing activities that results in deliverables to be transitioned to users and knowledge in the form of records transitioned to organizations involved. Not only work in the frame of projects is initiated, planned, executed, controlled, and closed. These management functions are universal, and every manager performs them in their daily work.
In the frame of project management, the very first question to be answered is if a project should be initiated and why. Typical reasons for initiating a project are the existence of a business opportunity, or of a problem to be solved, or a regulation to comply with.
If the solution needed is time constrained, this is a good reason to organize the upcoming work as a project or as a group of related projects, called a programme, if the scope intended exceeds the possibilities of a single project, for instance because the demonstration of benefits is needed but these benefits emerge after the project delivers the solution to end users. The good reason to organize the upcoming work as a project or as a programme is that project management has developed a set of tools and techniques precisely aiming at delivering solutions in time and in budget.
At this pre-project stage, project inception methods are used such as a business case or a feasibility study which may be part of a more comprehensive process governed by corporate management called portfolio management, to select which initiatives will be done. If the result of the inception processes is a “yes”, then a project is initiated. Not planned yet. Initiated.
At this stage, the project manager may have been informally nominated. A formal nomination is one of the outputs of the initiation process. But a good practice is to involve the future project manager during the initiation process, even if this stage runs under the responsibility of the project initiator or sponsor. It is only at the conclusion of the initiation activities that the new temporary organization called Project X will be officially created, including the name and level of authority of the nominated project manager.
A good start for the project initiation activities is the determination of who are the key stakeholders. Working with them the project manager determines which part of the problem or of the opportunity the project will address as well as the purpose and the goal of the project.
The sponsor is the leading person for this. The two crucial questions to be answered are “what do we want to achieve and why”. The why is the purpose and the what is the goal.
While formulating the purpose and goal statements it is extremely helpful to agree on the business requirements for the project. Business requirements are the new capabilities the organization wants to obtain because of the project. They should not be confused with functional requirements and quality attributes for the solution, which come later, during planning.
Before functional requirements for a solution can be formulated, the team must first identify, analyse, and select the most appropriate strategy to attain the goal. There is always more than one solution to attain a goal and the key deliverable to be created by the project, the solution, depends on which strategy is selected.
The definition of project success criteria, high level risks, initial assumptions and existing constraints should be identified as well and all these elements of defining a project should be appropriately documented in a document that is usually called project charter or project brief, that officially creates a new temporary organization called “project X”, which did not exist before and therefore must be approved by corporate and informed to stakeholders.
Any work involves planning before doing, even if the planning happens only in the brain and nothing is written. This is not different when the work is organized as a project.
The project management team starts gathering from key stakeholders their requirements for the management of the project, and review again the constraints, and assumptions gathered during project initiation to see if there is any change.
Now is the moment to define SMART objectives leading to the project goal established in the charter.
The project management team needs to define the type of development lifecycle the team will use to create the solution: which are the phases and or iterations to be pursued.
Special care is to be given to the development of the project baseline, which includes the approved project scope, budget, and schedule. This is what the project will deliver, when and for how much.
The elicited requirements for the management of the project allow to determine how things will be managed.
In the planning stage the team will identify risks, analyze them to determine which are the most critical and develop answers to them.
When all these elements are well combined and balanced, approval from the governing body should be obtained. In most cases this is the project sponsor and the project customer if both roles are not the same person.
Finally, the project manager informs stakeholders about the approved PM Plan and a second kick-off meeting can be conducted to inform everybody of the final plan and migrate from the planning toward the execution phase.
Now it is time to create the key deliverable starting with the acquisition of human and physical resources, leading or participating to the associated acquisitions processes.
A large portion of managing execution consists of the authorization, delegation, review, and acceptance of work packages. At the same time the project manager leads, manages, and develops teams including coaching techniques, manages communications and other ways to engage stakeholders.
Assuring quality during project execution is more than only auditing the application of standards and policies and is concerned with quality generation during all project phases.
Implementing approved changes and corrective measures resulting from controlling activities is also part of managing execution, as well as implementing responses to identified risks.
Finally, while project work is executed the project manager takes care that the team uses existing knowledge and creates an appropriate environment for the creation of new knowledge, including process improvements through lessons learned in team retrospectives.
The purpose of controlling a project is to understand its current state, have visibility into its future status with cost and schedule forecasts and to initiate corrective and preventive actions.
The controlling processes cover all areas of the project management plan, including naturally the project baseline but also risks, effectiveness of communications, stakeholders’ engagement, material resources and procurements.
Part of the controlling work refers to addressing issues and the need of changes that arise during project execution, using problem solving and other techniques to evaluate and decide the most appropriate way of resolution and initiating the corresponding corrective measures and changes that go back to planning and execution processes.
As most projects are structured into phases, those phase boundaries must be controlled as well, evaluating ending phases, providing the project board with appropriate information to decide whether to proceed to the next phase, including the planning of the next phase. Controlling phase gates also includes assuring that phase closing activities have been performed such as the transition of phase deliverables, the release of no longer needed resources and certain administrative phase closing activities such as updating logs and registers, collating lessons learned, and others.
This overlaps already with closing activities, which take place at each phase end and not only at project end.
Closing activities include assuring that the evaluation, acceptance, and transition of accomplished deliverables has taken place, and also evaluating performance of team members including suppliers.
Closure activities are performed at the end of each phase. However, at the end of the last phase, when it is also project end, many of the phase closure activities are combined with the project closure and include the administrative closure activities mentioned before plus project end activities such as the determination of project success using the project success criteria defined in the project charter and the elaboration of a project closeout report.
A final word about the applicability of the norms ISO 21500 and 21502. The guidance for project management they provide is applicable to any organization, type of project or delivery approach.
If the scope to be created by the project can be determined with a reasonable degree of certainty at the beginning of the project, then the delivery approach can be more predictive. If the scope to be created is unknown, unpredictable or the customer does not know what they want or need and so the project embraces a discovery journey during execution, then a gradual formulation of requirements is more appropriate. Delivery approaches for a gradual formulation of requirements are incremental, delivering functionalities in increments, or iterative, gradually improving already built functionalities. Or both, incremental and iterative which is the Agile approach, which includes several useful practices that have been formulated in detail by various Agile methodologies including certain ceremonies.
In many cases, the ways organizations work, require a budget and a timeframe for a solution to be established upfront to approve an initiative and reserve a specific budget, even when parts of the solution have a notable unknown factor and may be developed using Agile approaches. Or trying to predict unpredictable things upfront, working with assumptions, carrying with it the implication of having to manage many change requests, because – whether we like it or not, changes are inevitable in projects for the very fact that they are unique. In the frequent hybrid cases, sections of the project are more predictable than others and some components of the global solution can have a predominant Agile character. Suppliers of those Agile components see their part in the project as “the project”. And it is in fact “their project”, as a supplier of one component of a larger project. From the point of view of the final customer, that Agile project is in fact a work package, a component to a global solution that may not be managed entirely and not even predominantly as an Agile project.
Whatever the delivery approach and the management philosophy is, any work needs to be initiated, planned, executed, controlled, and closed as explained in the ISO Norm for project management.