Other project integration management tools and techniques

In this chapter so far we have explained what project integration management is and its broad principles. The rest of this chapter gives a summary description of the processes, tools and techniques, inputs and outputs, and other concepts within project management integration. Let us pause just here to clarify these terms, starting with the PMBOK definitions see the box and adding to them a few comments.

PMI says

Processes, activities, tools and techniques, inputs and outputs

'Process. A set of interrelated actions and activities performed to achieve a specified set of products, results or services.'

'Activity. A component of work performed during the course of a project.'

'Tool. Something tangible, such as a template or software program, used in performing an activity to produce a product or result.'

'Technique. A defined systematic procedure employed by a [person] to perform an activity to produce a product or result or deliver a service, and that may employ one or more tools.'

'Input. Any item, whether internal or external to the project, that is required by a process before that process proceeds. May be an output from a predecessor process.'

'Output. A product, result, or service generated by a process. May be an input to a successor process.'

All from PMBOK Guide (p.350ff.)

The PMBOK definitions given here are as useful as any others. They help us to get clear in our minds what we should be doing at any given time in project management, in the following ways:

  • Processes answer the question 'What should I be doing now, as a project manager?'

  • Tools and techniques answer the question 'How should I be doing it?' the difference between the two terms being that tools are things in the world, such as checklists, software and written procedures, whereas techniques are habits of mind, or in a sense 'mental tools'. The key ideas box gives an example that may help you to remember the difference between tools and techniques.

  • Outputs answer the question 'Why are we doing it?' in the sense that if the output is not directly or indirectly supporting the aim of the project, then it is not the right output.

  • Similarly, inputs have value only to the extent that they are necessary for outputs.

  • And activities answer the question 'Which bit of the project plan should the team be doing now?'

Being clear about such distinctions helps one to avoid the greatest personal risk in project management, which is to drown in the terminology and procedures instead of focusing on what matters. We need to know most of the concepts and terminology, but we need to ensure that we use as little of them as possible at any one time, just the right concepts for the immediate needs of our project. This is especially the case in project management integration, where we need to make everything in the project fit together, but efficiently. In this book we use the term 'concept' to include processes, tools and techniques, inputs and outputs, and also other concepts within project management.

Key Ideas

Tools versus techniques: what's the difference?

Tools are things that exist in the physical world, although tools need not always be physical things. Techniques are in the mind or the body of a person and are also known as the skills of the person (although a technique is a kind of skill that can be learnt by a number of people, rather than being unique to one person).

Consider the great golfer Tiger Woods as an example. His golf clubs are his tools. How he swings them is his technique. Other people can have the same tools, the same golf clubs as Tiger, but that is not sufficient to make them play as well as he. Tiger has mastered the technique of golf to a very high and rare degree, but despite that, without the tools of golf clubs, his technique alone won't move the ball very far, that is, his technique without the right tools won't achieve the objective.

As a project manager, it may be useful to consider whether at a certain point in your project it is investing in tools or techniques, or a mix of both, that will most help your project. Do your golfers have any clubs at all? If they have some clubs, is it going to be better clubs or improvements in technique that raise their game most, within the timescales that matter to the project? There will be different answers to these questions in different cases. Project management training courses, teambuilding, and one-on-one coaching is a way to improve technique; mandating new conceptual tools (or methodologies) and procuring new software tools are ways to improve the tools available.

The rest of this chapter describes the key concepts in project integration management, but only as far as is necessary for project integration management; they are not complete descriptions of each tool. Complete descriptions are given elsewhere in the book. You as project manager should decide whether or not each concept is useful for the project you are running.

You will not need all the tools for any given project. The concepts are:

  • Processes

    - Develop preliminary project scope statement

    - Direct and manage project execution

    - Monitor and control project work

    - Integrated change control

    - Contract closure

    - Close project

  • Tools

    - Project management information system

    - Configuration management

    - Change control systems (part of configuration management)

    - Configuration management system

  • Technique

    - Earned value technique

  • Inputs and outputs

    - Requested changes

    - Project management plan

    - Deliverable

    - Lessons learnt

  • Other concepts

    - Project selection methods

    - Project planning methodology

    - Statement of work

    - Drum resources

    - Hammock tasks

    - Corrective and preventive actions

    - Change control board

    - Administrative closure

