PERFORMANCE MANAGEMENT


Performance and its control is one of the areas on which you should spend a significant amount of time. Sadly, measuring how successful a project is can be difficult, particularly the success of an advanced project. It is difficult to measure success because advanced projects tend to be unique projects. This means that little in the way of previous performance measures exists. Despite the difficulties associated with performance measurement it is nevertheless a goal worth pursuing. The key to measuring and reporting success is to focus on the main foundations of any project:

  • timescale ;

  • resource;

  • quality;

  • scope.

Once you have understood these and put in place measures to enable their management you need to look at a fifth aspect, performance analysis.

Timescale

Timing is obviously important for any project. However, with an advanced project you need to apply a slightly different perspective. You need to understand what lies behind the timing rather than just the timing itself. Advanced projects by their nature are trying to do something difficult. If they weren't then the project would not be thought of as advanced in nature. This means that although they have a general direction the final deliverable is not always clear. In fact, it is likely to change on an ongoing basis as the project progresses. This effect can be thought of as a funnel (see Figure 6.3).

click to expand
Figure 6.3: Uncertainty funnel

This figure illustrates a lack of certainty at the start of a project, which gradually improves as the project progresses. Put plainly, since you don't know at the start what is to be delivered at the end it is pointless trying to assess it in detail. Instead you should focus on what could potentially be delivered in the timescale. This method is often called a risk-based method. It means that when reporting you should focus not only on progress but also on understanding the end deliverable. A simple way to achieve this is to examine the volume of DLRs against time.

Figure 6.4 illustrates the DLR approach to measuring the likely variation in timescale. The graph shows a sharp increase in the number of DLRs from January to March. This is the initial startup period of the project. As these DLRs are translated into firm plans in March to April, the rate of increase falls . This happens because there are fewer DLRs being written since the project team is starting to understand the requirements. In March the plan is baselined and work begins. As work progresses there is a steady increase in the number of DLRs. This happens because there are new ideas and there is a requirement to correct existing DLRs.

click to expand
Figure 6.4: DLR volumes

It is possible to analyse this graph to determine the position of the project. The first measure to consider is the ADLR. This is the number of DLRs that have been created in addition to the baseline. Using this figure in conjunction with the time T1 (time taken for the DLRs to be added), a rate of change figure can be derived:

It is this figure that is interesting for measuring the performance in an advanced project. If T1 is held constant then the rate of change can be compared continuously.

Figure 6.5 illustrates a rate of change curve plotted against time. From this graph it becomes obvious that the rate of change increases after June. This is a good indicator to the project manager that action may be needed.

click to expand
Figure 6.5: Rate of change

Deciding on the period of T1 depends on the project. If the period is too small then it is not a worthwhile exercise. The graph will look the same as DLRs against time. However, if it's too large then the rate of change can become meaningless. You should pick a value that gives a reasoned output. You should also not be afraid to change that value if you are not getting the type of result that you want.

Resource

Resource reporting on advanced projects can be complicated. There are a lot of people, and figuring out what they are all doing can be very difficult. If there are 200 people working on a project then you would potentially need to have 200 conversations every day. Obviously some other method or system is needed. Generally, organizations have an in-house system. When this is not the case then you should set up your own monitoring system. Before describing such a system it is worth examining exactly what is required of resource performance measurement.

Resource is employed in two general ways in an advanced project. Firstly, the term is used to cover funds used to buy goods. Secondly, the word is used to mean people who perform activities or services. Both uses need to be measured and need to be included in any performance measurement. Normally interest in these two areas concerns how much of the resource has been used. However, whilst this is an important factor it is not sufficient on its own to measure resource performance.

A simple technique for looking at this is earned value analysis. With this technique the ongoing value is examined as the project progresses.

Figure 6.6 shows two cost lines. The first line is the baseline cost of work performed (BCWP). This is the cost that the project would incur if the project managed to stick exactly to its baseline plan. However, as most experienced project managers know this rarely happens. Therefore a second curve is required. This curve shows the actual cost of work performed (ACWP). In this diagram the cost lines include all costs in the project. However, this could easily be changed to enable the project manager to examine only staff costs or only external consultant costs.

click to expand
Figure 6.6: Value analysis

Perhaps the biggest value that can be derived from this picture is the difference between the two lines. This is commonly called the variance, A. The value of the difference at any moment in time is:

You are able to derive some very interesting data from the value of the variance. If the value is positive then the plan is ahead of schedule. The ACWP line will be above the BCWP line. If it is negative the plan is behind schedule. The ACWP line will be below the BCWP line. However, you need to analyse the chart further before reaching these conclusions. It is perhaps more interesting for you to consider boundaries for the BCWP line and compare these to the ACWP.

Figure 6.7 shows two boundaries, B1 and B2. Examining the figure shows that the ACWP line exceeds the upper boundary B1 at T1. This is the point of alert for you. At T2 the ACWP line comes back within target, presumably as a result of corrective action.

click to expand
Figure 6.7: Value analysis boundaries

You should also remember that breaking the limit could have occurred not because of problems but because the project was ahead of schedule. However, this might still be a problem in an advanced project because it might affect an organization's cash flow. Cash flow is very important in all organizations. Advanced projects can often form a substantial part of that cash flow. They have large budgets that often run into a value of several million pounds . This can result in difficulties if a project starts to get ahead of its schedule and require funds earlier than expected. For example, it's possible that the borrowing needed to support the advanced project is 5 million. If this money is borrowed too early, extra interest may need to be paid: a lot of interest when you're borrowing & pound ;5 million!

