Project Integration Management
Most people who partake in a Project Management Professional (PMP)® exam preparation course will agree that integration is really where project management starts to make sense. Without integration, the other knowledge areas come across as totally separate sets of work, with little or no relevance to each other.
Because many Project Managers arrive at their position from a hands-on technical role, project management often seems to involve managing the aspects of a project that are of concern to that particular organization. For instance, anyone working in the medical device or pharmaceutical sectors will appreciate the need for quality control and regulation. Work in an accountant’s office and budgeting will be the top priority. But rarely do we stand back from the work and consider the project as a whole. This really is what distinguishes the Project Management Professional from a project administrator.
Project Integration Management begins with the first project management process – the development of the Project Charter. This is where the project gets approval and the go-ahead to investigate further at least. We might need another review of the project after the planning work is done.
Until recently, the Project Management Institute regarded the Project Charter as the Project Manager’s first encounter with the project. This is because the Project Charter is where the Project Manager is officially assigned. However, it is more common these days for the Project Manager to become involved in a project prior to its approval. S/he may be brought in to help with initial feasibility studies or risk assessments. This work requires the Project Manager to appreciate the organization’s strategy – where it wants to go and the way it wants to get there. Similarly, the Project Manager has to understand the business goals of the proposed project. Will the project contribute to the organization’s overall goals? If it does not then why are we doing it?
Another concept today’s Project Managers need to grasp is the idea of “benefits”. Traditionally, Project Managers were concerned with the project’s deliverables and getting them accepted by the customer. Now an awareness of the benefits to stakeholders would be an asset. My project might be to create a component, but what are the concerns of the systems integrators who are going to use my component? Are they concerned with its footprint, or its weight? Is reliability a critical factor? If my component is going to be a field-replaceable unit then ease of access will be important. Look at what use will be made of the deliverables and try to design them to confer useful benefits to the end users.
Once the project is approved, or chartered, the planning work begins. The remaining nine knowledge areas each have to be considered. What is interesting about looking at planning from a project-wide perspective is that the interactions between the different plans become clear. Just about anything can add to the budget. If we have to hire in contract workers instead of using in-house staff, the contract rates might increase the staff costs. Mitigating actions to reduce the probability or impact of a risk may cost money. Similarly, conforming to an international quality standard requires investment.
The more stakeholders that relate to the project, the more complex our communication plan will have to be. In fact, including all the stakeholder meetings, will add to the schedule. Developing the Work Breakdown Structure can reveal tasks that we had not been aware of just from reading the customer’s requirements alone.
This is why the Develop Project Management Plan integration process is so important. Having done detailed planning across all the knowledge areas, is the project still viable? All these extra tasks that we had not been aware of when we created the charter; all the risks and the stakeholder expectations can result in a budget that is too expensive or a schedule that goes months beyond the target delivery date. The review of the Project Management Plan is the opportunity for the organization to call a halt to the project.
If everyone is agreed that we go ahead, we enter into the Direct and Manage Project Work process. Here the Project Manager assigns work to the staff. A wise Project Manager will have acquired and developed the team, using the planning work to motivate them about the project. So they know what is involved and appreciate how this project will contribute to corporate goals.
Direct and Manage Project Work is where, having planned the work, it is time to work the plan. The goal of this process is to produce the agreed deliverables. We also need to record actual progress so that we can analyse how we are getting on. Change requests can also be raised during this work.
During execution of the Project Management Plan, the team's knowledge is growing steadily. They are learning from their mistakes and becoming expert in the activities associated with the project. They are learning useful lessons that could benefit other teams across the organization. The efforts made to capture these hard-won lessons and disseminate them organization-wide are part of the Manage Project Knowledge integration process.
While the planned work is being done, the Project Manager is also concerned with the Monitor and Control Project Work process. Here the details of actual progress are compared with the plan and any variances considered carefully. We might need to take corrective or preventative actions depending on the nature of the variance, or the trend that is emerging.
However, we cannot make changes at random. If the Project Manager feels that a change is needed then that change needs to be reviewed by the Change Control Board, just like change requests originating from stakeholders. This is part of another integration process – Perform Integrated Change Control. If a change is approved then the project plans have to be updated. This is a process called re-baselining.
Until all the deliverables are created and accepted by the customer, the project team continues to carry out the activities defined in the schedule and the Project Manager continues to assess actual progress in relation to the Project Management Plan. Eventually (hopefully), all the work will be done and the project comes to an end.
The Close Project or Phase process is all about bringing a project to a formal conclusion. In some industries – software development comes to mind – there is a tendency for projects to drag on as bugs are fixed during the early days in the field. It is good practice to define clearly when the project is complete and when remaining work is carried out by the sustaining organization. It might be appropriate to assign some of the team members to the sustaining organization until the product is stable, but there must be a definite point when the progress is deemed finished.
At this point, the Project Manager needs to close all accounts relating to the project and deliver a final report. The project documents need to be archived so that they can be reused in future projects. Traditionally, this is when a “post-mortem” takes place and the lessons from the project are recorded - again to benefit future projects. However, the latest thinking, especially on very long projects, is that lessons should be applied to the project as soon as they are discovered. If something is seen to work better, then it should be institutionalized across the project – there is no point not learning the lesson until the next assignment. This is why we have a Mange Project Knowledge process in the executing process group.