Figure 4.6 gives a graphical representation of this list, showing when during the project lifecycle each concept is typically used, or whether it is a hammock task. (Hammock tasks are described below in more detail; they are tasks that run throughout the whole project lifecycle. We are not using this term in quite the same way that the PMBOK uses it, but rather in accordance with the way in which most project managers who use the term use it.)

Figure 4.6. Project integration management processes, concepts, tools and techniques, outputs and inputs, showing when they are typically used and what kinds of tool they are

Project management information system

The Project Management Information System (PMIS) is a system for managing the information needed to run the project. Note the word system this does not necessarily mean an IT system. Some of the best systems from the project manager's day-to-day point of view are paper based: one can walk around carrying a small notebook or ring binder with key project management documents and checklists; despite the marketing claims of their manufacturers, it is not possible to be as fast and efficient walking around with PDAs or mobile telephones. Note especially that Microsoft Project is not a PMIS. It is a software tool for producing Gantt charts.

The purpose of the PMIS is to assist the project team with the execution of the planned activities listed in the project management plan. Until recently it was the case that few automated software tools were well adapted to the practical tasks of project management at the project manager level, and some sort of manual system was often needed to supplement an automated system; where good and complete systems did exist they were expensive. This is changing, in terms of both falling cost and increasing utility of such systems. Use software tools, but use them as tools do not get dazzled by them as toys.

The main requirements of a PMIS are to assist the project manager in the following ways:

  • To record the aim and scope of the project, so that they stay in scope and can ensure that everyone else in the project does so.

  • To track changes within the project, so that they control change rather than being at the mercy of uncontrolled change.

  • To monitor and control the various activities throughout the project from initiation to closure, so that the project gets done.

  • To summarize project management reports and data (summary reports are also known as a 'management dashboard') so that the project manager can see the big picture and identify trends and events that matter most, and communicate these, with evidence, to the sponsor and other key stakeholders as necessary.

Other functions can include:

  • Tracking cost, schedule and inventory

  • Producing management reports

  • Showing resource levels

  • Identifying the critical path.

Key Idea

Project management information system (PMIS)

A large amount of information is needed to manage a project efficiently and effectively. The project manager who cannot find their information when they need it won't be efficient and may be ineffective as a result. A PMIS does not necessarily mean an IT system often having a well-indexed ring binder of key information is more useful than a sophisticated database.

PMI says

Project management information system (PMIS)

'Project Management Information System (PMIS) (Tool). An information system consisting of the tools and techniques used to gather, integrate and disseminate the outputs of project management processes. It is used to support all aspects of the project from initiating through closing, and can include both manual and automated systems.' PMBOK Guide (pp.368 9)