To implement earned value analysis, the project manager should simply task each work package manager with maintaining such a graph. The upper and lower boundaries can be set through negotiation. You should not be too harsh in setting the boundaries since they can always be adjusted as the project progresses.

The graphs that you set up should cover the high level as illustrated . However, in many instances this will not be sufficient detail to allow the type of information that you want. To achieve this, you should set up several graphs to work in a cascade. Cascade graphs can be easily set up using a spreadsheet program. If possible the graphs should be placed on a central server to allow all work package managers access to them (see Figure 6.8). They can then simply update them as needed, removing any requirement for you to collate information. Obviously where this is not possible you or your administrator will need to collate the material.

click to expand
Figure 6.8: Cascade reporting

Quality

Measuring an advanced project's performance in terms of quality can seem a daunting task. Often rather than tackle the issue project managers find a method of avoiding it. It is easier to explain to customers that the organization is quality approved to standard such and such than to explain how quality is measured. Measurement of quality performance does not need to be a difficult task. Put simply, quality should be saying what you're going to do and then showing you have done it.

There are many standards that are commonly used by companies and organizations. Where they exist and you feel they are sufficient they should be used. However, it's worth considering adding some simple quality checkpoints into the system. Quality checkpoints are points in time where a review of the quality is held. There are a few obvious points in time to hold these:

  1. macro plan complete;

  2. detailed plan complete;

  3. at each major milestone;

  4. at the conclusion of the project.

At each review you should assess quality and related matters only. You should not get sidetracked into operational matters. For example, when discussing whether the plan is being adhered to, you should not get sidetracked into a discussion on how to bring the project back on to target.

The review should be based on facts. Firstly, the review should consider whether the systems that have been put in place are working properly, for example the boundary conditions set for the cost analysis performance graphs. Secondly, the review should consider whether the deliverables being produced are measurable, for example whether there is a design that is being used as a basis for testing. Lastly, the review should consider whether the staff in the project know and understand the processes and procedures they should be following.

Prior to the meeting you should spend time assessing these issues. If you spend a reasonable amount of time then the meeting is more likely to be productive. At the end of the review a series of actions should be defined. As with all action plans the actions should be Specific, Measurable, Attainable, Realistic and Timely: SMART.

Scope

Measuring performance with regard to scope falls into two categories: current scope and stretch or aspirational scope.

Current scope

Current scope refers to the set of HLRs and DLRs that have resulted from the process used to create the project baseline. Measuring performance for current scope refers to measuring the success of delivering the content of these DLRs and HLRs. This should not be confused with other measures like measuring whether the DLR will be delivered on time. It is important to examine each of the DLRs and HLRs in order to understand fully whether they are being met. It is important to understand this since it is frequently the scope that is reduced to enable the project to continue to hit its time line. This is illustrated in Figure 6.9.

click to expand
Figure 6.9: Scope reduction

The top bar in the figure represents the ideal scope. The bottom bar indicates the actual scope that is being delivered by the project. This scope is substantially less. Surprisingly this is normal in advanced projects. It is nearly always the case that some part of a DLR will be dropped in favour of on-time delivery. Measurement of this can be a time-consuming activity. It is also not a particularly fruitful activity. Generally customers will only care about final delivery. However, there is a method of examining the project's performance with consideration to scope. Instead of trying to assess the missing scope, project managers should measure the churn in scope.

Scope churn is simply a measure of the change in scope that occurs across the project. It can be easily measured by examining change requests. Scope churn is also sympathetic enough to scope content to make it a useful performance indication. Measuring change requests can give a number of interesting results. In relation to scope the part to examine with the change requests is the number of change requests for any given DLR. However, this on its own is too simple a measure; instead you should be examining the number of change requests raised to reduce functionality. Although this can seem daunting it is actually a reasonably simple task. If it is set up at the start of the project it is also easy to manage. A simple table is all that is required (see Table 6.1).

Table 6.1: Change request measurement

Change request title

Reduced functionality

New functionality

Additional functionality

Change request 1

Change request 3

Total

1

1

1

It is relatively simple for this table to be kept up to date. Perhaps the simplest way of achieving it is to add it to the change request form. It is also advisable to make it a requirement for the body that runs the change requests process to update the table. Scope churn is simply the value plotted out over time. A high churn indicates that the current scope is not stable.

Aspirational scope

Aspirational scope is the addition of new features through the project life cycle. Recording and assessing it is achieved in a similar manner to assessing baseline scope. Space was included for this in the chart of Table 6.1 and appears as the last two columns : additional functionality and new functionality. Additional functionality is based on existing requirements. The objective is to examine the functionality that is added to the initial baseline requirements. New functionality is not based on existing requirements. The objective is to examine how much extra functionality has been added to the project.

Table 6.1 can be enhanced by the addition of a date field. This enables totals to be generated on a monthly basis. This can be tracked as a cumulative graph, as shown in Figure 6.10.

click to expand
Figure 6.10: Cumulative change requests



Advanced Project Management. A Complete Guide to the Key Processes, Models and Techniques
Advanced Project Management: A Complete Guide to the Key Processes, Models and Techniques
ISBN: 0749449837
EAN: 2147483647
Year: 2007
Pages: 69
Authors: Alan D. Orr

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