The Busy Person's Project Management Book

Chapter 6 - Keeping it together

So you and team are finally on your way and your project has commenced. As we have discussed throughout this book, there are many things that you and the team have to keep an eye on.

Just as in our journeys where planes can be delayed, bad weather can interrupt some of our planned stop-overs and the children get sick, there are many factors that can prevent the project from going to plan. Clearly, the more rigorous and participative your planning session, the more likely that you and team would have included adjustments and allowances for the risks and so on. However, to ensure that your project has not started to get "off-the-track" then, as in most activities associated with project management, you must formalise the monitoring of progress and the reporting of progress to your stakeholders and project sponsor.

In this chapter, we will cover how to track your project, what formal reports you should be producing and what should you do when things change in your project.

Project Tracking

Project tracking has one major objective - to determine whether your project is "in control", i.e. meeting agreed deadlines, objectives, estimates and so on, or "out of control". As soon as your project has slipped "out of control", you should immediately undertake project re-planning which can include re-negotiation of the Business Case and technical specifications for your project. This tracking process is most simply achieved by a combination of formal tracking procedures and regular team meetings.

The initial focus of project tracking is to review the status of the Business Case to determine any actual or potential variations. Should any variation of the Business Case, in particular, the scope, objectives and risk, occur you should use formalised change control as described later in this chapter.

Apart from checking whether there are significant changes to the Business Case, a secondary focus for project tracking is for you and the team to compare the number of tasks completed with the number of tasks you planned to complete and the actual effort and duration versus the estimated effort and duration.

In other words, project tracking is dependent on task tracking. Task tracking is undertaken by each team member working on the project while project tracking is achieved by you and the team summarising the actual task effort completed by team members and stakeholders using the project plan and as the benchmark. Most PC-based scheduling tools provide the capability of entering actual effort against the estimated effort.

Provided that you and the team followed the "5/10 day" rule detailed in Chapter 4, for purposes of both project and task, you should treat tasks as either complete or not complete; "almost complete" tasks counted as complete will give you an inaccurate picture. This approach simplifies project tracking and avoids the 90% complete syndrome wherein a task remains almost complete for a period of time. The formal term for this is called the Zero-Hundred Percent technique.

It should be noted that there are other methods of tracking completion of tasks. One technique commonly used is the Linear Progress approach where the percentage complete is calculated from the actual duration versus the estimated duration. If a task was estimated at 20 days duration and 10 actual days have been spent then the task is 50% complete. A variation of the Linear Progress technique is a subjective evaluation of the worth of the actual effort. For example, although 10 days of 20 days have been spent, the person undertaking the task subjectively assesses that it is 70% complete. However, you will find that this technique can be very distorted by subjective judgements and, more importantly, by last minute difficulties in completing a task (many of us like to leave the hardest bits until last). So you should use the Zero-Hundred Percent technique for your tracking.

While you and the team will find that project tracking is typically undertaken on a weekly or bi-weekly time-frame, it should be emphasised that as soon as a team member or stakeholder realises that they will not meet their task deadline, i.e. they are "out of control", they should notify you so that the requisite corrective action can be taken. Clearly, this is vital for all tasks on the critical path of the project. For non-critical path tasks, this action would only be required if the change exceeds the available float for the task.

Fig. 22 - Project tracking meeting

An useful diagram for task tracking is a Gantt chart for each person on the project (see Figure 23). Most PC-based scheduling tools will provide this chart. These charts provide each team member with a clear picture of their individual work effort while the overall project Gantt chart provides each team member with a "common vision" of how the effort of all team members combines in the project.

Fig. 23 - Individual Gantt : an essential tracking model

The other focus of project tracking is to collect data to assist you in costing and in the creation of an estimating history. This involves project you and the team members recording actual and elapsed time spent on the various phases/tasks of the project.

The actual work effort and actual elapsed duration spent on each project phase/task should be recorded daily by each project team member on a project/task tracking document.

This information is required to assist in collecting an estimating history for future projects and, in some cases, for the accumulation of costs for examining the cost-benefits of the project. You should be clear that tracking effort and duration is not a time-keeping or personal evaluation document. It would be quite legitimate for no work to be done on a project task during a day.

