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.
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:
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.
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:
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 systemThe 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:
Other functions can include:
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 systemsHowever 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:
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:
Drum resourceA 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 taskThere 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 controlNo 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.)
The sequence of events in a typical change control process is as follows:
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 actionsCorrective 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.
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 methodsIt 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:
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 techniqueA 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.
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.
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 systemThe 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.
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 BoardThe 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.
Monitor and control project workMonitoring 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 managementThe 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.
Lessons learnedLessons 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.
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:
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:
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 closureAdministrative 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 closureContract 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 projectThe 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.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Top of Page