One example of a PMIS for smaller projects is Basecamp (http://www.37signals.com/) which is a web-based project and process collaboration system that is inexpensive, effective and easy to use. Basecamp is one of the first of a new generation of tools, and more like it can be expected in the next few years. As ever, a Google search will give a number of others PMIS tools.

Change control systems

However good your plan, it will need to change. You have a choice as project manager: either change controls you, or you control change. The latter is better; the former dooms you. In project management you control change with a change control system. This does not need to be, and should not be, a complex system, but you must have a system. Often a simple spreadsheet will provide most of what you need, with some process around it to use the information in the spreadsheet. An example of the columns in a spreadsheet might be:

  • Name of change.

  • Description of change.

  • Reason change is necessary.

  • Date raised.

  • Raised by (name).

  • Approved or rejected or further information required (pick list).

  • Date approved.

  • Approved by (name).

  • Change actions (i.e. a list of what actions are needed to effect the change).

  • Owner of change actions.

  • Next review date or closed date.

If your organization has an IT system for project management then it will include a change control database with fields similar to those above.

The change control system is a component of the configuration management system. Every project must have a plan for how a change would be managed, which is part of the overall project management plan. The change management plan need not be long or complex two or three lines will do in many cases. For example: 'Once the project charter (and subsequently the plan) is signed off, any changes required to the charter (or plan) will be communicated to the project manager, who will log them in the change control spreadsheet. Every fortnight the sponsor and project manager will review change requests and together with other appropriate people, such as the person making the request, will determine the need for change and evaluate options and make a decision on whether and how to implement changes. Any change requiring or making likely a material increase in the project budget will be presented to the full project steering committee.'

A Change Control Board is a body of people responsible to the organization for evaluating and deciding on change requests. It is usually a sub-group of the project steering committee. Change Control Boards are not necessary in all projects, and typically they will be used only for the larger and more complex projects.

A checklist to ensure that your project has a change control system is:

  • Do you and the sponsor have a clear idea in your minds of why a change control system is needed?

  • Do you know how it will work in your project?

  • Is this documented somewhere?

  • Is it in the plan?

  • Has it or will it be communicated to key stakeholders, to manage their expectations of what is and is not likely, or reasonable, in terms of change in the project, from their point of view?

  • Does your organization have standard forms to be used in change control?

  • Who is most likely to generate change requests, or to be otherwise involved in the change control system?

PMI says

Change control system

'Change control system (Tool). A collection of formally documented procedures that define how project deliverables and documentation will be controlled, changed, and approved. In most application areas the change control system is a subset of the configuration management system.' PMBOK Guide (p.353)

Drum resource

A drum resource is a resource that sets the pace of the rest of the project. The term comes from the analogy of an ancient galley, where the man on the drum set the pace of rowing and thus the speed of the ship by beating the drum[7]. Usually the drum resource is the scarcest resource that is critical to the project. In investment banking this is very often the subject matter expert for risk management: work simply cannot proceed on a project at a rate faster than that allowed by the availability of the risk management experts, who tend always to be in short supply. This means that the most effective way to speed up all projects across the bank is to manage very carefully the availability of the risk managers, the drum resource, to ensure that it is used as efficiently as possible.

Hammock task

There are two different meanings of this term. In this book we follow the more widely used one, which is a task that continues throughout the project, from beginning to end. Time recording, maintaining the issues log and communicating with stakeholders are all examples of hammock tasks. The term comes from the analogy to a hammock slung between two posts, the start post and the finish post[8]. The PMI's PMBOK uses 'hammock activity' in a different way, to mean 'summary activity'. In that sense it is a set of activities reported at summary level, that is, as an aggregate. We do not use the term in that way in this book (and so far as we are aware, knowledge of that use is not something that will make much difference to passing the PMI's exams, for those readers who are interested).

'Hammock task' is a useful term, in the sense of meaning a task that runs throughout the project, because it helps the project manager to be clear in their own minds and to communicate about such tasks. One example of how this helps in real-life project management is that instead of taking up space on a Gantt or PERT chart to show highly important hammock tasks, they can be listed under the heading 'Hammock tasks', thus simplifying the chart and so reducing the risk of confusion, without losing sight of the importance of the hammock tasks.

Integrated change control

No plan survives contact with reality. In real life, you will have to adapt and update your plan to deal with reality. You will have to keep changing your plan right from project initiation though to project completion. If you do not update the plan, then an ever-widening gap between what the plan says and what is actually happening will emerge, and as this gap grows the usefulness of the plan will diminish and the risks in your project, and the risks to your career, will grow. Integrated change control is the process by which you control change in your project. You have a choice: either you control change or it controls you. (We have said this before, but experience from real-life project management shows that it is worth repeating.)

PMI says

Integrated change control

'Integrated change control (Process). The process of reviewing all change requests, approving changes and controlling changes to deliverables and organizational process assets.' PMBOK Guide (p.363)

The sequence of events in a typical change control process is as follows:

  • Identify a possible change or establish that a change has already taken place.

  • Review the change and understand the reason for and impact of it.

  • Approve or reject the change, being sure to involve key stakeholders.

  • Modify the plan and baselines accordingly.

  • Agree necessary ramifications (e.g. budget increase) with stakeholders.

The integrated change control process can also be used to assess and authorize corrective or preventive actions (see below). Any change needs to be incorporated into the project management plan, and this is a key part of project integration management, because unless this happens coordination and efficiency, which are what integration is about, are lost. The change may also need to be incorporated within the other project documents and plans, such as budgets, risk management plans, work breakdown, communication planning and product specifications. Any stakeholder affected by the change must be not just notified but communicated with sensitively to ensure that all concerned with the project are using the same version of the project management plan. The project must then be managed in accordance with the new project management plan.

