Direct and manage project execution

This is the 'doing' part of project management. Managing and executing project work should be done so as to meet the project's requirements and objectives, as specified in the scope statement and project plan. Like any management task, the challenge is first of all to execute effectively, that is to reach the objectives, and subject to effectiveness, to execute efficiently, that is at lowest cost and risk. The project manager is the linchpin of project execution. As such, they are involved with the organization and integration of all aspects of the project, from resolving minor issues to ensuring that the path is clear of major obstacles that could halt the progress of the project, and to do this the project manager must work closely with the sponsor.

The project team's efforts must always be focused on the project's aims and deliverables. The project manager must ensure that this focus is maintained, and to do so must check regularly on progress against baseline plans, and manage variation beyond tolerance limits. (See the subsection on 'Corrective and preventive actions' later in this chapter.) Even if the project is managed and directed well, preventive and corrective actions are normal, especially from running the quality process.

Work needs to be controlled, especially so that people do not start work too early. If work is started too early then there is a risk that it will have to be reworked, and sometimes people will want to do work that they find easy or interesting instead of other work that the project needs them to do first. A work authorization system manages this problem. It is used to instruct and direct team members or contractors to start work on a specific work package at a prescribed time. The allocation of when and by whom a work package is started is important to the effective management and control of the project's activities. For larger projects a more rigid system would be in place, purely because of the extra number of moving parts to integrate. The work authorization system is usually an established company process, therefore it is not specifically generated for an individual project.

PMI says

Work authorization system

'Work Authorization System (Tool). A subsystem of the overall project management system. It is a collection of formal documented procedures that defines how project work will be authorized (committed) to ensure that the work is done by the identified organization, at the right time, and in the proper sequence. It includes the steps, documents, tracking system, and defined approval levels needed to issue work authorizations.' PMBOK Guide

It cannot be emphasized too much that in managing project execution the project manager must keep in close touch with the project sponsor and communicate with them constantly. It is the sponsor who has the power to protect the project from changes and loss of resources. Keeping in touch means ensuring that the other person understands what you mean.

Requested changes

Requested changes are inputs to the integrated change control process in a project. This may sound obvious, though experience shows it is valuable to remember two points about this. A requested change is just that, a request. It does not mean that the change will be made, or is likely to be made. As project manager you may need to start managing expectation around this as soon as a request for a change to the project is made. Does the person making the request understand that your project does not and cannot automatically accept changes, but that there is a process? This is not bureaucracy, it is good management. (The process can be made bureaucratic, but that is a different matter.) Secondly, these requests go into a system; they are not dealt with on a case-by-case basis. Change requests are normal, and on all but the smallest and simplest projects there will be many of them. It is simply too inefficient not to have a systematic process to deal with them.

A requested change, or, in another style of the English language, a request for a change, should include the following information, and if it does not then your job as project manager is to find out this information:

• Who wants the change?

• Why is the change necessary, or desirable?

• What are the consequences if the change is not made?

• What is the timescale around this change?

• What are the ramifications to the project and to stakeholders if this change is made, and what if it is not made?

During the life of the project, the sponsor or a stakeholder may identify the need to expand or reduce the scope required of the project. The proposed alteration to the project could also impact on the cost or schedule of the project. The set of criteria used to assess the success or failure is contained in the project scope statement, so if a requirement is to be amended in any form, a formal change request must be submitted for consideration. The requested change can be initiated from inside or outside the project, but in either case the Change Control System should be followed for this process. The team will implement only the approved changes, but once again the need to integrate the change is key to the success of the project.

Deliverables

As we know, a project is a temporary endeavour which creates a unique product or service. The deliverables are therefore a set of products or services distinct from what is produced by the normal or everyday activities of the organization. The project management shows what the deliverables are, when they are due, how they will be made, why they are needed and who is responsible for which parts of them. It should also show the processes to be used to review and check the correctness or quality of the product or service. A deliverable can also be used to define a set of customer or sponsor requirements which must be met before approval or acceptance is granted for the project. Once all the planned deliverables have been delivered and accepted by the customer, then the project is deemed successful and project closure procedures can start. If the customer unreasonably refuses to accept deliverables, and the project has documentation to evidence that this is unreasonable, for instance because the deliverables have been produced to agreed requirements, on time and on budget, then the project is still in a very strong position.

PMI says

Deliverable

'Deliverable (Output/Input). Any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase or project. Often used more narrowly in reference to an external deliverable, which is a deliverable that is subject to approval by the sponsor or customer....'PMBOK Guide (p.358)

Note that the difference between a deliverable and a work product is that a deliverable can be, but is not necessarily, a kind of work product. A product, in the PMBOK Guide definition, is 'an artefact that is produced, is quantifiable, and can be either an end item in itself or a component item ...'. The key difference here is that a product is quantifiable, but a deliverable need only be verifiable. So an increase in sales can be a project's deliverable, because it is a verifiable result of the project, but is not a product. On the other hand, an increase in sales by 10% can be a product. Is this distinction useful? It can be, in some cases. Unless your organization already has particular meanings for these terms, we recommend using the term 'deliverable' as the primary general term for things intended to be created by the project.

Top of Page