• Project, Programme and Portfolio Management
• No comments

USING PLANS & LOGS.

In the previous blog post on applying project management disciplines we discussed how, in principle, each of the six project management disciplines can be applied, each in a simple way that is more likely to lead to success than more complicated applications of project management methodologies. In this post we are going to discuss how this can be practically achieved using plans and logs with reports that pull data from them.

It is a basic requirement of any organisation to define how it requires its employees to work. This applies to all important business processes including those which define how it intends to manage projects. It is not sufficient to simply state that a particular methodology (such as PRINCE2®, BS 6079, ISO 21500 or the PMBOK®) is to be used, as they are all scalable to what is important and workable to individual businesses, based on their size, complexity, maturity, environment and culture.

A process should therefore be defined that applies each of the project management disciplines, based on the principles we discussed in the previous post. Each process should be defined in line with the phases of the project lifecycle and care should be taken to make sure that the processes fit together and do not conflict. The processes should refer to the use of plans and logs as the prime project management tools, for which standard templates should be created.

I propose the primary use of plans and logs as follows, although plans should also include activities for quality management, risk management and issue management:

Using Plans for Schedule and Cost Management

In this post, though, I make no assumptions regarding whether plans are created using project management software or other mediums such as spreadsheet software, presentation software or even paper.

The process content for schedule management and cost management should make clear who maintains a realistic plan in such a way that the principles outlined in post 3 are satisfied and project reporting is in line with the plan.

Using plan templates to ensure that the right activities are considered

It is extremely helpful if, as a minimum, a plan template is created which is structured in line with the project lifecycle, in order to influence projects to follow it:

A single plan template will obviously require the least maintenance, but may also restrict an organisation from achieving the benefits that might be possible using multiple templates. There may be a good case for maintaining multiple plan templates if:

• separate parts of the organisation run projects that are different to other parts of the organisation
• there are different types of projects, each of which are themselves similar

Each plan template should be based on the same base template, which is structured in line with the project lifecycle (hence any changes to the project lifecycle will require changes to all plan templates). Plan templates can be used with the sole purpose of providing a standard structure, but the more content they include the less plan development is required by the individual planners who initiate their plans from them.

As well as common tasks within a defined structure, plan templates can also include links between tasks, resource assignments and estimates of effort and duration. Plan templates with such rich content can then be very beneficial to close the loop on lessons learned from projects, as the actions from these can often be to update a plan template (or templates), to ensure that subsequent projects plan to do things better.

I have implied that each plan template spans the complete project lifecycle. There is an option to separate out the templates into individual templates by phase, but I would only recommend this if the size of the plans becomes cumbersome. I highly recommend that, where plan size allows, plan templates are provided to facilitate plans being created for each owner. In other words, if a part of a project is to be ‘sub-contracted’ to another party (either internally within or externally to the organisation), as a work package or sub-project, then a separate plan should be used for this, rather than having numerous owners of the same plan.

Planning the right level of detail to be efficient

Whilst it is unlikely to be necessary to initiate a plan in the Concept phase, it is useful to create one during the Definition phase. At this time the level of planning should generally be high level so that, should it be decided not to take the project forwards, the wasted effort is minimised. However, the level of detail required will depend on the experience of the planner in the type of project being planned. The planner needs to have confidence in the plan, which might only be gained by adding detail.

The plan created during the Definition phase can serve to provide an early idea of achievable timescales and the time-phased resource requirements, which can then be used to calculate the associated internal costs. It can also be used to prompt early thoughts on external project costs and risks. During the Definition phase, the Initiation phase of the plan should be detailed so that it is clear how the proposed project will be set up on good foundations before being authorised to do so.

During the Initiation phase, the plan should be verified at high level still, rather than adding too much detail. The Delivery phase should, however, be detailed up to the first gate within this this phase, prior to commencing it. Thereafter, further detailing of the plan should similarly be progressively added, up to each subsequent gate within the Delivery phase, prior to passing through it. In the final section of the Delivery phase, the Closure phase should be detailed, so that it is clear how the project will be closed out in a controlled manner.