Corrective and preventive actions

Corrective and preventive actions help to maintain the project's performance with the specified baselines. Put another way, actual performance may vary from planned performance, and corrective and preventive actions are ways to help the project correct the variance and get back on track. In plain language, a preventive action is something you do to avoid a problem before it happens, and a corrective action is something you do to fix a problem after it has happened.

These ideas are, of course, common sense, like almost everything in project management. The point of making them explicit in project management is to help minimize wasted time by being absolutely clear about things that need to be done and thought about, so that you do not spend time on them when they are not necessary. In any moderately large or complex project, there will be people who for various reasons in effect want to think about preventive actions when what is needed is a corrective one, or to embark on corrective actions before they are necessary. Having a clear categorization of these simple ideas helps integration and saves time.

PMI says

Preventive and corrective actions

'Preventive Action. Documented direction to perform an activity that can reduce the probability of negative consequences associated with project risks.' PMBOK Guide (p.356)

'Corrective Action. Documented direction for executing the project work to bring the expected future performance of the project work in line with the project management plan.' PMBOK Guide (p.367)

The reporting used in a project should be designed to ensure that the most likely variances are reported and if possible forecast in regular reports. The most basic report (or reports) is the one showing the project's actual spend and actual deliverables produced against the planned spend and planned deliverables, by time.

Any material variance from the planned baseline should be assessed and discussed by relevant stakeholders, including at least the sponsor and project manager. Trivial variances can be ignored. The projects will need corrective or preventive action to address the variance. This action should be agreed through the appropriate mechanism, and that mechanism should be specified in the plan, and then implemented, and the plan and baselines updated. It is important to have a systematic approach to assessing and deciding on preventive and corrective actions, not only because it is simply efficient to do this, but also because if you adopt a different approach each time there is a high risk of unintentionally sending out a negative signal to some stakeholders which will risk turning them against the project. Stakeholders, like all people, prefer consistency in the way in which news that affects their interests is communicated to them.

Project selection methods

It is a fact of management life that there are more things to do than time and resources in which to do them, which is to say that there are more projects to be done than can be done. Therefore every organization has a mechanism for selecting from the large number of potential projects the smaller number to be worked on. This process should be a formal one, because if there is no formal process then the default selection method tends towards chaos, duplication and randomness in short, a mess. What has this got to do with project integration management?

How projects are selected can affect integration. To take a hypothetical example to illustrate the point, suppose that a $10 million project has been given approval to proceed because firstly, it will deliver a database necessary for compliance with a new regulatory regime, and secondly, it will consolidate three state databases into one regional database. Neither of these benefits will justify the project on its own, but together they justify it. Three-quarters of the way through the project, the new regulatory regime looks as if it will very probably be cancelled before the project delivers, but the sunk costs are such that it is worth proceeding with the project to realize the benefits of the database consolidation. This hypothetical example illustrates two ways in which project selection methods relate to integration.

First, the process of project selection and approval will reveal key interfaces and success criteria for the project, which the project manager needs to track so that the project can change and adapt accordingly. It will reveal these because key stakeholders will be involved or identified in the approval process, and once known their interfaces to the project and their success criteria can easily be determined.

Let's be quite clear: delivering perfectly on the original specifications, even if they don't change, is not necessarily success. Part of the project manager's responsibility, working with the sponsor, is to monitor changes in the external environment that affect the value of the project to the organization, and proactively suggest changes to the project. It will often be that delivering perfectly on the project specifications is in fact success, but it is also common for this not to hold, which is how 'white elephants' arise. This is not a new problem: when armies started using gunpowder, stone castles became obsolete, as they offered no defence against cannon. Before the introduction of gunpowder, to build a castle to plan was to deliver a successful project. The castle was the tangible deliverable, and the business benefit was military defence against the enemy. The moment the enemy started to use cannon, delivering a castle in the old style was a value-destroying activity, even if the castle came in early, below budget and looked wonderful. Castles needed to be fundamentally redesigned to manage the risk of attack by cannon. Fort Brockhurst, Fort Nelson and the other Portsdown forts along the south coast of Britain were initiated by Lord Palmerston in 1859 to address the risk of an invasion, but advances in artillery technology made them obsolete within a few years of completion.