It is not necessary to "balance" the number of hours each day or to ensure that the entire 8 hours of the day are accounted for. Project tracking tracks and monitors projects, not people.

Using this approach you and the team can then assess the accuracy of the estimated work effort versus actual work effort and estimated elapsed duration versus actual elapsed duration and, where necessary, adjust the schedule as discussed in Chapter 5 and re-plan the project.

You and team members may also wish to track work on other activities such as support of existing products, activities such as meetings, administration of your people, travel costs and so on.

Project Reporting

The format and timing for your project reporting will depend on the length of the project i.e the shorter the project, the shorter the reporting cycle. In Mary's project, the estimated duration of the project was 4 months, so she and the project sponsor agreed that a fortnightly project report was required.

The essential information that should be forwarded to your project sponsor and key stakeholder areas is:

• the status of the project, i.e. is it still proceeding to plans or not;
• if not, what is the revised situation and causes for the variation;
• what actions have been taken by the team to solve any problems;
• what alternative scenarios are available;
• what actions can be taken by the project sponsor and stakeholders; and
• revised or updated Business Case.

In addition, project reporting could also involve an aggregation of actual costs to date for the project.

Control of Project Change and Variation

Despite the best of our intentions and plans, it is almost inevitable that the need for change will occur some time before you finish your project. What you need is a pre-agreed process to evaluate and process the impact of changes to the Business Case and the re-planning of your project should the impact be significant.

In this context, you will find that changes can be internal or external.

• Internal changes:
  are those that arise during project development due to mis-understanding of requirements, estimation errors, project team member changes, invalid assumptions and technical issues that could not be foreseen during the initial planning of the project;
  
  
• External changes:
  are those that arise through changes in stakeholder or client requirements, new policy decisions, new/changed ideas, requirements of other projects and so on, which were not part of the original product specification.

Although it is likely that an internal change will almost always be accepted by the team as being essential, for control purposes, both internal and external changes must be treated in the same manner.

Control of changes involves three steps - request for change, evaluation and decision:

• request for change

  All requests for change must be documented no matter what the source, otherwise you will lose track of your project. The requirement is for a brief note addressed to the you and the team which must include the originator's name, date of request, description of the problem addressed, description of the change and justification for it.

• evaluation

  You and the team must evaluate the change. This would be normally achieved through the convening of a team planning session which would assess the following:

  • is the change really justified?
  • if justified, is it essential that it be made at this time or could it or another feature be deferred until after the Post-Implementation Review phase at the end of the project?
  • does the change alter the scope, objectives and stakeholders of the project?
  • what tasks, whether completed, in progress or to be commenced, would be affected?
  • estimate of work effort and duration required to implement change?
  • will it require re-scheduling of the project and/or extend the completion date of the project and/or a change of project development strategy?
  • will it require additional resources to carry out?
  • does the change impact across sub-projects or components?
  • does it alter the complexity and risk of the project? and
  • what risks are involved whether the change is implemented or not implemented?
  • decision

Assuming that you have no doubt that change should be made at this time, and provided it will not require additional resources, alter the risk, alter the Business Case and/or extend the completion date of the project, it can be accepted.

If there is some doubt, or if the change is very extensive, you should call a meeting between stakeholders including the requester of the change. This meeting should discuss all aspects involved and come up with a recommendation for the sponsor to proceed or otherwise.

If you decide to adopt the change, you and the project team must take the necessary steps to put it in train. This will mean that you should conduct a new project planning session. It must be remembered that whenever the project moves "out of control" as a result of either external or internal change, you must conduct another project planning session.

For example, in Mary's project, one of her clients requests changes in the way in which the statistics are being coded. As Mary's project's deadline cannot be extended, Mary decides to change the development strategy in her project to accommodate the changes. She chooses to move from the original Sequential release to a Concurrent Release strategy by keeping her initial team working on the original specifications and to add a new team member to alter the codes as a new release.

In most projects, by renegotiating the project's scope, objectives, resources, deadline and strategy, you can manage the changes to your project. The key is to make these negotiations open and participative.

So you've planned, tracked, reported and managed the changes to your project. You and the team have just implemented the changes that your project was developing. Congratulations!

However, your project is not quite over yet.

copyright: thomsett INTERNATIONAL 2008 | contact