What is the executing process group?
The executing process group turns a theoretical plan into something tangible. The entire reason for a project is that it should produce some deliverables, either physical products or something that is recognizable, such as a change in working practices.
The executing process group contains more than the production of the project deliverables; however hard or simple a task that might be to complete, it is also concerned with the realization of the project plan and how it evolves to meet the realities of the project tasks and operating environment. As such the execution process group should not be considered in isolation, but as a process that is intimately entwined with the monitoring and controlling process group. Between them these two process groups work the project plan, changing and documenting those changes as the project plan evolves.
The processes within the execution process group produce the project deliverables and perform quality assurance to ensure that the deliverables achieve the required standard. The execution process identifies change requests, often as a result of experience gained from executing part of the project plan, and then implements these changes. Changes to the plan that arise in this fashion are called corrective actions. Change requests occur to prevent a risk developing into an issue: shutting the stable door prior to the horse bolting are preventive actions.
An important part of the execution process group is the selection and development of the project team to complete the project work packages. In most cases, the risks associated when working with an experienced and motivated project team are much lower than those when attempting to execute the same work with an inexperienced project team.
Table 3.3 summarizes the results of the executing process.
What is the output of executing?
The main output of the executing process group is of course the project deliverables: this is the output of the entire project! As well as the deliverables the other main output of the execution process is change requests and the implementation of change requests. Along with the monitoring and controlling process group, execution is an iterative process; a successful project manager continuously checks that deliverables are of the appropriate quality and manages the associated risks.
Why is executing important in project management?
As well as the importance of a project actually executing the production of a product or implementing a change, the execution process group is important as it is this process that makes the project management plan work. Earlier earned value management protocols for project managers implicitly used the execution process as a test of the rigour of the project management plan and, ergo, a test of the competence of the project manager. This is unhelpful as it ignores the reality that changes to projects mostly occur owing to events beyond the project manager's control, such as stakeholder decisions or changes in the wider business, social or physical environment.
General Eisenhower famously stated that 'no plan ever survives contact with the enemy, but you still have got to have one'. A conjugate to that quote was made by a much earlier military commentator who said 'in strategy there are no victors'. Taking these two mantras together, it can be said that the best project management plan is worthless, unless it can be adapted to the realities of the project environment. It is the execution process that implements the changes to a project plan and identifies many of the change requests, as risks to the project become better defined.
Who should be involved in executing?
As with the planning process group, who should be involved depends entirely on the kind of project. As a minimum, this will usually be the project manager and the project team. Larger projects may require interactions with members of the organization outside the project team who are members of the organization or sub-contracting parts of the project to external sellers.
It is the interactions between the project team and members of the same interaction that are often the most complicated. Most organizations have rigorous procedures in place for procurement or contracting services; it is their processes for obtaining goods or services internally that tend not to be well planned. From the point of view of the project manager, any deliverables or work packages that are executed internally to the organization, but outside the project team that they control, should be planned and managed with the same care as those contracted in from outside the organization. The risk associated with work executed externally to the project team is typically higher than for similar work carried out internally. The main reasons for this increased risk are the extra communications required between the project manager and those external to the project and the lack of control the project manager has over them to deliver work packages within the project timescales. Sellers and contractors external to the project organization are normally controlled and legally bound by contract to complete work to the required standard and on time; while those internal to the organization but outside the project manager's control often lack suitable incentives.
Top of Page