We don't build castles any more, but this kind of mistake is alive and well in project management. Real elephants are an endangered species, white elephants are not. Mankind's ability to produce white elephants is undiminished. You should ensure that your project does not become one.

The three key things from the point of view of project integration management for the project manager to find out from the project selection process are:

  • Who has an interest in the project?

  • Why do the project? That is, how is the project expected to add value to the organization?

  • How will others judge whether the project is a success?

Ideally the project manager will be involved in the project selection process. While organizations should select projects by some objective mechanism that ranks them in order of value of the organization, in real life there may, in some organizations, be some projects that are selected because they are a senior executive's pet project. (This is not necessarily a bad thing: those people may have been promoted or elected in large part because they have been able to see value in projects and other things before there was widespread consensus for them.) In such cases, the integration aspect is the same: the project manager will benefit from understanding that this is the case, and from knowing who are the people close to the senior executive as far as the project is concerned, and why the executive wants the project.

Finally, it is worth making the point that at the very least, as a project manager you should know that your project exists because it has been through some selection process, formal or not. This means that there is a group of people who will be watching your project and have certain expectations of what it will and won't do. Managing those expectations is part of your job. Confound them at your peril.

Earned value technique

A method commonly cited in project management theory as being used to determine the project's performance against the performance baseline from initiation to project closure is called the Earned Value Technique (EVT). Our experience is that it is much less used in real life, but it is useful to know about it even if your organization does not typically use it, for those occasions where someone senior challenges you to justify your project's rate of progress, or to implement a 'more objective' reporting mechanism. It is a useful technique to know about and have in your back pocket, so to speak.

PMI says

Earned value and earned value technique

'Earned Value (EV). The value of work performed expressed in terms of the approved budget assigned to that work for a schedule activity or work breakdown structure component. ...' PMBOK Guide (p.359)

'Earned Value Technique (Technique). A specific technique for measuring the performance of work and used to establish the performance measurement baseline (PMB). Also referred to as the earning rules and crediting method.' PMBOK Guide (p.360)

Some project managers use the earned value technique to compare the actual performance of the project against the planned forecast. A reason for using EVT is that it integrates the time, cost and work done. These figures can also be used to reforecast the project's future performance and completion date by applying the project's previous performance. A number of changes or corrective actions are produced after applying this assessment technique, because it is useful to control cost and production activities.

One aspect of control is to establish the cause of any variance shown from the actual versus planned performance figures. EVT uses the baselines stated in the project management plan to determine the level of progress and the variations which may have occurred within the scheduled activities, work packages or control account. Table 4.3 lists the various terms and formulae used within the earned value technique.

Table 4.3. Terms, abbreviations and formulae in the earned value technique
Term Abbreviation and formula Definition
Planned value PV Estimated value of the work scheduled to be done
Earned value EV Estimated value of the work actually completed to date
Actual cost AC Actual cost charged for the work completed so far
Cost variance CV


Difference of earned cost minus actual cost. (A positive value means under budget; a negative value means over budget)
Schedule variance SV


Difference of earned schedule minus planned schedule. (A positive value means ahead of schedule; a negative value means behind schedule)
Cost performance index CPI


A cost efficiency indicator showing the cost value achieved by the project. (A value greater than 1 means that costs are running above budget; below 1, that costs are running below budget)
Schedule performance index SPI


A schedule completion indicator showing the work completed compared to the planned schedule. (A value greater than 1 means that the project is running ahead of schedule; below 1, that it is running behind schedule)
Budget at completion BAC Declared budget for the total project stated at the beginning of the work
Estimate at completion EAC


Total project costs at current forecast
Estimate to complete ETC


From current spend, how much extra the cost is forecast to be
Variance at completion VAC


Difference of total project costs minus budgeted costs
  Adapted from PMBOK Guide, Chapter 7 Project Cost Management,' p.157ff.

