Contingency planning is an essential part of project management simply because of the degree of risk and uncertainty involved in such an undertaking. It involves having some kind of safety net in case of unforeseen circumstances. Contingency is added to both the project budget and the project schedule in order to allow for unforeseen costs or additional work requirements. The degree of contingency to be added will depend on the degree of risk and uncertainty associated with the project. This can only be determined by carrying out a risk assessment. In general, there are two approaches to risk assessment. One is to assess the risk associated with every control package, and allocate contingency to each accordingly. The other is to allocate a single contingency figure for the entire project, and draw down contingency resources for individual control packages as and when needed. There are a number of advantages and disadvantages to both approaches, although the latter approach seems to be more widely used.
Project costs are to a large extent dependent on the amount of time it will take to complete the project, simply because this will be closely related to two of the major cost factors involved – man-hours and the total contribution to overheads. Any delays in completing the project are therefore likely to have a serious impact on cost. Perhaps the single biggest risk factor for any project is therefore the accuracy (or lack thereof) of the estimated task duration for each work package or control package. The estimates should of course be carried out by those responsible for doing the work and who (presumably) have the necessary knowledge and experience to come up with an accurate estimate. Historical data, if it exists, can also be used as a basis for estimating task duration. Ultimately, however, the accuracy of the estimate will depend the skill, knowledge and experience of the individual doing the estimating. It is essentially a best guess based on available information.
The degree of schedule contingency required will depend on the degree of certainty with which the original estimate has been made, and the degree of risk associated with any significant schedule slippage. If there is a penalty clause built into the contract for late completion, the degree of risk can be considered to be quite high. If the schedule itself is subject to a number of variables that cannot be accurately predicted, there is a more chance of it not being particularly accurate. Another issue that will affect how much schedule contingency is needed is the availability of additional resources that can be deployed in order to bring the project back on schedule, should things start to slip. If additional resources can be assigned to the project relatively easily, the degree of risk may not be so great. Alternatively, it may be possible to negotiate with the client to reduce the scope of the project in order to meet the project deadline.
The calculations required by the Project Evaluation and Review Technique (PERT) provide three time estimates for carrying out each work activity. The pessimistic estimate gives us a task duration based on a worst case scenario, while the optimistic estimate provides a task duration that assumes everything goes according to plan. Somewhere between the two lies the most likely estimate – essentially a best guess. The three figures thus derived can be used to find the expected task duration using a simple formula to calculate the average time the task would require if it were repeated a number of times over a given period. The PERT techniques are dealt with in more depth elsewhere, but they provide a means by which reasonably accurate task durations can be derived. They also give an indication of the range of values for task duration that might apply to a given work package. The numbers derived from a PERT analysis, together with the results of a risk analysis, can be used with a Monte Carlo simulation to analyse the likelihood of a range of possible outcomes. Monte Carlo methods are computational algorithms that repeatedly carry out the same calculations using pseudo-random numbers, and are often used to model the behaviour of systems in which there are a large number of variables (and therefore a high degree of uncertainty and risk). Many project management software packages now provide automated facilities for carrying out the necessary calculations. The risks associated with delays in the project schedule can thus be realistically assessed, and contingency time can be added to the schedule that is commensurate with the degree of risk involved.
Cost overruns have two primary causes. The first is due to the expenditure of more money than has actually been budgeted for the work planned, perhaps due to inaccurate estimates of the time required or poor task performance. The second is due to the addition of unplanned work to the project, either because something was left out of the work schedule at the planning stage, or because the scope of the project has been extended, or because technical issues have forced us to carry out the work in a different way. Budget contingency refers to a sum of money that is added to the initial project cost estimate to allow for such additional work. Remember that changes to scope will require an adjustment to the project baseline, both in terms of the budget and the schedule. If the project is being undertaken on behalf of a customer, any additional work requested by the customer that represents an extension to the project scope should be accompanied by a renegotiation of the contract.
It is important to manage contingency. It should not be seen as a way of compensating for poor task performance, or poor project management. It is in fact a reserve that should only be used to accommodate additional work, should it become necessary. If schedule or budget contingency (or both) are drawn down to bring a particular control package back on track, the project baseline should be amended accordingly. The action should be recorded, and will figure in the post-project appraisal process so that lessons for the future can be learned. Once the project is complete, any unused budget contingency is either included in the profits realised by the project, or is released for use elsewhere.
This article was first published on the TechnologyUK.net website in January 2009.
The two variables that need to be closely monitored during the execution phase of the project are expenditure to date and work accomplished. These variables are fairly closely related, since any delays in completing the work will have the potential to increase the overall cost of the project. Progress is usually measured at each project milestone, providing a snapshot of the project’s status at that point in time. The actual performance at any given point in time can then be compared to the project baseline to determine whether or not there has been any significant slippage (or variance), and if necessary corrective action can be taken. Milestones are often set to mark the completion of a group of related work packages (the low-level activities derived from the work breakdown structure), collectively known as a control package. The control package itself is usually defined at some higher-level within the WBS hierarchy. The cost associated with each control package can be estimated simply by adding the individual cost of each work package within it. The time required to complete the control package is not so easy to derive, since it is possible that two or more work packages within a control package might be executed concurrently. Instead, the total work effort required (in terms of man-hours) is used.
The essence of project management is to try to ensure that, as far as possible, the project stays within budget and on schedule. The purpose of a project milestone is to represent a point in time at which progress can be measured, both in terms of the work accomplished and the costs incurred to date. These values can then be compared to the project baseline to determine whether or not there is any variance (positive or negative), and if so how large the variance is. The ability to measure progress in this way makes it possible to exercise control over the project by flagging up any problems that may be developing and doing something about them. One of the most commonly used techniques for measuring the progress of a project is called Earned Value Analysis (EVA). Some of the terminology used in EVA is explained below.
Variances in cost and schedule are used as the basis for reporting problems to various levels of management and other stakeholders. Thresholds can be set for both to determine if, when, and at what level a variance should be reported. Of course, the degree of variance that may be tolerated will depend on the nature of the project. The acceptable variance will tend to be lower for a well-defined and well-understood problem domain.
If the project involves research and development and there are many unknowns to contend with, much greater tolerances may be defined (although ultimately, the goal of the project manager should be to stay on schedule and within budget). The reporting of problems to higher levels of management on the basis of whether or not variance thresholds have been exceeded fits in well with the idea of management by exception, whereby senior levels of management do not directly intervene in a project unless they are required to do so by circumstances. Two commonly used formulae for calculating the variances are:
Cost variance = BCWP - ACWP
Schedule variance = BCWP - BCWS
Work in progress is evaluated for each control package at the end of each project monitoring period (for argument’s sake, this could be done on a monthly basis). The cumulative value of the work completed to date (its earned value) is calculated using the budgeted cost of carrying out the work. At the same time, the actual costs of carrying out the work are derived from various sources (supplier invoices, staff timesheets etc.) and can be compared with the budgeted costs. The earned value and actual cost can be plotted on a graph and compared to the BCWS curve, which represents planned performance in terms of cost and schedule.
The BCWS curve represents the project baseline. If the actual cost (represented by the ACWP curve) and the work performed (represented by the BCWP curve) match or closely follow the BCWS curve, it is an indication that all is well and that the project is on budget and on schedule. If the ACWP curve is significantly above the BCWS curve, a cost overrun is indicated. By the same token, if the BCWP curve is significantly below the BCWS curve, the project is behind schedule. The curves for a generic 12-month project with a projected cost of £250,000 are illustrated below.
It can be seen from the above that nine months into the project there is a cost overrun of £79,000, and the project is nearly a month behind schedule. The figures used for the example have been chosen to highlight the principle, but sadly many projects have fared as badly, if not worse. If problems are highlighted by the earned value analysis (sometimes called variance analysis), further investigation needs to be carried out to determine exactly where the problems are occurring. Each control package must be examined in order to pinpoint which are over budget or behind schedule. It should be relatively easy to identify which control packages (or individual work packages) are causing a problem by comparing their actual status with the detailed project plan.
Even if the variances are insignificant, it does not mean that there are no problems developing. This is particularly true for the project schedule, since although an acceptable schedule variance is obviously a favourable indicator it does not guarantee that activities that lie on the critical path are being completed on time. Additional checks and balances should be applied to ensure that there are no hidden problems developing. A secondary benefit of earned value analysis is that if the project is being undertaken for an external customer, and the customer is being invoiced at pre-defined intervals on the basis of work completed, earned value analysis can be used to calculate how much work should be invoiced out for a given accounting period.
This article was first published on the TechnologyUK.net website in January 2009.
The project budget is an estimate of the total costs that must be incurred in order to complete the project. Because of the large number of variables involved in any complex undertaking, the accuracy of the budget will inevitably be limited, and therefore represents a risk factor in the sense that you may spend more than anticipated. For this reason, most project budgets include a contingency to cover unexpected costs (this is sometimes referred to as slack). The size of the contingency allowed as a percentage of the overall budget will depend on the degree of accuracy predicted. If the estimate is thought to be accurate within ten percent, for example, then a contingency of ten percent should be added to the initial estimate. Assuming that the project manager is responsible for setting the budget, he or she will often be put under pressure by senior management to keep project costs low. There is little point, however, in reducing the projected costs simply to curry favour with management. A frequently used tactic when seeking approval for a project budget is to put forward a somewhat higher figure than you think you need. This allows you to concede a budget reduction when asked to by senior management without leaving the project dangerously underfunded.
The approaches to budgeting vary from one organisation to another, but there are two general approaches that may be adopted. The first of these is top-down budgeting in which the cost of each high level activity identified by the project's Work Breakdown Structure (WBS) is estimated using estimates of the time required to complete the activity and the resources that must be allocated to it. This approach often relies on historical data from previous projects of a similar nature. The second approach is a bottom-up approach in which the low level activities identified by the WBS (the work packages) are used. The staff responsible for undertaking each task are asked to estimate the time required to complete the activity, and to identify any resources (equipment, materials etc.) required for the task. The cost of labour, materials and any other resources are then calculated and summed to obtain the total cost for the work package. Once the cost for each work package has been calculated, the overall direct cost of the project can be calculated.
There are issues related to both top-down and bottom-up approaches to budget estimating. The reliance of the top-down method on historical data can lead to inaccuracies if the data is incomplete, if there have been significant changes in costs in the intervening period, or if the current project is significantly different in nature from previous projects. The bottom-up method is on the face of it a more accurate one, but places far greater reliance on the experience and estimating skills of individual project team members. There is also more chance of some elements being overlooked. An alternative to relying on only one approach is to use both, and then compare the results. If the figures arrived at are reasonably close, the estimates are probably good. If not, they may need to be re-examined.
Usually, by far the biggest single cost factor in any project is the cost of labour (the time spend by project personnel actually carrying out the work). Bear in mind that project staff will also spend some of their time in planning or review meetings, completing project documentation, or in the execution of other administrative duties not directly related to the project work packages. The time required to plan and manage the project must also be accounted for when creating the project budget. The cost of the man hours for individual work packages will usually be calculated using the hourly rate that applies to the person (or persons) carrying out the task. The rate applied may reflect the salary or wage structure for the individual carrying out the work, or it may be a general hourly rate applied to the project as a whole. Either way, it will include an allowance to cover the additional costs involved in employing a member of staff, such as National Insurance contributions.
The other costs that will be incurred include the costs of purchasing materials and equipment, money paid to subcontractors, staff training and overheads. It may include things like travel and accommodation expenses if any of the work is being done is to be carried out at a remote location. It will be necessary to determine what materials and other resources are required for the various project activities, and allocate a cost to them for each activity. This is normally done for each work package identified by the work breakdown structure and should therefore provide a reasonably accurate estimate of the cost of such resources, providing nothing is overlooked. The term overheads usually refers to costs that will be incurred whether or not work on the project is proceeding, and can include things such as rent and rates, heating and lighting. Some organisations set a fixed contribution to overheads for the project based on the project's estimated turnover as a percentage of the total projected turnover of the organisation during the period over which the project is scheduled to run. The advantage of this method is that the contribution to overheads can usually be accurately determined in advance.
Generally speaking the bigger the project, the less accurate the budget will be. It is therefore important both to build in a contingency and to manage the expectations of the various stakeholders of the costs involved. Making sure that everybody concerned is aware of the potential costs will hopefully eliminate or at least reduce the likelihood of unpleasant surprises in the latter stages of the project. If senior management are intent on trimming the budget they sometimes see the project contingency as excess fat. It will sometimes be possible to argue your case providing you have been careful to document the source of cost information and any assumptions you have made in arriving at the final budget figure. If forced to accept a reduction in the budget, you may need to make some revised cost estimates. If costs cannot realistically be reduced, it may be necessary to negotiate with the project client to amend the scope of the project in order to reduce the amount of work involved. Remember that if you come in under budget you will be seen as having done a good job. If not, you will be responsible for explaining any cost overruns. This is unfair if you have been saddled with an unrealistic budget, but it happens.
The project budget, together with the project schedule, form the baseline for the project and will be used to measure actual progress at various milestones throughout the implementation phase of the project. If changes in the scope of the project result in approved changes to the project plan, new cost and schedule estimates may be required, and a new baseline will emerge. The baseline should not be changed, however, to reflect cost or schedule overruns at a given project milestone. The purpose of the baseline is, after all, to enable project status to be monitored and evaluated. If actual progress is falling behind planned progress, measures should be taken to try and get the project back on track. In terms of both the budget and the work schedule, milestones are selected that represent the completion of each high-level work activity. Intermediate milestones may also be used to allow interim progress reports to be made by the project team, and will represent the completion of work activities at a lower level. Each work activity, at whatever level, should have a cost allocation within the overall budget. It should therefore be possible to detect any significant variation between expected and actual costs before things get too far along.
While the WBS breaks down the project according to work activities, a complementary technique is sometimes used which groups the project costs according to cost centre. This technique, known as a Cost Breakdown Structure (CBS), allocates a different code to the various types of cost, such as labour, materials, and subcontracted work.
This article was first published on the TechnologyUK.net website in January 2009.
Cost-benefit analysis is a process intended to determine whether the total expected benefits that will be produced as a result of implementing change outweigh the total expected cost involved. Both the benefits and the costs are usually expressed in terms of financial values, and values may be adjusted to reflect the period of time over which the costs are incurred, or the benefits realised. Whilst the monetary costs of an undertaking are usually relatively easy to determine in terms of materials, capital expenditure, overheads and the estimated cost of labour, the financial value of the benefits is often more difficult to quantify. The more tangible benefits of a venture could be manifested as a reduction in operating costs (for example, being able to maintain current output with fewer employees) or as an increase in income (for example, increasing output with no associated increase in labour costs due to improvements in process efficiency). Less tangible benefits could take the form of greater flexibility, enabling the organisation to adapt more quickly to a volatile business environment or take advantage of new technologies to market its products and services.
Cost benefit analysis is usually carried out before any decision is made as to whether or not to go ahead with the project, and it will inform that decision. The process may take into account only the financial costs and expected benefits, or it may be extended to include an analysis of the more intangible costs and benefits. Either way, because of the complex issues that are usually involved, the degree of uncertainty over the actual costs that will be incurred, and the real value of any perceived benefits, the process can at best only provide approximate figures. The estimates that are arrived at may ultimately prove to be wide of the mark. Nevertheless, it is a necessary process if the decision on whether to proceed or not is to be an informed one, and should at least identify significant cost drivers and potential benefits.
Fairly obviously, since the benefits of any undertaking cannot be realised until that undertaking has been completed and the deliverables are available for use, the costs of the project (which start to be incurred as soon as work on the project commences) will not be matched by an immediate return on investment. The financial benefits will only start to materialise at some future point in time. The period of time over which the project is adjudged to have paid for itself (i.e. covered its costs) is known as the payback period, and the point in time where the project costs have been recovered is known as the break-even point. Many organisations take the payback period into account when making a decision on whether or not to proceed with a project. If the required return on investment will take too long to achieve, the decision may be to shelve the project. Complicating the equation is the fact that the real value of a sum of money earned at some future point in time will be less than its value in the present thanks to inflation, and the fact that the money has not been working for the organisation (e.g. earning interest or financing ongoing operations) in the intervening period.
Let's look at a simple example of a cost benefit analysis. A commercial director is deciding whether or not to invest in a new computer-based customer service system. The sales department currently has only a handful of computers, and the customer service operatives are not especially computer literate, but he can see the potential value of being able to reach a significantly larger number of customers and provide more efficient customer services, and feels that the new system would enable this to happen. The director carries out a cost benefit analysis, with the results shown below. It can be seen from these figures that (providing the estimates are accurate, of course) the system would pay for itself within the first year of operation - within the first eight months, in fact.
Discounted cash flow (DCF) analysis is a way of calculating the value of money flowing into and out of an organisation over time (the cash flows) based on the concept of its present value. Future cash flows are estimated and then discounted to give their net present values (NPVs). The discount rate used varies, but one commonly used method of discounting is to calculate how much money would have to be invested in the present at a given rate of rate of return in order to achieve the cash flow in the future. The rate of return may be based on current interest rates plus a risk premium that reflects the risk that the future cash flow may not be forthcoming. The future value (FV) of an investment can be calculated as:
FV = NPV x (1 + i)n
Where NPV is the net present value of the future cash flow, i is the interest rate (including any risk premium), and n is the time in years until the cash flow occurs (the unit of time used can be adjusted to reflect the time within which a return on investment is anticipated). Rearranging the formula to get the net present value, we get:
NPV = FV/(1+i)n
This formula represents a relatively simplistic approach that assumes that the interest rate (including the risk premium) remains constant. The formula is applied to both positive and negative cash flows. In a typical project scenario, the cash flows are likely to be negative until some point after the project is completed. The important thing to remember is that at some point in the future (the break-even point), the NPV (represented by the sum of the discounted cash flows up to that point) should acquire a positive value (i.e. it should be greater than zero).
Essentially, if the NPV has a positive value at some point the project will have paid for itself. If not, it will have lost money. To take a simple example, let's assume a project has a total cost of £100,000 over a twelve month period (Year 0). The project is expected to produce cost benefits in the form of an additional annual income of £25,000.00 per annum, and is expected to pay for itself within five years from completion of the project. If a value for i of 7.5% is used, the result will be a small positive NPV, as illustrated below (note that increasing the value of i to 8.0% results in a small negative NPV).
The calculations involved can be set up in any spreadsheet program in a few minutes, enabling a range of outcomes to be calculated by varying factors such as the value of i. The notion of discounted cash flow can be used to calculate how much value a project will add to the organisation over a given period of time. If the net present value at some pre-determined future date is greater than zero, then the project has added value to the organisation. If not, there will be no point (from a financial point of view at least) in continuing with the project. The example given is a relatively simple one and has been used in order to demonstrate the basic principles. In reality such calculations can be affected by a great number of variables, but it is beyond the scope of these pages to consider the implications of this any further. Bear in mind also that even if the calculations result in an unfavourable outcome from a purely monetary point of view, the project may still have long term intangible benefits that cannot be measured in purely financial terms. There could be serious negative consequences as a result of not going ahead with a project.
This article was first published on the TechnologyUK.net website in January 2009.
PRINCE (PRojects IN Controlled Environments) is a process-based project management methodology first established in 1989 by the Central Computer and Telecommunications Agency (CCTA), now known as the Office of Government Commerce (OGC). Now a de facto standard for project management, PRINCE 2 was published in 1996, and is used extensively both by the UK Government and many organisations in the private sector. Although copyright is retained by the Crown, PRINCE 2 is a public domain, non-proprietary standard that offers best practice guidance on project management. The PRINCE 2 methodology has undergone a fundamental revision, the result of which was published in June 2009 as "PRINCE2:2009".
The intention of the revision appears to have been to simplify the methodology, to address known issues, to dispel some common and widely-held misconceptions, and to better meet the requirements of a rapidly changing and volatile business environment. Two manuals have been published that incorporate the changes introduced by the 2009 update. These are "Managing Successful Projects Using PRINCE2 - 2009 Edition" and "Directing Successful Projects Using PRINCE2 - 2009 Edition". Practitioner accreditation is acquired by passing both a Foundation exam and a Practitioner exam, both of which are based on material in the "Managing Successful Projects Using PRINCE2 - 2009 Edition" manual. Practitioners have to re-take the Practitioner exam every five years to maintain their accreditation.
PRINCE2 embodies seven principles based on the following themes:
Business case - the business case provides the justification for undertaking a project, and is based on the cost of development weighed against the anticipated benefits. The business case should show that the proposed solution meets a valid business need, is financially viable, and can be achieved in the time allowed. It should, among other things, define the scope and objectives of the project. The level of detail provided will reflect the size and complexity of the project being undertaken, but the initial version should contain sufficient information to allow the project sponsors to make a decision as to whether or not the project is viable. For large projects involving a considerable financial investment, the business case may include a high-level cost benefit analysis of the available options. If the project goes ahead, the business case will be continuously updated to reflect actual costs incurred and any changes in project scope. The updated information will be used to assess the continued viability of the project, and will inform subsequent decision making. Once the project has been completed, it will be used to assess the degree to which the project has achieved its objectives.
Organisation - each project must have a clearly defined management structure within which roles and responsibilities are identified, and which provides the basis for project governance. The makeup of the management structure will reflect the size, complexity and cost of the project. The key roles within the management structure include:
Quality - a quality review technique ensures that the outputs from the project are of the required standard and meet all of the defined quality criteria. Quality review meetings identify problems, but do not attempt to identify solutions.
Plans - the project plan defines the project's deliverables and specifies the activities that must be undertaken in order to develop them. The activities will be organised into a logical sequence of events, taking into account any task dependencies. Estimates will be made of the duration of each activity and the resources that must be allocated to it, and a schedule of work will be produced (this usually includes the production of a Gantt chart and activity network diagrams using CPM or PERT). The plan will typically specify the pre-requisites for success, list the resources required, and identify areas of risk or uncertainty. It will also include a detailed financial budget for the project, and will identify significant project milestones.
Risk - to manage and mitigate a risk you must identify it, assess the probability of it occurring, and estimate the impact it would have on the project. Good project management controls the project's exposure to risk in order to minimise the possibility of project failure. The Project Manager should regularly review the project's exposure to risk and the measures being taken to reduce or mitigate it. The SRO and (if applicable) the Project Board should actively engage in the risk management process to ensure that risks are identified by the project team and dealt with at an appropriate level.
Change - issues often arise that may alter project parameters, and may include changes to the scope, objectives or completion date of the project. Minor changes are usually dealt with by the project manager, while more far-reaching changes may need to be dealt with at a higher level. Once a change has been requested its impact on the project must be assessed and a decision taken as to whether the change should be made. The change will be given a priority rating based upon whether it is categorised as essential, merely desirable, or cosmetic in nature. This will influence the decision whether or not to implement the change.
Progress - the project plan is a baseline against which progress can be measured. Any deviation from the plan can be identified and corrective action taken if necessary. The Project Manager will allocate work to the project team in accordance with the plan, monitor progress to ensure that deliverables meet specified requirements, and monitor costs and resource usage. The Project Manager has the authority to handle minor deviations from the project plan. For more serious deviations, the SRO and Project Board will need to be involved.
PRINCE2 provides a methodology for managing projects within a clearly defined framework. It describes procedures to coordinate people and activities, how to plan and supervise the project, and what measures should be applied when things do not go as planned. PRINCE2 2009 specifies some forty separate project management activities, which are organised into seven processes. The processes represent a step-by-step progression through the project lifecycle (see the PRICE2 process model diagram below), from starting the project to terminating it. The seven processes are listed below.
Starting up a project - in this process the need for the project is identified and a Business Case is developed. Other activities include the appointment of a Project Manager and if appropriate setting up a Project Board. A Project Brief is prepared that outlines the purpose of the project and its terms of reference including the objectives of the project, the business benefits that will be realised, and the scope of the project. The project brief will form the basis of an agreement between the SRO and the project manager as to what the project is to achieve and how it will proceed. Once the project brief has been completed it will form the basis for the next stage, and will also inform a decision by the SRO and the Project Board as to whether to proceed to the next stage.
Directing a project - this is a process that continues for the duration of the project, and defines how the Project Board (including the SRO) will oversee and control the project. The Project Board operates on the basis of management by exception in the sense that they will not normally be involved in operational decisions unless the project has encountered problems or requires change management that is beyond the remit of the Project Manager. The board will need to authorise the transition from one stage of a project to the next, however, and must be kept informed of progress at regular intervals by means of Highlight Reports.
Initiating a project - in this process the project brief is extended to form a Project Initiation Document (PID). The PID builds on the existing business case and provides a detailed project proposal against which success can be measured, and provides a more accurate estimate of the costs and benefits of the project. It provides an updated assessment of the resources required, the risks involved, and the amount of time needed for successful project completion. The PID also outlines the procedures to be adopted for quality assurance, and defines the roles and responsibilities of each member of the project team. A project plan is created that includes an activity chart of some kind (e.g. a Gantt chart), and a Governance plan is prepared that specifies how the project will be monitored and controlled. The PID must be approved by the SRO and Project Board before the project may proceed to the next stage.
Managing a stage boundary - in order to maintain control over the project's progress, it is necessary to break it down into manageable stages and put in place a process for monitoring and managing progress and resource usage. The Project Manager will identify stage boundaries by calculating how far ahead he can realistically plan daily activities in sufficient detail to retain the required measure of control. The detailed planning for the next stage will therefore often occur towards the end of the current stage, when the information required for planning becomes available.
Controlling a stage - at all key milestones during project implementation (or more frequently should circumstances demand it), the project manager will provide the SRO and Project Board with Highlight Reports containing information about the project's current status. A high level decision will then be taken on whether to proceed to the next stage based on factors such as whether or not the deliverables produced to date are of the required quality, the need for the project has not changed, and the project is still viable. Frequent Checkpoint reports will be produced for the Project Manager by project team leaders. The reports provide updated information on progress and the use of resources, and allow the Project Manager to respond quickly to minor deviations from the project plan as well as providing information that will be used in Highlight Reports. The frequency of Checkpoint reports will vary, depending on the current level of activity. During periods of intense activity, they could be produced daily.
Managing product delivery - the purpose of this process is to make sure that deliverables are produced as specified and meet the agreed quality criteria. It requires that the work carried out by the project team is authorised and agreed, and that team members are aware of the expected cost and timescales involved. The Project Manager must be updated with progress reports at regular intervals to ensure that adequate controls are maintained.
Closing a project - closure occurs either as planned or early if the reasons for implementing the project are deemed to be no longer valid. As the project moves towards its conclusion, the Project Manager will evaluate the project against the PID and communicate his or her findings to the SRO and the Project Board in a report, to enable them to formally close the project. The SRO and the Project Board must satisfy themselves that the work is complete and in accordance with the PID, and that all of the necessary information has been passed to those responsible for the use, operation and maintenance of the deliverables. A Benefits Realisation Plan should be drawn up to facilitate a post-project review. Project management documentation will be archived for future reference, the SRO and the Project Board will confirm the closure of the project, and the project team will be disbanded.
The Benefits Realisation Plan provides the basis for a post-project review that that will evaluate project outcomes and determine to what degree the benefits have been achieved. The plan defines the anticipated benefits and identifies the benchmarks against which they will be measured. It will also identify the stakeholders who can expect to reap the benefits, and a timescale within which the benefits should be realised. The SRO accepts ownership of the Benefits Realisation Plan when the project is formally closed, and will be responsible for ensuring that it is carried out and any findings acted upon.
This article was first published on the TechnologyUK.net website in January 2009.
CPM uses a fixed time estimate for each project activity. While easy to understand and use, it does not take account of the time variations that can impact on the completion time of a complex project. The Program Evaluation and Review Technique (PERT) is a network model that allows for variations in activity completion times. In a PERT network model, each activity is represented by a line (or arc), and each milestone (i.e. the completion of an activity) is represented by a node. A simple example is shown below.
Milestones are numbered so that the end node of an activity has a higher number than the start node. Incrementing the numbers by 10 allows for additional nodes to be inserted without modifying the numbering of the entire network. The activities are labelled alphabetically, and the expected time required for each activity is also indicated. The critical path is the pathway through the project network that takes the longest to complete, and will determine the overall time required to complete the project. Bear in mind that for a complex project with many activities and task dependencies, there can be more than one critical path through the network, and that the critical path can change.
PERT planning involves the following steps:
Because the critical path determines the completion date of the project, the project can be completed earlier by allocating additional resources to the activities on the critical path. PERT also identifies activities that have slack time, and which can therefore lend resources to critical path activities. One drawback of the model is that if there is little experience in performing an activity, the activity time estimate may simply be a guess. Another more serious problem is that, because another path may become the critical path if one or more of its associated activities are delayed, PERT often tends to underestimate the to time required to complete the project.
PERT incorporates uncertainty by making it possible to schedule a project while not knowing precise details and durations of all activities. The time shown for each project activity when creating the network diagram is the time that the task is expected to take based on a range of possibilities that can be defined as:
The expected time (the time that will appear on the network diagram) is defined as the average time the task would require if it were repeated a number of times over a period of time, and can be calculated using the following formula:
expected time = (optimistic time + (4 x most likely time) + pessimistic time) / 6
The information included on the network diagram for each activity may include:
In order to determine these parameters, the project activities must have been identified and the expected duration of each calculated. The earliest start (ES) for any activity will depend on the maximum earliest finish (EF) of all predecessor activities (unless the activity is the first activity, in which case the ES is zero). The earliest finish for the activity is the earliest start plus the expected duration. The latest start (LS) for an activity will be equal to the maximum earliest finish of all predecessor activities. The latest finish (LF) is the latest start plus the expected duration. The slack in any activity is defined as the difference between the earliest finish and the latest finish, and represents the amount of time that a task could be delayed without causing a delay in subsequent tasks or the project completion date. Activities on the critical path by definition have zero slack.
A PERT chart provides a realistic estimate of the time required to complete a project, identifies the activities on the critical path, and makes dependencies (precedence relationships) visible. It can also identify the earliest and latest start and finish dates for a task, and any slack available. Resources can thus be diverted from non-critical activities to those that lie on the critical path should the need arise, in order to prevent project slippage. Variance in the project completion time can be calculated by summing the variances in the completion times of the activities in the critical path, allowing the probability of the project being completed by a certain date to be determined (this will depend on the number of activities in the critical path being great enough to allow a meaningful normal distribution to be derived).PERT charts can become unwieldy, however, if the number of tasks is too great. The accuracy of the task duration estimates will also depend on the experience and judgment of the individual or group that make them.
This article was first published on the TechnologyUK.net website in January 2009.
The critical path method (CPM) or critical path analysis is a technique developed by the DuPont Corporation in the 1950s for scheduling project tasks. It is based on graph theory (a mathematical concept), and is an important and widely used project management tool. CPM provides a graphical view of a project, predicts the time required to complete the project, and identifies the activities that are critical to maintaining the schedule, and those that are not. The project is modelled as a network, with activities shown as nodes on the network, and events that signify the beginning or end of activities depicted as lines (edges) between the nodes. A typical CPM network is illustrated below.
Steps in CPM project planning:
A delay in the critical path delays the project. In order to accelerate the project, it is necessary to reduce the total time required for the activities in the critical path. CPM is one of several activity network diagramming techniques, and provides a graphical view of the project activities, their interrelationships, and the tasks that lie on the critical path (and therefore need to be carefully monitored). CPM is ideal for projects in which there is relatively little uncertainty about project completion time or task duration. For projects of a more uncertain nature, the Project Evaluation and Review Technique (PERT) may be more suitable, since it allows a range of durations to be specified for each activity.
This article was first published on the TechnologyUK.net website in January 2009.
The Gantt chart is named after its inventor, Henry Gantt. It is a graphical way of presenting information about the activities involved in implementing a project (essentially a horizontal bar chart), and is a useful tool for scheduling and tracking progress. The horizontal (x) axis of the chart shows the timescale over which the project work is carried out, and is divided into appropriate time units (the units of time used will depend on the overall timescale for the project). The vertical (y) axis identifies the various tasks that must be carried out. Each task is represented by a horizontal bar, occupying its own row on the y-axis which is often identified with a task number at the left-hand side of the chart. The left-hand end of the bar is positioned on the x-axis in such a way that it represents the start date for the task, while the right hand end of the bar represents the finish date. The length of the bar therefore represents the duration of the task by definition. Task dependencies may also be indicated using an arrow that links the end of one task to the beginning of the next. Gantt charts can be created and updated relatively easily using project management software like Microsoft's MS Project, and can even be created using spreadsheet packages like MS Excel.
One of the fundamental principles of project scheduling is to be able to identify which tasks can be carried out independently of other tasks, and which tasks can only commence on completion of some other task (i.e. they can be said to have a task dependency). The Gantt chart makes it relatively easy to identify those tasks that have a task dependency, and which tasks they are dependent upon. If one task begins before the completion of another, the bars will overlap, and it is quite possible that two or more tasks may be performed in parallel. Larger projects may employ a series of Gantt charts if the complexity of the project is such that a single chart cannot provide the required level of detail. In some implementations of the Gantt chart, the work achieved for each task can be shown by shading part of the bar to represent the work that has been completed, so that the status of each activity can be seen a glance. To demonstrate how the Gantt chart works we can construct an example using some imaginary project tasks. Consider the information in the following table.
| Task No. | Duration (days) | Task dependency |
|---|---|---|
| 01 | 3 | N/A |
| 02 | 2 | N/A |
| 03 | 1 | N/A |
| 04 | 11 | 02, 03 |
| 05 | 11 | 02, 03 |
| 06 | 15 | 02, 03 |
| 07 | 1 | 02, 03 |
| 08 | 11 | 07 |
| 09 | 6 | 07 |
| 10 | 6 | 07 |
| 11 | 5 | 08, 09, 10 |
| 12 | 5 | 04, 05, 06, 11 |
| 13 | 4 | 02 |
| 14 | 5 | 12 |
| 15 | 4 | 12 |
| 16 | 4 | 13, 14, 15 |
The screen shots below show how this information is entered into the GanttProject software package, which can be used to produce a Gantt chart. Its creators describe it as: "a cross-platform desktop tool for project scheduling and management . . . [that] runs on Windows, Linux and MacOSX, it is free and its code is opensource". GanttProject is indeed a free software package, and can be downloaded from:
http://www.ganttproject.biz/download
This article was first published on the TechnologyUK.net website in January 2009.
A project network (or project activity network) is a graphical depiction (very similar to a flow chart) that shows the sequence in which the project's terminal elements must be completed. Each terminal element represents an activity that relates to a work package at the lowest level of the work breakdown structure (WBS). However, whereas the WBS does not attempt to identify the sequence of events or the duration of any activity, the project network seeks to identify the sequence in which activities occur and the other activities (if any) on which a particular activity depends. There are a number of techniques used to create a project activity network. Some of the more commonly used techniques include Gantt charts, Critical Path Management (CPM) and the Project Evaluation and Review Technique (PERT). In some techniques, each terminal element (or activity) is represented by a node on a graph, while in others it is represented by an edge (the line connecting two nodes). Each terminal element should lie on only one path through the network. An example of a project activity network diagram is illustrated below.
An activity network diagram helps you to determine the most logical sequence of events for a project, and provides the basis of a realistic project schedule. It will enable you to calculate the total amount of time required for the project, define the order in which tasks must be carried out, and highlight those tasks that are critical to the project schedule. When the WBS has been completed you will have a list of activities at various levels of decomposition that must be completed in order to achieve the project’s objectives. You can now determine the task dependencies and the duration of each task to allow a schedule to be produced. Project management software is now available that will carry out the scheduling for you, calculate the overall time required for completing the project, and identify the schedule's critical path. All you have to do is to enter the duration of each task and identify any task dependencies. The software will produce network activity charts and Gantt charts based on the information that you provide.
Although project management software is readily available these days it is useful to understand the process by which an activity network diagram is created. The following steps can be used to carry out the process manually:
The critical path tells you how long it will take to complete the entire project (based on current information). The tasks on the critical path, therefore, must be monitored more closely than those tasks not on the critical path, because any delays in one of these tasks will cause the critical path to increase in length (in other words, the time required to complete the project will increase). One way of reducing the overall duration of the project, of course, is to speed up the execution of one or more tasks on the critical path – assuming this is possible. For other paths through the network, each task will have some slack in the sense that it may be delayed – up to a point – because it is not on the critical path. Bear in mind however that should one or more tasks on other paths become significantly delayed, the path affected may acquire an overall duration that exceeds that of the critical path. It will therefore by definition become the new critical path.
Gantt charts, PERT and CPM are all useful techniques that provide information about project schedules in a graphical way, but they do not tell you everything. They do not tell you, for example, what resources are required for a particular task. Activity network diagrams are snapshots of the status of a project at a particular time. It will be necessary to update them as circumstances change. If a task is taking longer than expected, it may have an impact on the overall project schedule. The same is true for tasks that are completed ahead of schedule. The impact on resources will not be apparent from looking at the network diagram alone, and other tools and techniques must be used to determine where the peaks and troughs will arise in terms of the demand for critical project resources.
This article was first published on the TechnologyUK.net website in January 2009.
Once you have defined the scope of the project, you can start looking at the individual tasks that must be accomplished in order to complete the project. The Work Breakdown Structure (WBS) is a diagrammatic approach to defining the work to be undertaken by breaking the project down into a number of tasks and sub-tasks in a hierarchical fashion. The resulting tree structure can be used as a framework for estimating costs and developing a work schedule. The work is decomposed into successively smaller logical units, until it becomes impractical to break the work down any further. Each "work package" produced as a result of this process will be accompanied by a description of the activity to be undertaken and the specific deliverable to be produced as a result of that activity. The work package should provide the basis for a realistic estimation of the time and cost involved in carrying out the work, and should result in a specific and measurable deliverable. An example WBS diagram is shown below.
The WBS should include 100% of the work required to achieve the projects agreed objectives - no more, and no less. It follows that, for each high-level component in the diagram, the sum of the work embodied in each of the element's sub-tasks (or children) should represent exactly 100% of the work required to complete the high-level component. At each level within the hierarchy, component tasks are numbered, usually from left to right on the diagram (e.g. 1, 2, 3 . . . etc.). Child elements are also numbered in a manner that identifies their relationship to a particular parent element (e.g. 1.1, 1.2, 1.3 . . . and so on). If a particular life cycle model has been used for the project, the high-level tasks identified by the WBS often reflect the phases of the life cycle (e.g. analysis, design, implementation etc.). It is important to decompose the work to an appropriate level of detail. Too little detail and there is a possibility that some important aspects will be missed. Too much detail and the result could be the micro-management of activities that serves only to hamper the work.
The work breakdown structure can be seen as a checklist of the activities that must be undertaken in order to achieve the objectives defined in the scope document. The WBS will in turn form the basis for the detailed project plan. The work packages defined by the WBS provide a basis for assigning tasks to workgroups or individuals, allocating resources, and monitoring project activity. High-level tasks tend to be allocated to workgroups, whereas the work packages that comprise the high-level tasks are often assigned to an individual project team member, since they are generally far narrower in scope and can be carried out within a relatively short timescale. Not that while the WBS groups activities that are closely related to each other, it does not attempt to impose a timeline on those activities or specify the duration of each task. Nor does it attempt to identify any task dependencies that might exist between the tasks. These details will be determined by the project schedulers, and will eventually form part of the project plan. The real purpose of the WBS is to identify a complete range of measurable deliverables for the project, rather than to try and impose a sequence of events.
In some industries, a minor variation on the WBS, called a Product Breakdown Structure (PBS), is used to decompose a complex product in terms of the systems, subsystems and components that together make up the product (for example, the engine management system or braking system of a motor vehicle). Just as the WBS decomposes a project into a number of discrete low-level activities (work packages), the PBS is a hierarchical structure that decomposes a complex product such as an aircraft or an item of heavy machinery into its constituent assemblies, sub-assemblies and components. As with the WBS, the lowest level of the PBS should consist of components that cannot realistically be decomposed any further, and should follow the same 100% rule whereby every single component required to build the top-level product under consideration is included.
This article was first published on the TechnologyUK.net website in January 2009.
Once the project enters the implementation phase, the project manager's primary role is to monitor the progress of the project on an ongoing basis to ensure that work proceeds according to the project schedule and that expenditure is maintained within the project budget. He or she will also be required to report project status to senior management on a regular basis, and will liaise with other project stakeholders including the project client, suppliers, and sub-contractors. Other tasks with which the project manager will be closely involved include:
Part of the project manager's job involves dealing with the human aspects of project management. They will need to motivate the project team, give them a sense of purpose, and resolve conflicts between team members. The human side of project management involves leadership, as opposed to the purely administrative, technical and functional aspects of the job. As a leader, the project manager must be able to motivate people to perform to the best of their ability and gain their commitment to the project. At the same time he or she must be a good listener, provide encouragement and support when things are not going well, and attempt to remove or minimise barriers to progress. An effective leader should know when to delegate responsibility for carrying out tasks, and when to step in to shoulder some of the burden. The broad spectrum of people with whom the project manager must interact, both within and outside of their own organisation, calls for excellent communication and interpersonal skills, as well as the technical skills required to manage and monitor the project.
The "hard" skills required by project managers involve knowledge of and competence in a variety of project management techniques, many of which involve estimation and measurement and the preparation of reports and documentation. Thankfully, there are a number of project management software packages available today that make the performance of these tasks relatively painless. The effectiveness of such tools does of course depend upon the skill of the user, and the accuracy of the input data. It almost goes without saying that the project manager should be familiar with standard project management tools and techniques, and should be competent in the use of the chosen project management software. Depending on the nature of the project, he or she will also be expected to be familiar with relevant aspects of the business environment within which the project is executed, and where the project's deliverables will be used.
Many of the attributes commonly found in a good project manager are gained only by experience. The ability to develop and maintain an overview of the project as a whole, for example, without getting too bogged down in the day-to-day detail. At the same time, it is important to be aware of what is going on with each project team member, and to understand the work being undertaken in sufficient detail to be able to address issues as they arise. Decisions often have to be made without all of the information pertaining to a particular situation being available, so good judgement is also vital. The decisions made may not always be perfect, or even the right ones, but they should always be justified by sound reasoning. The project manager will be accountable for their decisions, and will have to explain their actions to senior management and other stakeholders when things do not go as planned. A reputation for being fair and having integrity is also an important attribute, particularly when dealing with project team members. People are more likely to go the extra mile for a team leader they can trust, and who has demonstrated that they will "do the right thing", even when this does not always endear them to senior management.
One commonly encountered problem for project managers is that the degree of responsibility that usually goes with the position is not always matched by a commensurate level of authority. Formal authority is vested in the title "Project Manager", but the precise definition of that authority may vary widely from one organisation to the next (or even from one project to the next). It implies that the project team members report to the project manager directly in the first instance, and are accountable to him or her for their actions. This authority sometimes, though by no means always, includes the power to hire and fire people as and when required. In the long term it may extend to the ability to influence the career prospects and remuneration of individual team members. In many cases however, such matters will be the prerogative of each team member's functional manager. Authority to set or amend the budget and allocate funds is another area where the project manager may or may not be empowered. The extent to which the project manager controls the purse strings is often a reflection of the extent to which they control the project overall, and the authority to award financial incentives to productive team members can be exploited to good effect.
Informal authority can be exercised by virtue of the project manager's demonstrable knowledge, expertise and experience. A number of other factors can also contribute to informal authority, such as social connections (otherwise known as having friends in high places), personal charisma, or simply having a personal code of conduct that is above reproach. The authority vested in the project manager, howsoever gained, should be directed towards achieving the objectives of the project. If authority is used in any other way (for example to pursue some private hidden agenda or fulfil a personal need to exercise control over others), then the overall effect on the project is likely to be negative rather than positive. That is not to say that "office politics" can be entirely avoided, but it should certainly not be allowed to cloud one's judgement.
Good negotiating skills are a huge plus for the project manager. Skilful negotiation involves knowing how much to ask for, and how much to concede when necessary, as well as an astute sense of timing. Sometimes, the timing of a request to senior management for more resources is as important as the arguments presented to justify the request (e.g. when they have just captured a major contract, or recorded an increase in profits). It often requires the use of certain other useful personal characteristics, like intuition and the ability to weigh up exactly how strong your negotiating position is. A rule of thumb when negotiating is to ask for more than you actually need and offer less than you are actually willing to concede. This will give you a margin within which to negotiate – but don't get carried away. Perhaps most importantly, a successful negotiation should leave both sides feeling as though they have achieved at least some gains. An alternative to negotiation is coercion, in which the objectives are gained simply by pulling rank or using some other form of leverage to get what you want. Be aware, however, that coercion should only be used where absolutely necessary, and when all other strategies have failed to yield results. It will not gain you many friends, and may have unforeseen (and unfavourable) repercussions at some future date.
One of the problems faced by project managers is the imposition of targets by senior management that are not based on realistic estimates, but are based instead on unrealistic expectations of what should be achievable. This creates problems when it comes to planning, particularly with regard to the project schedule. The project budget will also be affected, since the man hours required to complete the project will inevitably be underestimated if an unrealistic project deadline is set. Even assuming the project manager is not saddled with unrealistic targets, there is often a tendency for senior management to expect a high degree of accuracy in the estimation of project deadlines and budgets that is simply not achievable, given the complexity and uncertain nature of most projects. The prudent course of action when asked for estimates is to provide a realistic range of values that reflects the degree of uncertainty involved. While management will probably be less than happy with what they may perceive to be a deliberately vague forecast, predicting a range of possible outcomes is better than committing yourself to a very specific and perhaps overly optimistic forecast.
This article was first published on the TechnologyUK.net website in January 2009.
Project success is often based on choosing the right people for the project team and obtaining the necessary level of commitment from them. The work breakdown structure can be used to identify the work to be done, after which you will have a reasonable idea of the work activities that need to be carried out, the number of staff needed to undertake the work, and the specialist skills and knowledge required. Assuming you have a choice, choose the best people available. This does not simply mean that you are looking for people with the required skills and expertise. You should also be looking for people with a good track record for getting the job done, and who are known to work well as part of a team. Your ideal candidates will also be prepared to work to a tight schedule when the need arises, and not be afraid of putting in some overtime if necessary. Depending on the organisational structure within which you will be working, you may have to recruit staff from a number of functional areas, and may well be involved in negotiations with functional managers concerning the allocation of staff to the project. In a worst case scenario, you may have a team imposed upon you.
In most cases, the staff required for the project will be available in-house. If there is a skills gap, you may need to consider either providing existing staff with the requisite training or recruiting additional staff with the requisite skills. The team should ideally be composed of individuals that can work well together from the outset, although this is rarely possible to judge in advance, especially if they come from a number of different departments and have not worked together before. Try if possible to keep the size of the team reasonably small (no more than a dozen people, ideally). The larger the team is, the more difficult it is to keep track of what each individual is doing, and the channels of communication between team members increase in number and complexity. If the project team is selected by senior management on the basis of availability rather than suitability for the role, you will simply have to do the best you can with the personnel available. There is a chance that no-one else will be particularly happy with the choices made either, including the individuals concerned and their departmental managers.
Whatever the circumstances, the team should become committed to the project and motivated to work with the project manager and each other to achieve the objectives of the project. This may involve giving individual team members ownership of their own part of the project. It will certainly involve making sure that everyone clearly understands the project's goals, and the impact that the project will have on the organisation as a whole. Each individual within the team should develop a sense that what is being accomplished is both necessary and worthwhile. Bear in mind also that the achievement of project milestones will often depend on the willingness of project team members to pull out all the stops from time to time in order to get the work done on time. It is therefore vital to involve the people responsible for carrying out a particular task in the planning process, rather than simply impose an arbitrary deadline upon them.
In order for a group of people to develop into a team, it is important to provide somewhere that the team can regard as its base of operations. Assuming that the project team are all based in one geographical location most of the time, this implies a physical space in which the team will work, or at least gather frequently to exchange information and ideas, hold meetings, or chat. The home environment should provide adequate space, and the amenities required to ensure that it is a pleasant area in which to work. The team should also be provided with the necessary technological support to enable them to function efficiently. The facilities needed will probably include personal computers, notebook computers or PDAs with appropriate software installed. In a modern business environment, access to the Internet, e-mail and a shared network file space are pretty much essential too, as is a telephone. The ability to communicate and share information in a timely fashion is essential, especially if project team members are located in different places or frequently on the move.
One of the most widely cited models of team development and behaviour is still that formulated by Bruce Tuckman 1965. The original model involves four stages, and explains how relationships within the team, and between the team and the team leader, change and mature. The four stages of the original Tuckman model are briefly described below.
Unfortunately, many project teams never reach the performing stage and will require a certain amount of guidance. The management of human resources will often figure prominently among the project manager's duties, particularly if there is a significant turnover in project staff. Team members may leave the organisation to take up a more favourable post with another company, be recalled to their normal duties by their functional manager, or simply be unavailable due to illness or for some other reason. Finding a replacement for a team member will become more difficult as the project progresses, simply because there will be less time available to integrate a new team member and because the work undertaken to date will be at a more advanced stage, and will therefore take more time to assimilate. This can have a negative impact on the project overall, especially if the individual leaving the team performs a critical role. In extreme cases, the project schedule and budget may be affected significantly, and may have to be renegotiated with the project client.
Another problem faced by project managers is that of one or more team members under-performing. This is more likely to occur where the selection of the project team has been arbitrarily made by senior management, with little or no input from the project manager. In some cases the problem can be turned around, especially if the problem is discovered early in the lifetime of the project, by the provision of appropriate training or mentoring. Alternatives include re-assigning the individual concerned to a task more appropriate to their skills, or replacing them with someone more capable. If none of these options are practical, the only other course of action available is to attempt to minimise the negative impact on the project by working around the team member concerned as far as is possible.
One of the oldest dilemmas faced by project managers is that of if and when to bring in extra help when a project runs into difficulties such as falling behind schedule. Usually, there is a law of diminishing returns that comes into effect when allocating additional manpower to a project. This law can be quantified in various ways, but essentially it states that whereas adding a small number of additional staff may bring dividends in terms of bringing a project back on track, adding too many people to the mix will actually slow things down even further as the logistics of coordinating the efforts of all the additional personnel becomes unwieldy and inefficient. The same kind of problem occurs when considering whether or not to incur overtime. Whilst it may be necessary on occasion, it is really only effective when used as a short-term remedy. There is a real danger that overtime working can become the norm, especially where it is seen as a way of supplementing income. For salaried staff this is not an issue, but they should still be assured that putting in all the hours under the sun is the exception and not the rule. Otherwise, even the most dedicated and loyal team member may start to feel that their efforts are being taken for granted. It is also imperative to acknowledge the efforts of staff who have "gone the extra Mile".
Work carried out by Dr. Meredith Belbin over a period of nine years at Henly Management College has identified a number of team roles (a summary of Belbin's team roles is given in the table below). Belbin defines a role as:
"A tendency to behave, contribute and interrelate with others in a particular way."
| Category | Role | Description |
|---|---|---|
| Action oriented: | Implementer | An implementer can take other people's ideas and put them into practice. They tend to be well organised, self-disciplined, efficient, and loyal to the team. On the down side, they can be resistant to change may be seen as too conservative. |
| Shaper | Shapers are energetic and dynamic extroverts who 'shape' the team by encouraging others to improve, and by urging the team onwards. They are good at finding solutions to problems (which they see as challenges) and encourage others to consider all possible approaches. On the negative side, they can be argumentative and insensitive to the feelings of others. Having more than one shaper in a group can lead to conflict. | |
| Completer-finisher | The completer-finisher tends to be a perfectionist who pays attention to detail and who will go out of their way to ensure that work is done thoroughly, accurately, and on time. Their weaknesses include a tendency to worry too much about details and a reluctance to delegate tasks to others. | |
| People oriented: | Coordinator | The coordinator is an effective leader who can see the ‘big picture' and help others to focus on a task. They tend to be confident and mature, and have an ability to recognise strengths and weaknesses in others. This ability allows them to select the right person for a particular job, and they are happy to delegate work. On the down side, they are sometimes perceived as manipulative, and may delegate too much of the work. |
| Team worker | Team workers use their negotiating skills and a natural flair for diplomacy to settle disputes and get people to work together. Team workers are good listeners and tend to be popular. Although very capable in their own right, they put the interests of the team as a whole ahead of their own. Weaknesses include a tendency to be indecisive due to their reluctance to take sides. | |
| Resource investigator | The resource investigator is often an extrovert and is focused on people and opportunities outside the team. They are good at exploring available options and negotiating for resources. They bring enthusiasm to the team process and like to work with external stakeholders to ensure that the team achieves a successful outcome. On the negative side, they can run out of steam in the closing stages of a project and have a tendency to overlook details. | |
| Thought oriented: | Plant | Despite a tendency to be introverted and work alone, the plant is creative, can generate new ideas and approaches, and is good at solving difficult problems. Weaknesses include poor communication skills, an aversion to criticism, and a tendency to ignore details. |
| Monitor-evaluator | Monitor-evaluators have an ability to see things objectively and take all relevant factors into account before making a decision. Their chief strength lies in being able to analyse and evaluate the ideas generated by others and come to an informed (and usually correct) decision. Their detached and unemotional nature is also their weakness, as they are not particularly good at motivating others and can sometimes be over-critical. | |
| Specialist | The specialist is an expert in (and usually very passionate about) his or her particular discipline, and can be relied upon to solve problems related to it. Although very good at what they do, their contribution to the team is likely to be very narrowly focused, and they will be uninterested in other aspects of the project. |
It can be seen from the above that each of Belbin's team roles has certain strengths and weaknesses. Most people do not fall neatly into one of the team roles described here, but tend instead to exhibit characteristics found in three or four of them. At any given time in their career however, and within a particular setting, most people tend to lean towards one particular team role. This is said to be their primary role. A successful team tends to consist of a mix of team roles, where each team member is aware of their primary role within the team, can work to their strengths, and is able to manage their weaknesses. Belbin suggests that a team is more likely to achieve a successful outcome if it consists of a balanced mix of team roles. The implications are that a prevalence of any one weakness amongst the team members (for example, a reluctance to make difficult decisions) could result in a manifestation of that weakness in the team as a whole. On the other hand, the predominance of a particular strength could also be counter-productive. We have already mentioned, for example, the fact that having more than one shaper in the team can lead to conflict. The list below can be used as a guide to putting together a balanced team.
Use the model as a guide to assess whether or not you have a balanced team, but bear in mind that there are other models and theories that are arguably just as valid. Any findings you come up with should be viewed with a critical eye. You should apply common sense and judgement to your own particular situation and not rely too heavily on theoretical models. If you would like to know more about the work of Dr. Meredith Belbin, the following link is a good starting point.
This article was first published on the TechnologyUK.net website in January 2009.
Organisations of any size have a structure that reflects the kind of business activities in which the organisation is involved, and the way in which the various groups within the organisation relate to each other. The interrelationships and the roles played by each group or individual within the organisational structure are usually documented in an organisational chart. The organisational structure is important to a project in that it forms part of the wider environment within which the project team will function, and will to a large extent influence the way in which the project team will interact with the organisation. Organisational structures tend to be categorised in a number of ways. We will be looking at three examples here, starting with the functional organisation.
The functional organisation has a more or less traditional structure based on organising people and resources according to functional areas. People and groups within a specific functional area carry out similar tasks and share common skills and knowledge. Projects that are carried out within a functional organisation tend to be oriented towards a particular functional area, will often be managed by a senior manager within that functional area, and will have a project team consisting mainly of personnel from that functional area. Where projects involve a number of different functional areas, the question arises as to who will have overall responsibility for the project, and how project resources and personnel will be allocated.
The benefits to projects of operating within the environment of a functional organisation include the availability of staff with specialist knowledge in a number of areas, while at the same time being able to focus the main efforts of the project towards a single functional area. It is also an opportunity for staff from different functional areas to collaborate on work that they would otherwise not be involved in, and to take back what they have learned to their own areas. The down side is that there is often a conflict of interest between the responsibilities a team member has towards the project and their normal duties, particularly if they are expected to carry out their normal duties whilst on secondment to the project team.
There may also be issues when it comes to selecting a project manager, particularly if the project directly involves two functional areas that are major stakeholders. If the project involves creating a new information system for the human resources department, for example, both IT and HR will have a major input into the project. Will the chosen project manager therefore be a senior manager from IT who understands the requirements from an IT point of view, or one from HR who understands the functional requirements of his own area far better? The solution to the problem may lie in ensuring that wherever potential conflicts may arise, the project priorities are unambiguously determined in advance. Even so, arbitration may be required from time to time to enable conflict of interest to be resolved.
Some organisations, particularly those whose business involves contract work, organise themselves around ongoing projects, of which there could be any number ongoing at any given time. Each project is managed more or less independently as a separate business unit within the organisation. The project manager is responsible for managing the project work and allocating resources, while overall financial control resides with the program manager. Usually, both the project manager and the project team are committed to the project on a full time basis. This eliminates the kind of conflict of interest that can arise in functional organisations, since the project manager will have a clear and unambiguous mandate, and the project team will be fully committed to the project. Lines of communication tend to be shorter resulting in more effective communication, and there are no competing demands for dedicated project resources.
Disadvantages to this approach include the fact that some functional areas are duplicated across multiple projects, while project team members have fewer opportunities to share experiences and good practice with members of other project teams. Some flexibility in allocating personnel and resources is also lost, with personnel in specialised roles being assigned to one project team for the duration of the project even though there may be phases during which their services are not actually required, potentially increasing individual project costs. Project managers are often reluctant to release specialists to work on other projects, preferring instead to retain their services and forego potential savings.
Some organisations adopt a matrix structure that combines features of both the vertically aligned functional structure and the more horizontally aligned project structure. The matrix structure can provides the benefits of both the functional and project structures, but may also exhibit many of the problems inherent in both types of organisation. It can however allow a more integrated approach to the allocation of staff and other resources, and staff with specialised skills can be assigned to a project either permanently or as the need arises. A major weakness is that each project team member will have more than one line manager raising the possibility of conflicts of interest and divided loyalties. There is a clearer division of managerial responsibilities in the sense that, while functional managers will be responsible for providing staff and other resources for the various projects, the project manager will have sole responsibility for coordinating staff and resources within a project. The diagram below shows the organisational structure for a matrix organisation. The highlighted boxes represent the staffing resources for a single project.
The matrix structure allows skilled staff and other resources to be shared by all projects. It is also quite possible for a member of staff in a particular functional area to be assigned to more than one project, resulting in more efficient use of specialist resources. The highly integrated approach can also improve communications, facilitating the flow of information and speeding up both the resolution of problems and the decision making process. There will however need to be a high level of cooperation between project managers and functional managers in order to avoid or at least resolve conflicts. If conflicts cannot be avoided or resolved, a project may become bogged down due to failure to provide the project team with clear leadership. The matrix organisation really comes into its own where the nature of the projects undertaken by the organisation tends to be cross-functional.
Project stakeholders are individuals, groups, or organisations that have an effect upon, or that are affected by, the project. A stakeholder is generally identified as someone who has an interest in whether or not the project has a successful outcome. The process of identifying stakeholders is both necessary and enlightening, and will throw up some obvious and some not so obvious candidates. The following list, though not exhaustive, includes most of the usual suspects.
This article was first published on the TechnologyUK.net website in January 2009.
Project termination (or close-out) is the last stage of managing the project, and occurs after the implementation phase has ended. Acceptance testing has been carried out, and the project deliverables have been handed over to the client. The project team has been disbanded and unused resources have been disposed of as appropriate. All outstanding bills have been passed for payment, and the final invoices for work carried out have been issued. The main purpose of the close-out stage is to evaluate how well you performed, and to learn lessons for the future. A final project status report is prepared that should contain a summary of changes to the project scope (if any), and show how actual completion dates for project milestones and costs accrued compare with the final version of the project schedule and budget. All significant variances from the project baseline should be explained here. A review is then undertaken with the client and other project stakeholders, during which the project outcomes are evaluated against the project's stated aims and objectives. The results of the review are recorded in a close-out report. The questions the stakeholders should be asked will vary depending on the nature of the project, but will normally include questions such as:
Projects fail for many reasons, some of which are outside the control of the project manager. External factors that can affect the outcome include a changing commercial environment, lack of support from senior management (including the provision of adequate resources), or lack of co-operation from the project client. Internal factors include inadequate expertise within the project team, a lack of planning and management, poorly defined project objectives, and a failure to communicate effectively. However, despite the fact that a project may not have fulfilled the expectations of its stakeholders, future projects can benefit from the lessons learned from a post-project appraisal process. It is important to learn lessons from successful aspects of the project as well as from mistakes. In that way, not only can the same mistakes be avoided in future, but good practice can be implemented in future projects.
The close-out report will be the final report for the project. It will include an executive summary, the final status report, and an analysis of lessons learned that includes recommendations for improvements to be implemented in the handling of future projects. The close-out report will be made available to future project managers so that the lessons learned and the recommendations that are derived from them can be utilised. The project documentation itself will also be archived for future reference, and if it contains accurate information that has been kept up to date throughout the project it will provide a valuable source of historical data. When evaluating problems that have occurred, it is important to identify the root cause of the problem and come up with strategies for ensuring that it does not occur in future. The avoidance of certain types of problem cannot always be guaranteed (changes in scope will often occur, for example, but they can rarely be predicted). Even so, it may be possible to identify a means of detecting problems earlier in the project management process so that the negative consequences can be minimised.
The importance of the availability of up to date, complete and accurate project data to the close-out process cannot be overstated. The analysis of problems and the derivation of solutions to those problems (as well as the ability to recognise and document good practice) will only be meaningful if based on a full and accurate record of what occurred during the course of the project. The memories that individual project team members and other stakeholders have of events that occurred will be distorted by time and personal bias, and therefore cannot be relied upon. It is also to some extent unfair to ask project team members to submit statements that appear critical of colleagues, or show themselves in a bad light, particularly if such statements would be made in the context of a project team de-briefing and could possibly cause some embarrassment. The idea is to highlight problems and suggest solutions, rather than to apportion blame. The project manager may well be called upon to assess and report upon the performance of individual project team members, but this assessment will usually take the form of a confidential written report that is seen only by the line manager of the individual concerned.
If the project has been a success, there will be cause for some kind of celebration. This could take many forms, but represents an opportunity to thank the project team for a job well done, and to offer then a sense of closure. Even if the project has not been a complete success, it is important to thank the members of the project team for their efforts, since they have no doubt all worked hard. Where performance merits it, either the team as a whole or individual team members should be rewarded accordingly. Appreciation for a job well done may take the form of a financial reward or something less tangible. Sometimes, for some people, a sense of being truly appreciated is just as important as money. Recognition of a valuable contribution made is often sufficient incentive to ensure that an individual’s future performance will be just as good as before, if not better.
This article was first published on the TechnologyUK.net website in January 2009.
Change occurs whether we want it to or not. It is an inevitable part of life. In terms of managing a project we try to discourage it, but sooner or later we have to face the fact that changes have occurred or are about to occur. We therefore need a change management process to ensure that when changes do occur, they can be assimilated into the project baseline and will not cause the project to fail. Changes to the project baseline are not the only kind of change we should be concerned with, however. The project itself will bring changes to the organisation for which it is being commissioned. Hopefully these will be positive changes in the sense that it will provide long term benefits such as making the organisation more productive. Keep in mind, however, that organisational change is not always welcome. One of the tasks the project team should be prepared to embrace is that of persuading users of the positive aspects of the changes involved. Change can create anxiety, and may generate resistance if the ground is not carefully prepared in advance to ensure that the new product or system is not only a technical success but is accepted by users.
The kinds of changes that will have the most profound effect on the project baseline are changes to the project's scope, i.e. the set of deliverables that represent the end product or service to be produced. The client may decide, for example, that they require additional features or functionality. This can often occur as the client becomes more familiar with technical aspects of the project and becomes aware of new possibilities. Sometimes it is driven by project team members, who may have discovered a better way of carrying out a particular task or wish to implement design changes. If the project is taking place over an extended period of time, technological advances or improved equipment or materials can also provide an incentive to change some of the project parameters. Other drivers can include changes in the business environment or key personnel.
Baseline changes are not always client-driven or even directly related to scope. They may be the result of a range of external factors that impact on the client’s business, or internal factors that affect the project team. The client may find, for example, that their cash flow situation has been compromised due to unforeseen expenditure elsewhere. This can lead to a downsizing of the project’s objectives (and by definition a reduced project scope) or perhaps delays in completing the project (work may be shelved until the cash flow situation has improved). Legislative and regulatory changes may also force the client to review project specifications, and may necessitate changes. Other external factors that can affect the project and may induce changes include significant shifts in the economic, political or social environment. Internal factors for change include technical difficulties that may be encountered in meeting the project objectives. These could be caused by a lack of suitably skilled personnel, the unavailability of vital materials or equipment, or simply a failure on the part of project team members to perform as expected. Significant budget overruns (spending more money that you planned to) may also force changes to the baseline.
Obviously, some kind of change control mechanism is necessary to ensure that change occurs in a controlled manner, that the changes are documented, and that the project baseline is adjusted to reflect the changes made. A formal procedure must be established for requesting a change, and any changes requested must be evaluated in terms of their impact on the project baseline. The exact procedures will vary from one organisation to another, but usually involve the individual or workgroup wishing to implement a change submitting a change request form. Depending on the nature of the change, the project manager may need to be informed of the change and his or her approval sought before the change can be integrated into the project plan. This will normally only be necessary if the magnitude of the change will significantly affect the project baseline. Generally speaking, changes should only be authorised by project personnel with the requisite decision-making powers.
A typical change request form is illustrated below. The information requested includes the name of the person requesting the change, the date on which the change was requested, a description of the change, and a justification for the change. In the example shown, the requestor may also assign a priority to the change request and comment on the impact of not making the requested change. Once the change request form has been submitted, the impact analysis section will be completed by designated members of the project team, who will evaluate the effect of the change on the project's scope, resource allocation, budget and schedule. If necessary, a risk assessment will be carried out and the risk management plan will be amended accordingly. The change request resolution section of the change request form records the decision reached (i.e. whether or not the change is approved), the reasons for the decision, and the identity of the person responsible for the decision.
When the change request form is first submitted it is assigned a change request number, and the details of the request are entered into a change log. The log will be updated with the relevant information once a decision has been made as to whether to implement the change or not. The information recorded in the log includes the change request number, the name of the requestor, the date on which the change was requested, brief details of the changes required, and the outcome of the request. If the change is approved, the task of implementing the change is assigned to appropriate personnel.
This article was first published on the TechnologyUK.net website in January 2009.
Projects are by nature risky undertakings. The very fact that they are generally both time constrained and resource constrained means that there is little margin for error when planning a project. Unforeseen events can result in time lost or a drain on resources, either of which could be detrimental to planned outcomes. The complexity of the project itself presents us with a large number of variables to consider, many of which are unknown quantities at the outset and can at best only be estimated.
It is unlikely that we will be able to eliminate either the project constraints or the element of uncertainty. The only realistic course of action when considering potential risks is to try to anticipate what might happen and either reduce the chances of a risk occurring or formulate a plan to deal with it if and when it does occur. A proactive approach to risk management will increase your chances of completing the project on time and achieving all of the project's objectives.
The first step in any risk management process is to identify potential risks. This can be done in a number of ways. One method is to ask each project team member to write down ten possible risks. The results should be used to derive a master list, with any duplicates removed. Depending on how long the final list is, it may be necessary to shorten it to include only those risks that would have a significant impact or a reasonable probability of occurring.
Once you have a definitive list, you can carry out a risk assessment of each item on the list to determine its risk characteristics in more detail. The risk assessment looks at two things. The first is the probability of the risk occurring, and the second is the impact that it could have on the project. These factors can then be assessed using a risk matrix like the one shown below.
Both the impact of the risk and the probability of the risk occurring need to be assessed (in the example above, each factor is given a value on a scale of one to four). The risk matrix is then used to assign a level of priority to the risk. Note that if the probability is high but the impact is low, the risk is classed as having a medium priority level. If the probability is low but the impact is high, then the risk is assigned a high priority. This is an attempt to reflect the fact that a remote chance of a major problem is worthy of more consideration than a good chance of a minor inconvenience.
Once the priority level of each risk has been established, the next step is to determine a strategy to either minimise the likelihood of the risk occurring (risk avoidance), or to deal with the risk in an optimal way if it does occur (risk mitigation).
Risk avoidance is not always possible but could include simple measures such as finding an alternative supplier for critical materials in order to eliminate (as far as possible) the risk of not being able to get hold of the required materials because your original supplier has let you down. In an extreme case, it could even mean cancelling a project if all the indicators point to it being doomed to failure.
Risk mitigation usually means having a fallback plan that can be implemented should the risk occur, in order to reduce its negative impact on the project. This could entail modifying one or more of the project objectives to get around a shortfall in time or resources, or simply re-scheduling work to accommodate changes in personnel or unforeseen delays.
In some cases the decision may be to take no further action, if the impact to the project is likely to be minimal. Whatever strategy is devised for dealing with a risk, monitoring the status of the risk and carrying out the necessary actions should it occur will be the responsibility of the risk owner (the person assigned to manage the risk). In most cases this will be the project manager, although a risk could be assigned to any project team member.
We have talked about the need to identify and assess the risks that may affect a project, and to formulate a strategy to deal with each risk identified. The final element required for the effective management of risk is to put in place a system for monitoring the status of each risk identified throughout the project's implementation phase.
Each risk, the result of its risk assessment, and the actions to be taken in response to an occurrence of the risk, must be recorded as part of the risk management plan. The risk owner is tasked with reviewing the risk at frequent and regular intervals during implementation. The risk owner should ensure that he or she can recognise the warning signs that might signal an imminent occurrence of the risk, so that they can initiate a response in good time.
This article was first published on the TechnologyUK.net website in January 2009.
A project is invariably undertaken in order to further the aims of a business or organisation. The processes that occur within the project are therefore taking place, not in isolation, but within a wider business environment.
The project team members who carry out the various tasks involved must interact with a range of stakeholders who are not directly tasked with project activities, and who have their own concerns and agendas. For this reason, the criteria for project success or failure cannot be defined simply in terms of how well or how badly a project is managed and executed, or even whether or not an agreed set of deliverable is produced on time or not.
The commitment of the project team must be matched by a commitment by the client and end users in order to achieve a successful outcome. Such a commitment can only be achieved if the processes involved are well understood by the key stakeholders, which in turn is dependent on maintaining the flow of timely and accurate information. Some of the factors that contribute to project failure are listed below (although the list is not exhaustive).
The characteristics of a successful project therefore include a well-defined and well-understood set of requirements, realistic scheduling, effective channels of communication and clear reporting procedures, formal change management procedures, good leadership, and sound management of personnel and resources.
Successful projects tend to occur within an organisational culture that is willing and able to investigate and deal with problems, where the vision behind the project is shared by all of the stakeholders, and where the project manager demonstrates effective communication skills when dealing with clients and project team members. Indeed, where project leadership is concerned, communication skills take far greater precedence than technical knowledge.
When considering the criteria for success, it is easy to reduce the matter to a question to whether or not all of the project objectives have been achieved, and whether they have been delivered on time or not. These are certainly important considerations, and can be objectively assessed (assuming, of course, that the project objectives and completion date have been clearly defined in the first place).
There are perhaps some more qualitative (and subjective) success criteria that could be used, such as whether the project team members feel at the end of the process that they have delivered a quality project, whether they have a sense of achievement, or whether they feel they have been allowed to exercise autonomy and work creatively. Unfortunately such criteria cannot be precisely defined or measured, although they may be just as important in some ways as those that can. The success criteria that can be objectively evaluated are commonly linked to the objectives defined in the project's scope document and therefore tend to include:
It should probably be stated at this stage that there are no absolutes when it comes to measuring project success or failure. Even the fairly objective criteria shown above can be interpreted differently, depending on how they are interpreted and by whom. A failure to involve stakeholders during the formative stages of a project (and indeed throughout the development process) can mean that the end product is poorly received, even if it the project has achieved all of its agreed objectives. Organisations, after all, are made up of people, and people are often resistant to change. This is particularly true for end users of a product or service who have had little or no input into the process that created it.
To look at this from another point of view, consider a scenario in which a project takes significantly longer to complete than anticipated, and substantially exceeds its budget. Maybe it does not even provide all of the promised functionality or features. But if the end result is something that is user friendly and highly beneficial to the client organisation, it can hardly be said to have failed.
In contrast consider London's Millennium Dome, which was delivered on time and within budget. Unfortunately, the public did not respond to the project with anything like as much enthusiasm as expected, resulting in substantial operating losses for the owners (the New Millennium Experience Company Ltd.), who subsequently went into liquidation.
It would appear that for a project to be successful, not only must the project management process be efficient, but the objectives of the project must be fully understood and agreed upon by all of the project stakeholders. Traditionally, project management theory has identified an "iron triangle" of success criteria consisting of cost, time and quality.
More recent thinking recognises that while the cost and time elements are easily measurable, the issue of quality perhaps needs to be considered from a range of perspectives, including not only that of the organisation as a whole but that of every stakeholder. Some of the perhaps less directly quantifiable criteria for success could therefore include:
Whatever your view of what constitutes a successful project, it is vital to consider all stakeholders and the perceptions that they may have. As far as quality is concerned it, like beauty, is often in the eye of the beholder. It is vital for the project manager to understand what stakeholders consider to be the most important criteria for success, and in order to do that he must be able to identify the different perspectives that exist within the stakeholder community.
Success criteria should be both clearly stated and achievable, and should be ranked in order of priority. The nature of the project itself may dictate the success criteria chosen and the priority assigned to them. If the project is urgent, time is a critical factor in determining success or failure and completion on schedule will be an obvious criterion for project success. If financial constraints are the main consideration, then keeping costs within budget may take priority.
It is worth pointing out at this point that success criteria are the standards by which the project will be judged, whereas success factors are the somewhat more intangible issues that will determine how well the results of the project are received, and may be considered to include the long term benefits for the organisation and user satisfaction.
This article was first published on the TechnologyUK.net website in January 2009.
Constraints are limitations that restrict our freedom of action in some way. Limitations in the time and resources available for some activity are age-old constraints that have affected almost every human endeavour since the dawn of civilisation. Every project we undertake must usually be completed by an agreed date with limited resources, and there will only be a certain amount of money available to fund the work.
The imposition of a fixed timescale and a budget on any undertaking forces us to consider the implications of falling behind with the work or spending too much money. There are also the constraints imposed due to the need to carry out certain tasks in a specific order. If we were building a computer network, for example, we would need to acquire and install network accommodation (i.e. equipment racks and cabinets) before installing the major items of networking equipment.
Any task that cannot be started until one or more other tasks have been completed is said to have a task dependency. One of the most important goals of project management, therefore, is to ensure that we are aware of the constraints that exist, and tailor our plans accordingly.
Having planned work schedules and expenditure around known constraints, we next have to consider the possibility that further constraints may be imposed on us by unforeseen circumstances at some point during the implementation phase of the project. It may be the case that there are a number of tasks that do not have any task dependencies, and may be performed at the same time (i.e. in parallel).
This implies that at certain times during the execution phase of the project there will be a high level of activity, while at other times there may be relatively little happening. This in turn implies that during certain periods there will be a high demand for resources, particularly manpower, in order to get the work done on schedule.
Suddenly finding that key members of the project team are unavailable during such a period due to illness or having been seconded to another project may force you to postpone one or more activity, which can have a negative impact on the project's target completion date. Other constraints can be imposed by delays such as those caused by suppliers not being able to deliver equipment or materials on time, which also has the potential to delay project completion.
One of the aims of the planning process should be to smooth out any peaks in demand for resources wherever possible, which usually means trying to spread the workload evenly throughout the project's lifetime. Where delays are inevitable, one option for bringing the project schedule back on track is to allocate more resources (usually in the form of manpower) to those tasks that are significantly delaying the project. This may marginally increase overall costs (where, for example, overtime has to be paid) but may be preferable to extending project deadlines, especially where time is at a premium (in which case the project is said to be time-constrained).
Most projects incur costs in the form of fixed overheads during the project’s implementation phase. The project overheads are normally proportional to the amount of time taken to complete the project, so any delay is likely to result in additional cost, regardless of whether or not work is taking place. On the other hand, in situations where resources are at a premium (in which case the project is said to be resource-constrained) and overheads are at a relatively low level, it may be better to plan for a somewhat longer timescale in order to smooth out the demand for scarce resources.
This article was first published on the TechnologyUK.net website in January 2009.
Planning a project is about deciding what work needs to be done in order to achieve the objectives of the project, who will undertake each task involved, when each task will be carried out and how long the work will take, and what resources will be required. In addition, all of these activities must be viewed against the backdrop of cost, both ongoing and final. The project plan addresses questions such as what, when, how and by whom.
There can be no plan, however, until it is known with some certainty exactly what has to be accomplished in terms of the deliverables that have to be produced for the project client - in other words the scope of the project. Establishing the scope of the project is important, therefore, because it determines both the extent of the resources required and the amount of time needed to complete the project. Both factors will have a direct bearing on the overall cost.
In order to define the scope of the project, it is necessary to determine the requirements that must be met. This is achieved by talking to the customer and studying the problem to be solved to ensure that the requirements are fully understood. Ultimately, the customer wants a solution to a specific problem or set of problems, and what you are trying to elicit from them is a definitive set of criteria that must be met by the solution in order for it to be accepted. Bear in mind that the customer’s perception of how the problem should be solved may not be the best solution, and may be missing one or more critical elements.
Once the acceptance criteria have been established, they become the objectives for the project. If the project objectives are achieved, therefore, the customer will be satisfied. It is very important to be able to prove to the customer that the project objectives have been met. They must be defined in unambiguous terms, and they must be measurable.
From the customer's point of view, the set of requirements defined will include all of the features that the final deliverable must exhibit (e.g. compliance with applicable industry standards or regulatory guidelines) and the functionality provided (e.g. the actions that the system will perform or the work it will carry out). It is also good practice to try to group requirements into three categories. The first of these will be a basic set of features and functionality that must be provided.
The other two categories will be split between those features and functions that would be highly desirable, and those that would simply be nice to have if time and financial circumstances allowed. This approach defines a basic package and two levels of value-added features and functions, and provides some scope for making decisions on what is to be included in the final deliverable during the planning phase (or even beyond, should circumstances change).
The document that defines what deliverables are to be provided (in other words, the objectives of the project) is called the scope description, and its purpose is to describe as fully and as unambiguously as possible what will be produced, including details of the required features and functionality, and the agreed-upon acceptance criteria. It is important to clarify both what is, and what is not included in the scope of the project, since this defines the project boundaries.
The scope description should list the major tasks that will be undertaken in order to produce the deliverables, and should provide a realistic estimate of when the implementation phase of the project will end. The document should also identify the project's stakeholders. A stakeholder is any individual or group that is either contributing to the project, or is affected by it directly or indirectly.
The scope of a project determines, to a great extent, how much time and effort will be involved in carrying the project through to completion. A preliminary baseline will be established that defines project milestones and the projected work schedule and costs for each phase of the project. The baseline will provide a basis for formulating the project plan, as well as a yardstick against which the actual costs and work carried out at each stage of the project schedule can be measured.
In the early stages of the project, the baseline may be amended to take into account any agreed upon changes or additions to the project scope, but at some point it will be frozen. From this point on, the original baseline will be used as a historical reference point. A revised baseline may be produced at the end of each major phase of the project to reflect any changes in scope that may have occurred. Any significant changes to the scope of a project will have profound consequences on both cost and timescale. The scope does, after all, effectively represent the overall scale of the undertaking.
It is invariably the case however that for a project of any size changes will occur – a phenomenon sometimes called scope creep. The reasons for such changes are many and varied. While they usually involve some additional work having to be carried out (e.g. an extension of the project's scope), there are occasionally situations where the scope of a project is actually reduced. Either way, contingencies must be available for dealing with changes in scope.
It is important to understand the reasons why the scope of a project can change, and (to some extent) to be able to differentiate between them. It may be, for example, that certain tasks have been left out the project plan either because they were simply overlooked, or because not enough information was available to properly define them when the project plan was drawn up.
In such circumstances you are not extending the scope of the project but simply adding to the list of work that must be carried out in order to achieve the agreed upon objectives. There should therefore be some contingency built in to both the budget and the project schedule to allow for this. On the other hand, the customer may request additional features or functionality not included in the original agreement. The scope of the project must therefore be extended to take these changes into account.
Once it has been established that the requested changes are feasible, the impact on the project’s budget and work schedule must be assessed. The project plan will need to be modified accordingly, and any additional costs for the extra work involved should be agreed with the customer, together with a revised completion date.
Another scenario that can (and often does) arise is where the actual time taken to carry out the work exceeds the time scheduled for it, or the cost of materials is higher than anticipated. It should be clearly noted that this kind of occurrence does not constitute a change in the scope of the project. Since the scope of the project is used to determine the project baseline, deviations from the planned work schedule or cost overruns do not warrant a change to the project baseline. Rather, the baseline is maintained in order that we can assess actual performance against it, and determine to what degree it has deviated from the project plan.
This article was first published on the TechnologyUK.net website in January 2009.
There is no single project lifecycle model that fits all kinds of project. Each industry or application area has its own distinct model with very specific characteristics (a simple software development life cycle model is illustrated below). Even within a particular application area both the model used and its precise interpretation can vary. In every case, however, the lifecycle model provides project managers with a structure within which work can be identified and organised into phases. Once an appropriate life cycle model has been selected, its structure can be used to form the basis for developing the project plan.
In the absence of an application-specific life cycle model, a generic model can be used to provide the necessary framework. The following phases might form part of such a model:
The project life cycle model can be used as a framework within which to plan project activities and to define project milestones. Each phase of the life cycle will be associated with a specific set of deliverables which can be evaluated against the planned objectives for the current phase, and which will form the foundation on which the next phase of the life cycle will build. The end of each phase will be a significant project milestone. In many projects, the phases of the life cycle model used will form the basis for the Work Breakdown Structure (we will look at this in some detail elsewhere), which is used to define and organise the units of work that must be undertaken during the project’s lifetime, and which forms the basis for the project plan. The standard assumption is that each phase will be completed before the next phase begins, although there are invariably exceptions to this rule.
This article was first published on the TechnologyUK.net website in January 2009.