• Project, Programme and Portfolio Management
• No comments

QUALITY, SCHEDULE, COST, RISK, ISSUE & CHANGE MANAGEMENT.

In this post I discuss the important aspects of the key project management principles and how they can be applied in a simple and pragmatic way that will provide your organisation with optimum benefits for required effort.

The project management disciplines included in various standard methodologies can be distilled into the following:

Quality Management

Paramount to project success is that the quality requirements of the project deliverables are defined and agreed as early as possible and ahead of finalising plans. Until this has been done the project should recognise that it is carrying a significant risk.

For the purpose of clarity and focus, I recommend separating the standard management items, produced from templates and required for the gate criteria, from the special project deliverables, or products, that constitute the objectives of the project. The quality of the former can be easily controlled by including quality guidelines within the standard templates, which are checked at the lifecycle gates, thus allowing the quality management activities to focus on the latter.

Concentrating on the special deliverables then, there will be a minimum of one per project representing the fully assembled product, or the project may be responsible for delivering a number of different fully assembled products, perhaps as variants. Each of these may break down into convenient sub-assemblies and/or base components, which can be illustrated as a product breakdown structure.

At each level (component, sub-assembly, full assembly) formal descriptions should be considered, based on a standard template, to define the deliverable, its quality requirements and other quality related data: for example method of measurement, responsibilities and product status (in progress, completed, accepted, rejected). The quality requirements of the components and sub-assemblies must be in line with those of the full assemblies, and it is especially important to agree formal descriptions of any components, sub-assemblies or full assemblies for which the design and/or production is contracted out to others as work packages.

All quality related activities (testing, reviewing and authorisation), should be included in the project plan, with cross-referencing between the deliverable descriptions and the planned tasks.

Schedule Management

Delivering projects on time is usually an important requirement, often driven by a need to realise the financial benefits in line with a timeline, such as when bringing a new product to market. A by-product of timely delivery is the ability to release resources from the project so that they are available to work on other things, towards increasing sales and profitability. ‘Time is money’.

Schedule management is the discipline that monitors and controls timing by doing so for the sequences of activities, or tasks, which are required to produce the project deliverables.

The prime tool for schedule management is a plan. There are a number of planning tools on the market, which make planning easy, whether it is done simply or with greater complexity. A simple plan should consist of the tasks required to create the project deliverables, as defined by their formal descriptions, so it is logical to structure the plan in line with the deliverables. The last task of each section of the plan should be a milestone representing completion of the deliverable.

Rather than just ‘what will be done when’, it is more valuable to plan tasks based on ‘who will do what, when’ by assigning the appropriate resource to each task, so that it is clear to the project team members when they will be required to start and finish each task, especially if they are working on numerous projects, very often alongside on going business-as-usual activities.

The duration of each task will often be dependent upon the assumed or assigned allocation of resources. For example, a task requiring a given amount of effort over an originally estimated duration may be completed in half the time if the resource allocation is doubled.

Some organisations generate three estimates of task durations and/ or effort: ‘optimistic’, ‘most-likely’ and ‘pessimistic’, but my opinion is that estimating is too approximate to gain much additional benefit from this added complexity, for the extra effort required. Instead, I recommend that the ‘most-likely’ estimates be used to drive the plan, with risk management being used to estimate the probabilities of, and contingencies for, things not going to plan (as described in the Risk Management section).

Cost Management

All businesses are in business to make a profit, so it is obvious how important it is to control the costs of projects to within project budgets defined and agreed during the early phases of each project. As discussed in the Introduction, it is important to realise that overspends on projects may be hidden by overruns, causing significant loss of ‘value’.

Project costs can be separated into external and internal costs, where the former includes costs paid to others external to the company and the latter are the costs of internal resources, usually driven by rates. These rates can be the individual base rates of each resource, but this can create data sensitivity problems as they are directly related to employee salaries, so it is more usual to calculate an average rate for each resource category.

Some organisations also apply additional costs of employment to the rates, in an effort to best understand the real costs of projects, which is especially worth attempting if the projects are being sold on at higher rates to include profit margins. However, deciding what to include as additional attributable costs to cost rates can be extremely subjective yet very influential to decision-making, so great care must be taken when doing so.