As a general principle, to protect plans from becoming too large,  I suggest that tasks of a minimum of a half day duration is a good guideline. If there are smaller activities than this that need to be captured and tracked, I recommend the use of an Actions log to capture them. This log should then be reviewed as part of periodic project review meetings, alongside reviewing progress against the plan.

Planning resources to maintain achievability

Key to a project’s success are the resources required to deliver it. These include, most obviously, the people, or labour resources, but there may also be important facility resources and/or material resources which, if not planned and managed successfully, can cause delays.

It is usual for projects to utilise resources from a finite resource pool, which are shared with other projects and ongoing business-as-usual activities. Unless there is confidence that the resources required to deliver the tasks identified in a plan will be available at the right time, to apply the agreed effort within the durations scheduled, there is a significant risk to project delivery.

To gain this confidence, a mechanism is required whereby the time- phased resource requirements of each project are identified and brought together with those of all other projects that share the same resources. The requirements of resources for business-as-usual activities also need to be accounted for, either by reducing the capacity of them (to the percentage that is available for project work) or by adding the required effort for these activities into resource analyses.

If analysis of the total resource demand from projects is greater than the capacity of any resources, then the projects that are assuming use of those resources are unachievable. It is very important to project success that resources are not over-allocated and that this state is continuously maintained.

To help achieve this, it is important to gain a mid/long term view of resource demand that can be compared with current capacity, so that any gaps can be filled before there are any short-term problems. If it is possible to have mechanisms in place to promptly fill short term gaps with appropriate temporary resources, then this is an obvious strategy that should be considered.

For high level planning, it is usual to consider the roles required to complete the scheduled tasks. For tasks that are to be completed in the near future, it is important to identify and agree the specific resources (named people or facilities) that will complete the tasks, whilst gaining verification from them that their tasks can be achieved within the planned effort.

To help project planners, it is useful to set up and maintain a centrally controlled resource pool that includes both the full set of roles and the complete list of specific resources, ensuring that it is clear which of the latter match with each of the former.

Using milestones to highlight key dates

Milestones are tasks of zero duration. They are very useful for highlighting inputs and outputs to a project along with other key dates. Most obviously, the project lifecycle gates should be represented in the project plan as milestones. Another important use of milestones is for representing external dependencies, against each of which there should always be a corresponding risk that is tracked and managed.

Most planned tasks should be towards creating the project deliverables; hence it is logical to represent completion of the deliverables with milestones that correspond to the deliverable descriptions, each referencing the other.

Another convenient use of milestones is for representing the points in time at which goods and services are due to be received, these being the events that trigger project costs being attributed to the project.

Some planners prefer to group the various types of milestones together and position them at the top of the plan, while others prefer to place them within the plan based on where they fit within logical sequences of tasks.

Using plan baselines to control delivery

Plan baselines are records of the state of a plan captured at particular points in time, which can be used for comparisons with the current state of the plan as the project progresses further. By capturing a snapshot of the plan in an agreed state, at a project lifecycle gate for example, then any variances from it can be identified and acted upon, if necessary.

Baselines are particularly useful in combination with milestones. Tracking schedule variances of milestones is a key strategy for ensuring that projects deliver on time. With regard to scheduling, it can be argued that there need be little concern for what is happening regarding task completion, as long as the delivery milestones are achieved on time.

As well as illustrating schedule variances, plan baselines can also be used for comparing effort and cost values. For these parameters, it is generally more useful to compare the total values of sections of the plan (e.g. the phases), rather than those of individual tasks.

Defining an update cycle to maintain data quality

Maintaining a realistic plan is fundamental to keeping a project on track. Without it, there is no way of knowing if the remaining activities can be arranged and managed to achieve acceptable timing. If there are any changes that cause a need to re-plan, this should be immediate. For general plan maintenance, though, an update cycle should be defined to prompt periodic tracking of project progress. In order to do this a mechanism is required whereby the plan owner is provided with progress data from project team members, regarding whether tasks are completed or partially completed in line with the schedule. This can be achieved by discussion, prompted by an agenda item at project review meetings, or by collection and compilation of progress data from team members.

If the organisation intends to include internal costs within its cost management, then it will be even more important to be rigorous and to put in place a mechanism for periodically capturing the actual hours of work incurred by project team members.