The parameters used may be employed on a period-by-period basis (month-by-month, quarter-by-quarter, etc), or simply on a cumulative basis which runs throughout the project. The selection used depends on the overall timeframe of the project and the assessment criteria applied by the project manager or sponsor.

Let's step back from the detail of these formulae for a moment and ask a few questions. Why do we have these formulae and how should we use them? And what in particular do they mean for project integration management? Simply, these formulae help us to understand, and to communicate to others, where we are in the project. In particular, from the perspective of project integration management, they help us to focus on what is important. For example, imagine a big or complex project where there is too much detail for you to have a reliable intuitive sense of how things are going. You have been asked by the sponsor to help them prepare an ad hoc report to the chief executive about your project. You run some numbers, and find that SPI is 1.1, and CPI is 0.9. This tells you that your project is ahead of schedule, but over budget, both by 10 per cent. If that is a problem, then you know that you need to focus your efforts on managing costs rather than, say, speeding up progress. This means you know roughly where to apply your efforts, and how big the problem is. If SPI was 0.5 and CPI was 1.5, you would need to take a different kind of action. In a small project you will probably have a good, reliable intuitive grasp of these things, but even then it may help you to have some hard data to back up your claims. In larger or complex projects, often you need data to understand where you are.

Do you have to use the formulae as presented here? No. These formulae are common sense formulae designed to answer certain key questions, such as 'Are we over or underspent?', 'Are we ahead or behind plan in terms of results produced?' and 'How much of the project have we done so far?'. You can invent your own metrics to answer these and other key questions, and indeed your own organization may already have its own preferred metrics for measuring project progress which are different from the ones measured here. All that matters is that you understand what question you are answering, ensure that the metric does answer it, and finally, apply the metric consistently throughout the project. And from the integration perspective, remember that these metrics are a way to help you focus on just the right things at the right time.

The analysis of variance is not confined to just cost and time. Factors such as project scope, risk and quality can also be assessed for variance from the project's plan. Another area of analysis is to evaluate the trend in performance to determine whether the recent work output is improving or deteriorating with time. The scale of deviation from the planned values is likely to reduce as the project heads towards closure because the team's level of understanding of the project increases, while the risk factor also tends to reduce as the project moves to the final stage of completion.

Configuration management system

The configuration management system is used to track and monitor all the changes within the project management plan. It is used to inform the project team and stakeholders about the current amendment state of each plan and baseline document contained in the project management plan. The benefit of operating such a system is that everyone is aware of the latest version of the schedule and performance baselines.

PMI says

Configuration management system

'Configuration Management System (Tool). A subsystem of the overall project management system. It is a collection of formal documented procedures used to apply technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a product, result, service or component; control any changes to such characteristics; and support the audit of the products, results, or components to verify conformance to requirements. It includes the documentation, tracking systems, and defined approval levels necessary for authorizing and controlling changes. In most application areas, the configuration management system includes the change control system.' PMBOK Guide (p.354)

The configuration management system includes the change control system. The configuration management system also describes the agreed approval levels for the authorization of proposed changes. For example, the project manager may be authorized in it to approve negative variances of up to 5 per cent, the sponsor of up to 15 per cent, with any greater variances to be referred to the Steering Committee. The system also provides an audit trail to check and validate conformance against the requirements. It is not just government bureaucracies in which being able to deliver an audit trail is useful: it is useful in many private sector companies to be able to show that what has been delivered is what people said they wanted, right up to the last minute.

Change Control Board

The project manager is not always the subject matter expert, nor are they in possession of all the facts necessary to make a decision relating to a change request. A Change Control Board (CCB) should be established for a project that is responsible for reviewing all change requests and to decide whether more information is required before the board is able to assess the change. The CCB should consist of the sponsor, stakeholders and the project manager, but expert members could also be included if the change to be reviewed requires someone with a more detailed knowledge of the subject matter. The work of the CCB is therefore to approve or reject changes submitted for consideration, and then to document the recommendations made by the board. Often the CCB is a sub-group of the Project Steering Committee.

PMI says

Change Control Board

'Change Control Board (CCB). A formally constituted group of stakeholders responsible for reviewing, evaluating, approving, delaying or rejecting changes to the project, with all decisions and recommendations being recorded.' PMBOK Guide (p.353)