Individual organisations may decide to monitor and control external costs only, internal costs only, or both. This depends upon the magnitude of the costs within each category. For example, construction companies generally spend huge amounts of money on materials and to external contractors, whilst the project team within the organisation is very small; hence little is gained from tracking and controlling internal costs compared with external costs. Whereas, for organisations that sell services (where ‘time is money’ applies), rather than products, it is imperative to primarily track and control internal costs, as external costs amount to little more than expenses.

If external costs are to be tracked and monitored, which will usually be the case, it is useful to agree on a small list of standard categories that can be used for planning and prompting project managers to consider the right things when estimating. These should be agreed with the Finance function within the organisation. The standard categories can then also be used to monitor how much is being spent on each, perhaps with the same few suppliers, which can be helpful when negotiating prices for future projects.

It is also important for Finance departments to understand the split between capital expenditure (CapEx) and operational expenditure (OpEx) costs. Generally, project costs are OpEx, whilst the assets that they create may become CapEx, but there can be some grey areas that need to be agreed and clarified, in order that the project community can provide useful data to Finance.

There may be other costs that projects are responsible for controlling, which are outside of the costs of delivering the project, such as a bill of materials (BoM) for the final product and on going manufacturing and maintenance costs. It is best to treat these as Deliverables and apply quality acceptance criteria (as described in the Quality Management section of this chapter), which include cost targets.

A recognised technique for tracking both cost and schedule performance in monetary terms, which is extremely beneficial for achieving ‘value’ from investment, is Earned Value Management (EVM). Although there are many books on this subject, organisations generally find it difficult to understand and implement, and it is generally considered to be a very advanced technique, adopted only by organisations mature in project management. In my view, however, a simple version of it can easily be applied and it is very beneficial to do so as it provides extremely useful measures of the health of a project (or the health of all projects in a portfolio) at a glance. I shall provide an explanation of how Earned Value Management (EVM) can be simply applied in a later post.

As per my recommendations within the Schedule Management section, I suggest that cost estimates are based on the ‘most likely’ values, with risk management being used to estimate the probabilities of, and contingencies for, things not going to plan (as described in the Risk Management section). I recommend that the total risk contingency, updated throughout the project lifecycle, is included in remaining cost forecasts, as this provides a more realistic total cost figure than one that ignores the risks to a plan, no matter how good the ‘most likely’ estimates of effort and cost are.

Another contingency worth considering, helping on going data stability, is one that takes care of gaps in actual cost data. Providing a facility for project managers to include estimates of cost data that is known to them but missing from the actual costs reported to them (for example due to incomplete timesheet data), can be very helpful.

Risk Management

Of all of the project management disciplines, this is the one in which I have seen the greatest variability in application, and witnessed the least effectiveness (contributing significantly to poor project delivery) and the most wasted effort. It is very often attempted through very complicated methods and tools which project managers, sometimes assisted by risk managers, struggle to work with and which prove to be largely ineffective, despite the effort required.

We discussed earlier that the project plan should reflect the ‘most likely’ estimates for the sequence of activities that we intend to manage. To maximise the chances of project success, we therefore need to consider what might ‘derail’ the plan, such that the quality, schedule or cost expectations might not be met. In other words, risks should be considered in direct relation to the plan.

By deliberately thinking about what could go wrong (and encouraging the project team to do the same) we might then decide to proactively do something to either remove or reduce the risk, which should therefore be planned as mitigation tasks. It may, however, be either impractical or deemed not to be cost-effective to mitigate the risk, in which case we might decide to be ready for it in case it should materialise, by creating ‘fallback’ tasks within the project plan.

A mechanism should therefore be provided whereby risks can be identified by project team members and brought to the attention of the project manager at any time during the project lifecycle, but particularly when planning. Unless the number of risks is genuinely small, it is useful to estimate both the probability and impact of each risk, so that effort can be directed more towards the higher risks, based on the combination of the two parameters, perhaps by escalating them to the project sponsor.