In order to track external costs, the update cycle needs to include a mechanism whereby the total costs spent to-date are captured. At any time in the project lifecycle there are the following states of external costs:

• items that have not yet been ordered
• purchase orders that have been raised, but the goods or services have not yet been received – these are termed ‘committed costs’
• goods and services that have been received
• goods and services that have been paid for

It is usual for projects to plan and track goods and services based on receipt, so actual cost to-date data for external spend should include all items of this status. A reliable mechanism for recognising that goods and services have been received and accepted should be put in place. Committed costs should be treated as part of the remaining costs to complete the project, along with the goods and services that have not yet been ordered. Whether goods and services have been paid for or not is generally of little concern to the project, unless a ‘bad debt’ might affect the relationship with a supplier of items yet to be received.

Having updated the plan with actual progress, there may be variances compared with planned progress. Any uncompleted work in the past should now be rescheduled into the future and the remaining effort and task durations should be reviewed. If the project team members are resources that are shared with other projects and/or do other business-as-usual activities, then checks should be made that the re-planning has not created any over-allocations. This is of paramount importance as any plan that assumes the use of over-allocated resources is unachievable. If this happens, then the tasks in question should be either rescheduled or allocated to another resource.

Using Logs for Quality, Risk, Issue and Change Management

The purpose of logs is to capture important items relating to a project to enable them to be tracked. The use of logs should be included in the process flowcharts for quality management, risk management, issue management and change management. These should support the principles discussed in post 3 and facilitate project reporting.

Below are proposed lists of fields for the logs of each of these four project management disciplines.

Quality Management

For tracking the quality of the project deliverables (or products), I recommend the use of a Deliverables log within which they can be defined, along with their quality criteria and other quality tracking data. It should include the following fields:

Risk Management

For capturing and tracking risks, I recommend the use of a Risks log comprising the following fields:

Issue Management

For capturing and tracking issues, I recommend the use of an Issues log comprising the following fields:

Change Management

For capturing and tracking changes, I recommend the use of a Changes log comprising the following fields:

Using Reports to Enable Exceptional Projects to be Highlighted

The generation of reports is usually very labour intensive, so this activity should be reduced to the absolute minimum that is required to enable efficient decision-making. Both the number of reports being generated and the content of them should be minimised, to enable their frequency and timely generation to be optimised. Far too often, the various parts of the organisation demand numerous similar reports to be generated, where some easy compromises would provide significant savings.

The key to optimising reporting effort is ‘drilldown’. This means that there needs to be some high level measures that trigger more in-depth analysis. If tolerances are defined for each project health measure, then red, amber, or green (RAG) indicators can be either calculated or manually declared, providing very visual indicators of project health  (or performance).

If project plans are used for schedule and cost management, then it is possible to calculate variances between the latest plan and baselines, from which RAG indicators can then be calculated. It is best to calculate schedule RAG indicators for milestones (or key milestones) and cost RAG indicators based on sections of the plan (e.g. the phases).

Overall project level RAG indicators should be used to fulfil high level reporting across projects, prompting drilldown analysis of underlying data within exceptional projects, where the RAG indicators of milestones and sections of the plan provide the next level of detail.

As well as plan based RAG indicators for cost and schedule, it is important to include other RAG indicators in high level reporting across projects. This should include indicators for the overall status of each project’s quality, risks and issues.

I recommend that, for tracking the performance of projects, organisations define one standard report that brings together the project level indicators, to illustrate the health of each project (and highlight exceptional projects), and another standard report that brings together more details of any single project, that can be produced for the exceptional projects when required. I suggest calling these the Portfolio Summary Report and the Project Summary Report. Below is a list of the proposed fields that should be included in each:

Portfolio Summary Report

Project Summary Report

As well as variances between baselines and the current project status given by the plan and logs, it can be useful to calculate variances from one reporting period to the next, but this introduces further complexity and reporting effort, which I suggest should be minimised unless it is automated through configuration of software tools.

The timing of when reports are produced should be defined to fit in with other business processes. For example, the cost performance status of an organisation’s projects will usually be an input to the businesses financial performance, so it is generally logical to complete project reporting immediately prior to providing project cost data to the Finance function. Project reporting should also, of course, be timed so that it is after completing an update cycle, to ensure that the status provided is up-to-date.