Monitor and control project work

Monitoring and controlling of project work is conducted throughout the project from initiation to closing. This activity is a major control function for the project manager to ensure everything is occurring at the correct time and within cost. Integration of all the process inputs and outputs is key to controlling the project and maintaining the right level of supervision for the project. A larger project will produce a greater number of activities because of its size and complex nature; therefore an appropriate level of guidance on how to control the planning process should be generated for this purpose. The outcomes from monitoring and controlling the project work are corrective and preventive actions, defect repairs, and recommendations to change the project. All of these changes are considered, assessed and either accepted or rejected for implementation under the banner of integrated change control.

Configuration management

The configuration management system, as a system, is described in a separate section in this chapter. Here we look at the concept of configuration management. The main objective of configuration management is to ensure that the project and any changes to it meet the specified requirements of the project. It is concerned with conformance to requirements, and as such is closely allied to the quality management system. The size and complexity of the project dictates the level of configuration management required. Configuration management is also about confirming the results of the various changes implemented and communicating to all stakeholders regarding the changes approved.

Configuration management = change control
    + identifying and documenting the required characteristics or specification of work products
    + auditing conformance to requirements

Key Idea

Change control and configuration management: how they are related?

Change control
Understanding the characteristics or
specification of work products
Auditing conformance to requirements
Configuration management

One of the implications of the difference between configuration management and change control as formulated above is that the people who run the project's change control process do not necessarily need to understand the characteristics of the work products to be produced. This reduces the cost of the change control process, and enables the change control function to be managed as a discrete process.

Lessons learned

Lessons learned are the easiest but the least used way to improve your current project and the projects you and your organization will own in the future. Again, learning lessons from what you have done is common sense. It needs to be part of your project management process because if not, the pressures of day-to-day life make it likely that you will miss out on the easy benefits of learning lessons. Having a formal process also helps ensure that not just you but others learn the lessons. And finally, a lessons learned process in project management is likely to be an essential part of quality management procedures, such as ISO 9000, in your organization.

PMI says

Lessons learned

'Lessons Learned (Output/Input). The learning gained from the process of performing the project. Lessons learned may be identified at any point. Also considered as project records, to be included in the lessons learned knowledge base.' PMBOK Guide (p.363)

Lessons learned are collected at all stages of the project, right from the start right up to the finish. Do not put off capturing lessons learned and discussing them until you are 'into the main project', or the chances are you never will. Start the way you mean to go on. This process is vital to continuous improvement of your organization's project management and other processes.

How should you capture lessons learned? If your organization already has a lessons learned process, use that. Have a look on your corporate intranet if you are not already aware of it, failing which, your organization's quality manager should be able to help. If you need to create a lessons learned process from scratch for your projects, be pragmatic and design something that is simple and will work, avoiding over-elaboration. The two main elements are a template for recording the information, and a process to ensure that the information is captured and, most importantly, used to improve your project performance in future.

The template or form to capture lessons learned should include the following information:

  • Name of the project and date.

  • Description of the lesson.

  • Is the lesson something that worked well or badly?

  • If badly, how could it have been done better? If well, what should be repeated or reused next time? The vital question is what should we do or do differently next time?

  • Brief rationale for the above, if not obvious.

  • Some indication of the importance of the lesson, at least whether of high, medium or low value.

  • To which project management knowledge area is the lesson applicable?

    - In which stage of the project management lifecycle?

    - To which of your organization's processes?

    - To which of your organization's divisions or products?

    - To which of your organization's people?

In designing your process and in your overall approach to lessons learned, consider always human psychology. The aim is to learn from what has happened, both good and bad things, to make the rest of this project and all subsequent projects better, and to make the rest of your career as a project manager, and the careers of everyone else on the project, better than they would be without the lessons learned process. If lessons learned is seen as a threat to people, as a blaming and scapegoating activity, or as pointless bureaucracy, then there is little point in doing it. So you need to manage the way that the process is perceived, and the human element and emotions around it.