If it is decided that the risk should be mitigated, this should have an effect on the evaluations of probability and/or impact, such that the risk is significantly reduced. It is therefore useful to evaluate the probability and impact both pre- and post-mitigation. Importantly though, the post-mitigation evaluations should only be ‘acknowledged’ if the mitigation tasks are included in the plan.

Rather than introduce calculations based on probability and impact to achieve risk scoring, I propose that this can be avoided by simply applying colour coding as red, amber or green (RAG) indicators based on the following matrix:

In an effort to reduce subjectivity, some organisations try to provide some textual guidance around the scoring bands for each of Low, Medium and High. Whilst this is commendable, in reality it is very difficult to reduce the subjectivity inherent in risk assessing, hence my view is that this added complexity adds little real value and is more likely to cause unnecessary and wasteful debate.

As discussed in the Cost Management section, a more realistic total project cost is achieved if the cost of the risks is added to the cost of the plan. It is therefore useful to calculate the potential cost impact to the project should the risk materialise. A cost exposure value can then be calculated for each risk, where:

Cost Exposure = Cost Impact x Probability Value (post-mitigation) based on Probability Values calculated as follows:

The sum of all of the cost exposure values for all of the risks is the required project risk contingency. This should, of course, reduce as the project progresses and passes the points at which the risks either materialise or are passed.

In order to prompt project teams to consider appropriate risks, there is usually a set of standard risks that can be listed for consideration by all projects. For example, they may well include the following important items:

• undefined deliverable descriptions
• external dependencies (i.e. dependencies on deliverables of other projects)
• stakeholder resistance (i.e. actions taken by individuals who would prefer the project to fail)

Some organisations also categorise risks in other ways (e.g. legislative, commercial, technical, etc.) but I rarely observe any added value being achieved from this additional complexity and effort.

Issue Management

An issue is a risk that materialises. Issues that arise unexpectedly are therefore an indication of poor risk management! The reality of issues is that they are upon you and are causing problems. They need to be dealt with – usually quickly. Having captured them, there is little value in rating them or categorising them. More importantly, the activities required to resolve them need to be planned and actioned. If the resolution action is simple, it may not even be worth planning (just actioned), but if the issue is complicated, the application of a problem solving technique may be required, which should be planned and then implemented.

As with risks, it is useful to rate issues with colour coding as red, amber or green (RAG). I recommend the following for this:

Change Management

In this section we need to be clear that we are discussing project change management, rather than organisational change management. The latter is the process by which organisations capture change requests and arrange for their consideration and possible implementation through a small work item or a project. Project change management is the project management discipline of controlling changes to project scope (quality), cost or timing (schedule).

The Project Initiation Document (PID), is very important with regard to project change management. This is where the project’s quality, timing and cost expectations are captured, alongside the Business Case (benefits versus total costs). Change management should be triggered as soon as the project forecasts that any of the defined and agreed requirements or the Business Case will not be met.

There may be a period during which the project is uncertain about this, that should be highlighted using risk management and reporting. The point at which a change based on a risk should be initiated will be subjective, but I propose that any red risk (post-mitigation), that would cause a project delivery problem in relation to the PID, should be a trigger for change management.

The on going risk management process might, in itself, be a trigger, if additional risks come to light and/or the probabilities of existing risks cause the need for the risk contingency to be increased (in order for it to be maintained as realistic), resulting in the projected total project cost value (including risk contingency) to be greater than the project budget.

An issue might more obviously trigger a change management process, if a re-plan reveals that the quality, timing and cost expectations can no longer be balanced.

Once a change is triggered, it might be appropriate to provide some options. For example, it may be possible to achieve the quality expectations at a cost that exceeds the project budget and/or extends the project timescale. Or it may be possible to deliver the project within the agreed project budget and timescale at reduced quality values. The impact of each option on quality, schedule, cost, risks and the Business Case should be clearly stated, preferably in a standard templated format, to enable good decision-making. For organisations that have large numbers of projects in progress at any time, the use of tolerances are worth considering, allowing minor variances before formal changes are initiated.