The document should outline what worked well, what did not go quite so well and how things could have been done differently. It is useful in larger projects to split lessons learned into categories. Ten possible categories are:

  • Technical aspects of the project.

  • How well the project plans and related documents worked.

  • How useful and timely the project reporting and metrics were.

  • Causes of variance encountered within the project.

  • Communication and buy-in issues.

  • The rationale for and success of particular corrective actions.

  • Which tools should be used again and which dropped.

  • Which techniques should be used more.

  • What project management or other training should be given and to whom.

  • The performance of the project manager.

Bearing in mind the point above about the human psychology of lessons learned, it may be useful to run the lessons learned process for the last of the above categories in a slightly different way from the others.

Administrative closure

Administrative closure can occur throughout the project, although this would usually take place at set phase breaks within the project. It is typical for small or medium-sized projects to conduct administrative closure at the end of the project, but it must not be concluded until contract closure has finished. In comparison to contract closure, the procedure covered in administrative closure contains only the roles, responsibilities and activities of the project team. The procedure will also establish how the product or service will be transferred to the user. Further elements addressed within administrative closure are how the project will meet the specified requirements, what is necessary to meet acceptance of the deliverables, and finally to confirm the criteria of project completion. The last task is to place all the project plans and information within the company archives for future reference.

Contract closure

Contract closure concentrates on the closure of a contract specifically linked to a project. Contract closure is conducted only at the end of the project, but closure must also be concluded if the contract was stopped or terminated for any reason prior to formal completion. The closure procedure should cover the steps to be followed in order to comply with the terms and conditions laid down in the contract, as well as the criteria listed for contract closure. Contract closure describes the roles, responsibilities and activities of the project team; it also includes stakeholder and customer involvement during the contract closure process. The closure procedure will detail the work associated with the contract, such as ensuring all the payment actions are complete and the cost records are finalized for audit purposes. The final contract performance report should be produced to specify the effectiveness and success of the contract. The procedure could also be used to describe how and when loan equipment is returned to its owner.

Once the project criteria have been met and formal acceptance has been stated, the next stage is to hand over the product or service for which the project was originally authorized. In contract terms, a receipt is required to declare that the project has met the terms and conditions of the contract. The formal basis of a contract means good records must be kept, which includes the contract, list of changes, alterations made to the deliverables and the agreed terms and conditions. All of this documentation is required for normal audit procedures, but it could be important if a dispute arises and legal protection is necessary.

Close project

The closing process is the last of the five process groups, and one element of this is the 'close project' process. The key planning activity conducted under the close project process is to detail how the project will be closed, as well as the procedures required for administrative and contract closure. The two closure procedures will be covered later, but the difference between them is linked to the formality and frequency of the work. Once the technical work is finished, the close project process involves completing all of the activities from the other process groups in order to close formally the project or project phase. Similar close project activities would also be applied if a cancelled project was being wound up, although the requirement to hand over the project, as part of the closing process group, would not be needed.

PMI says

Close project

'Close Project (Process). The process of finalizing all activities across all of the project process groups to close formally the project or phase.' PMBOK Guide (p.354)

Top of Page

Definitive Guide to Project Management. The Fast Track to Getting the Job Done on Time and on Budget
The Definitive Guide to Project Management: The fast track to getting the job done on time and on budget (2nd Edition)
ISBN: 0273710974
EAN: 2147483647
Year: 2007
Pages: 217
Authors: Sebastian Nokes

Similar book on Amazon
Measurement Made Accessible: A Research Approach Using Qualitative, Quantitative and Quality Improvement Methods
Measurement Made Accessible: A Research Approach Using Qualitative, Quantitative and Quality Improvement Methods
The Conflict Resolution Toolbox: Models and Maps for Analyzing, Diagnosing, and Resolving Conflict
The Conflict Resolution Toolbox: Models and Maps for Analyzing, Diagnosing, and Resolving Conflict
Financial Intelligence: A Manager's Guide to Knowing What the Numbers Really Mean
Financial Intelligence: A Manager's Guide to Knowing What the Numbers Really Mean
Management Skills: A Jossey-Bass Reader (The Jossey-Bass Business and Management Reader Series)
Management Skills: A Jossey-Bass Reader (The Jossey-Bass Business and Management Reader Series)

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net