manage project progress -...

Reading: Manage project progress

Manage project progress

Inside this reading:

The control phase of a project 2Establishing a project monitoring and control system 3Managing changes 5

Methods used to monitor projects 7Team communication and gathering project data 7Periodic reporting 11Monitoring tools and software 12

Controlling the project 15Schedule control 15Task and team management 16Quality control 17Control tools and software 18

Assessing and implementing change 19Changes to project scope 19Steps in change control 20

Reporting 25Status and progress reports 25Structure and format of reports 28Templates, checklists and document control 29

Summary 30

document.doc© State of New South Wales, Department of Education and Training 2006 1


The control phase of a project

The control phase of a project involves the main activities listed in Table 1.

Table 1: Summary of project phases, with control phase shaded

Planning processes Implementation processes

Initiate Planning Organise Control Close

Define the overall project goal

Develop detailed task list

Procure necessary resources

Team leadership and support

Complete final deliverable

Identify all stakeholders, their needs and expectations

Estimate all task times and all costs

Recruit necessary personnel

Establish control tools and methods

Obtain stakeholder acceptance and sign-off

Identify the project objectives

Arrange best sequence of all tasks

Organise and lead the project team

Monitor the project plan and make any necessary corrective actions

Document project results and achievements of team

Identify initial work and resources and basic milestones

Develop workable schedule and identify critical milestones

Assign all project tasks

Assess and implement change

Write and issue final report

Identify all constraints, assumptions and risks

Write detailed project plan and obtain approval from stakeholders

Communicate with stakeholders and all necessary parties

Prepare and distribute status reports

Conduct review of project lessons

Although this project phase is known as the ‘control’ phase, control processes have been at work since the planning stages and will continue through to the end. In this topic we’ll see how controlling the progress and direction of the project happens in a cycle, and how it requires willing contributions from all the team.

Every member of the project team shares accountability for checking, controlling, reporting and integrating work. The key to success will be your ability to handle the day-to-day pressures of what can happen with:

Resources—people, equipment, materials

Time—are tasks taking longer or less than expected? Will you be able to deliver on time?



Money—do you have enough cash flow? Are there unexpected costs?

Changes—when events lead either you or the client to request a change in the project’s scope.

No doubt you can see that these elements are inter-related, and a change in one generally affects another. For example, someone gets sick, and you can’t get a replacement on time, the task takes longer than expected so the schedule is put behind. It won’t make the client happy, so you’ll need to do something!

Avoiding project failure

There can be many reasons a project fails. However, failure often relates to:

the support or otherwise of upper management in an organisation

lack of ongoing support from project sponsor/steering committee

the quality of the project management; ignoring standard project management processes

a project manager selected for seniority rather than appropriate skills

lack of dedicated team effort.

Some large organisations have a project management office to handle projects and processes. Yet for managing a simple project, avoiding project failure includes the use of templates, best practices, standards, guidelines, and policies, much of which is behind the work of monitoring and control discussed in this reading.

We will look in more detail at the control phase activities in the following sections. Communicating and leading are very important, but you also need to use controlling skills to keep the project on track.

In the end, as the adage has it, ‘projects don’t fail; people do’. In many cases, project managers are unprepared for their role. They aren’t professionally trained, and don’t manage what they are doing. A good project leader needs strong interpersonal, technical and administrative skills.

Establishing a project monitoring and control systemAs the project manager, you are responsible for ensuring that the project goal and objectives are met. Systems for monitoring and controlling the project are established early and can be found in such things as the project plan, communications plan and contracts.



Control, like quality assurance, is ongoing. It can be achieved by comparing the planned status of the project to its actual status, to then if necessary take corrective action. You may need to modify work, objectives and expenditure to complete the project successfully. This can involve making changes to the original plan, which is a normal part of managing projects.

The development of a project can be thought of as a cycle of monitoring, controlling and directing work. You can see this in Figure 1. It will be useful for you to refer back to this figure as you work through the topic.

Figure 1: Project monitoring and control processes

Monitoring progress to plan for deviation

All aspects of the project need to be monitored. In particular, you’ll be checking:

that all tasks are being completed as planned, on time and with appropriate quality

any deviations from the project plan are accounted for

that milestones on the plan are being reached on time

that contracted work is progressing according to agreements



where the major hold-ups are if the schedule is slipping; if enough slack has been allowed

any problems with costs; if cash flow is sufficient; if costs are affected by any slippage in the schedule.

Successful project management is a process of checks and balances. You are checking the flow of progress, and balancing where extra motivation is needed. Monitoring requires careful listening, watching, analysis and mutual support for everyone on the team.

You especially need to know of any deviation from the plan as soon as possible. You can use a number of tools or methods for this, which you’ll learn about in the next section. Everyone on the project team must have access to monitoring tools to clearly see the project status and direction; how progress and changes influence their own work and the work of others on the team. When monitoring reveals warning signs, the team can then work together to ensure a remedy.

Managing changesA project is often an agreement to develop and deliver a thing that hasn’t before been built or provided. The team must solve unfamiliar and unexpected problems. The risk in this must be managed. Some projects start to drift slowly off course, degree by degree. Other projects run completely out of control (but thankfully, not many). Many projects suffer the pain of a thousand frustrating changes.

Projects can change in structure, size and character. There can be modifications and wholesale changes to features, timing, budget, work plans, priorities and people on a project. Good management can sometimes control this. For example, if a project manager knows in advance that a delivery will be late the sequence of work on other tasks might be adjusted so that the project schedule isn’t affected.

Some changes are unavoidable and unpredictable—if a key programmer on a software project suddenly falls ill at a critical time, all you might do is send a get-well card and start looking for a replacement! As you watch the project progress, there will be many incidents, concerns, and an array of problems that creep into the work. They all need to be managed.

Monitoring and control measures, while sometimes annoying, can have a positive side. As work goes ahead, the team can use them to find newer and better ways of doing things that were not obvious when the project plan was drafted. Shortcuts and other efficiencies can compensate for losses elsewhere.



Change and risk assessment

Some known risks to project success will have been identified and assessed in the planning phase. Yet mistakes and unexpected things can happen at any time once a project is underway. What’s more, changes that you make can expose new hazards! Power cuts, temporary loss of access to the Internet, illness, loss of staff to another more urgent project, hardware failure, even bad weather—are all largely unpredictable events.

Constant risk awareness and trust

The project manager needs to daily appraise the team’s readiness to avoid or respond to problems. A manager should try to get a clear assessment of potential risks at team meetings. Getting warning of risks is more likely if team members are comfortable reporting individual difficulties, rather than hiding them and hoping they will evaporate. Team members should be secure in the knowledge that if they draw attention to problems they will not be criticised.



Methods used to monitor projects

Ways of monitoring the project’s progress should be set out in the project plan and should include:

discussion with members of the project team

getting regular reports from team members

actual observation of work in progress

taking measurements and comparing them to the plan

using project management software and other tools to produce reports

review of all reports and documentation

feedback from users and stakeholders.

Team communication and gathering project dataYou’ll need to establish concise guidelines for getting the information you need from your team members. Details of a communication plan may include:

by what means you’ll get feedback from staff and contractors

the reports that will be collected and distributed

the frequency of meetings

how progress will be reviewed and reported

any other documentation that needs to be created.

Meetings and forums

Commonly, communication with team members will be via email or group-ware. However, regular meetings (which can also be held by phone conference, video conference or on-line), are also an important way of gathering information.

Successful meetings need good planning, such as plenty of notice and detail about what will be discussed. This gives team members an opportunity to prepare their contributions. Project team meetings should be held mainly to:



share information

solve problems

make decisions

evaluate various aspects of the project.

Progress should be discussed, as well as documented. Progress meetings give the team a forum to interact with people with whom they may not otherwise have regular contact.

Typical agenda items might include a discussion of:

handovers (where finished work is reported and new work allocated)

schedules

individual workloads

the status of deliverables and milestones

the status of contract work

delays (causes and strategies to deal with)

changes and how they will be implemented.

Walking around

Frequent personal contact with team members is one of the best ways of getting information about what is happening on a project. Management by Walking Around (MBWA) can be highly effective at gathering data and testing its validity.

One idea behind this is that in most interpersonal work situations, such as a project, most of the time you only see what the other person wants you to see. Since they know your expectations, they will manage their presentation to satisfy you. On the other hand when you walk around, you get to see what people are actually doing.

You can practice MBWA by:

consistently making time to visit project team members and being available for impromptu and informal discussions

getting away from your own desk, and learning first-hand about problems and concerns

mentoring team members with new methods to manage particular problems.



Collecting and collating information

Collecting and collating information about a project is one of the many crucial jobs the project manager must direct. In an early team meeting, the group will decide:

the extent or scope of measurements to be recorded

who captures each element of detail about the project

how each measurement is to be made

when the information is captured

how to store results (electronically or in hard copy)

where to store data

what format to use for the data.

Information from team members, suppliers and contractors must be constantly checked, analysed and confirmed. In the project planning phase estimations for likely costs, probable task times, expected scope, anticipated delivery dates and so on, will have used the best numbers available. As the project moves forward, those numbers are adjusted using information gathered by the team as to actual numbers.

Progress indicators and measurement

Choosing the right indicators of project progress is essential to evaluating progress. Indicators need to:

be relevant to the particular project

be easily understandable to everyone interested in the project

be easily measured

provide reliable information.

An indicator can be as simple as a list on a whiteboard showing the date and the work that should be done that day, or as complex as a statistical comparison of one project with another.

Quantitative indicators use some sort of numeric measurement (it’s easy to remember this as it has ‘quantity’ in it). Examples include the number of faults per 1,000 products produced, the number of dollars expended, or the number of people working on a task.

Qualitative indicators are more subjective, and refer to feelings and descriptive judgments. For example, if you’re working on one of the project tasks, you might say that progress on the task was ‘slow’, or ‘we’re really making great progress’—which would be a qualitative assessment.

Progress can be measured in different ways by different specialists. An accountant may be mostly interested in financial aspects. A programmer



may be interested in the number of lines of code finished. The head of the department, with three other projects waiting to start, may have time as their main interest.

Most of the indicators in a project should have been firmly decided in the planning stage. There may also be legal requirements, or particular client specifications that make measurements an important part of monitoring progress. For example, you may have a certain number of files to create, or web pages to develop, or rooms to install, etc.

Measurements are tangible evidence of what’s happening in a project, while providing a measure of progress can be difficult for project team members. Programmers and technicians, for instance, when trying to solve complex problems, might be distracted from problem solving by having to measure and record progress.

Ways to make measuring and recording progress easier, and to ensure it is meaningful, include:

motivating the team on the value of measurement

reducing the amount of work they have to do to capture vital statistics

showing the team how their measurements are used to bring the project to success

identifying when facts and figures are best gathered and collated.

Sample measurements (metrics)

The word ‘metric’ simply refers to the particular measurement being used, and any useful value in a project can be used. The dashboard of your car is a good way to think about metrics. It provides you with useful information such as how fast you are going, how much petrol you have in the tank, even sometimes how efficiently your car is running. In the same way, you should use metrics that give you information about how your project is going.

Some examples include:

staffing levels (comparing estimated and actual)

percentage of tests that have passed/task completed

estimated versus actual duration between major milestones

the number of tasks planned and completed.

Percentage completion

Percentage completion is an often-used metric. We can apply this to particular tasks, or we can use it as an indicator of the total number of tasks that have been completed, depending on the way the project is structured.



An example is illustrated in Table 1. A graphics company has a contract to produce 500 images for a training project. Each image is designed, drawn, checked, corrected and checked again. For any one image (or group of images), you could specify their status as a percentage completed. If the design is finished, you could say that this task was, say 25% complete. Similarly, you could record this for each image and summarise it in a spreadsheet. Or you might be interested in how many of the images were completely done. For example, if 250 of the images have gone from design to the final check, a useful measure of progress would that the entire project is 50% complete.

Table 2: Project progress (100 graphics per set)

Graphic set Percentage complete This is a simple example, but illustrates the use of this type of indicator.

See Table 2 below for further explanation of this method.

A 100%

B 75%

C 50%

D 25%

E 10%

Benchmarks and objective measurement

A benchmark is a comparison against which project progress can be measured or judged. Project managers sometimes measure performance by accepted industry standard benchmarks. Comparing one project with a similar project can encourage practices (best practice) to improve performance. There is no fixed rule for benchmarks.

Data capture needs to be objective—what you collect, and how you test the data should not be distorted by personal bias. As a particular example, project team members may be embarrassed about tasks taking longer than they should and therefore may report further progress than is the case.

Periodic reportingThe usual way to monitor and track progress is through a system of periodic reporting. Typically, this type of report identifies the status of every activity in the project for that period as well as for the entire project. Variations from the project plan can then be picked up by using information on activities and resources. These sorts of reports can greatly help in making decisions because they are usually in a concise format and are easy to read.

Variance can be both good and bad. Being ahead of schedule at any phase and under budget is music to the ears of project managers and stakeholders. Positive variances usually allow some replanning that could bring the whole project in ahead of schedule, under budget or both. Negative variance on



task time is bad, but in most cases this will only affect the project completion if tasks that are on the critical path vary.

Figure 2 shows a variance report.

Figure 2: Example of a variance report

It is very easy to get carried away with reports. The project manager must balance the rigidness of a tightly monitored project with the need for flexibility and creativeness.

Reports are discussed in more detail in the final section of this reading.

Monitoring tools and software

Software available

There are some obvious well-known packages available, including Microsoft Project, which can be used for monitoring projects. There are a great many more. When last checked the site http://www.project-management-software.org listed 233 different programs to help monitor and control progress in a project.

Software can be expensive, so you need to first consider:

the scope of your project?

the system you have in mind for the software to work in

how much training is needed

how much effort is needed to get the software up and running


http://www.project-management-software.org/

http://www.project-management-software.org/


if it is compatible with your existing software

what maintenance and support will you get from the vendor

if you will use the software again, after this project.

After considering these issues, especially for a simple project, you may find you’re better off using tools you already know such as word processors, spreadsheets and database software.

Using a spreadsheet to track progress

The following example of the basis for a spreadsheet to track progress builds on the example in Table 2, where the project involves creating 500 graphics. You’ll need the following information to understand the table:

there are different ‘weights’ applied for each of the graphic development stages

the stages are design (25%), drawing (50%), checking (10%), correcting (10%) and checking again (5%); seen in the first row.

Table 3: Tracking progress using weights (100 graphics per set)

Graphic set

Design25%

Draw50%

Check10%

Correct10%

Check5%

Percentage complete

A 100% 100% 100% 100% 100%

25% 50% 10% 10% 5% 100%

B 100% 100% 100%

25% 45% 5% 75%

C 100%

25% 25%

D 40%

10% 10%

E 100% 50%

25% 25% 50%

Total 52%

To look at set E: You can see that the design phase is 100% complete. However, the design phase only represents 25% of the total work for this set of graphics, because they have to be drawn, checked, and so on. You can see that the actual drawing stage for this set is half (50%) finished. To multiply that 50% by its weighting of 50%, gives 25%. Overall, the development of set E is 50% finished.



The percentage total of all the sets, once averaged, can give a percentage figure for overall completion.

You could add other columns and calculations to a spreadsheet like this, such as estimates for the number of hours planned for each phase or set of graphics and actual hours spent. From these, you can make comparisons; calculate costs and so on, to use this as a tool for controlling the project.



Controlling the project

Any changes to a project that are needed, as revealed by monitoring progress, or having fallen from the sky—will have to be managed and approved. Corrective action may range from using more resources to manage a task, to rescheduling an entire project.

Control tools and methods can include:

rescheduling where required

adapting resources where necessary

delegating tasks

changing priorities

changing objectives where necessary.

Schedule controlSome hints for keeping the schedule under control are first that it is a reference point for all members of the team and stakeholders, and that:

project tasks, events and issues should all be linked to the schedule

the schedule should be reviewed in each team meeting

the schedule should be updated constantly (even daily, depending on the project)

progress should be marked on the schedule, and be clearly visible to the team

comments and feedback on the schedule should be sought.

Schedule slippage

Slippage is the amount of time a task has been delayed from what was originally planned.

A common practice is to build in ‘float time’ (also called ‘slack’) to help deal with delays. Float is the difference between the time available on the schedule for performing a task and the time required to complete it. In other words, you estimate that, with the right resources, it should take you two days to install cabling, but you include three days in the schedule. This gives you one day of float time.


http://www.pmforum.org/library/glossary/PMG_C03.htm#Complete

http://www.pmforum.org/library/glossary/PMG_T02.htm#Time

http://www.pmforum.org/library/glossary/PMG_T00.htm#Task

http://www.pmforum.org/library/glossary/PMG_P01.htm#Performing


http://www.pmforum.org/library/glossary/PMG_T00.htm#Task



Measures to control slippage include to:

identify which tasks have slipped behind schedule

work out how much slippage has occurred, as well as the percentage of the original time that has been lost

try to define a best case and worst case scenario for slippage

identify other tasks that will be affected by work running late

discuss with the team ways to put the schedule back on track

create contingency plans

reach a team consensus on the best decisions to take as a result of running late.

Task and team management

Delegation

To delegate, put simply, is to hand responsibility for a task to another person. Some managers are reluctant to do this. You may know some people who have problems delegating. Wanting to do everything themselves, jobs don’t get done, or too much time is spent on lesser tasks, with important tasks neglected.

Good delegation is done in three basic steps.

1 Assign a function, a responsibility or a task to someone.

2 Make sure they have sufficient authority to do the job.

3 Get commitment from the person to do the job properly.

It’s easy to see from this that project work itself is essentially a delegated responsibility.

Setting priorities

Most project managers have to be good at multi-tasking, but there are times when some of the jobs have to wait their turn. Some time management techniques are useful, like each day, coming up with a new task list. The list will probably include jobs that are now overdue, so the list gets longer, the older the project grows. When this happens, you’ll have to shuffle the list so the most urgent and most important jobs get first priority.

However, your priorities may be different from those of others. Different stakeholders can hold conflicting views on the order of importance of tasks. It’s important for the team to stay flexible and reach agreement on re-scheduling decisions.



Communication

Communication is important for sharing information and persuasion. You’ll need to be able to change people’s opinions when appropriate, motivate team members and influence their work, to have control.

As discussed before, you need to consider:

what information should be distributed to different stakeholders,

the most effective methods of communication

how frequently to communicate.

Again, balance the value of information supplied, with the cost and time it takes to assemble, process and distribute. The objective should be to share sufficient information with team members who need data to solve problems, make good decisions and integrate work with others.

Keep the focus on learning and not blame

While recognising that the project team has been chosen because of their skills, experience and potential, you need to also recognise that mistakes can happen. Controlling the situation isn’t helped with finger pointing and a culture of blame. People won’t give of their best if they constantly need to look over their shoulder. Experts tell us that workers when they’ve made an error are willing to put their hand up and accept responsibility, if the group focuses on learning rather than on criticism.

Quality controlQuality control includes checking, measuring testing and auditing to prove that the results of the project comply with the agreed specifications or the desired level of quality.

Firstly, you’ll need to have planned for quality. In a larger organisation or project, there may be a quality assurance framework, which defines how the project’s quality will be managed, project methodologies to be used, standards and guidelines to be followed and how the project is organised and structured.

During the project you’ll need to conduct quality control activities such as reviewing, testing and so on, and this should be continuous. There should also be pre-defined quality control checkpoints, where the deliverables from one or more project tasks are examined in detail.

Just as you have to take corrective action to counter scheduling problems, you will also have to take steps to address defects, non-conformities or any other issue identified by the quality control process. In turn this corrective action may include changes to the project plan, the quality assurance framework, methodologies and even standards and guidelines.



Control tools and softwareProject management software, as discussed in detail in Learning Pack 4: Use Project management tools, is extremely helpful with the development and management of the project’s schedule. You can simply enter your work breakdown, resources, time estimates, etc, and the program creates a schedule for you. Such things as slippage and float can all be easily calculated, with alternatives presented.

As mentioned in discussing tools to monitor projects, project management software can be expensive, so you need to first consider a range of issues before if your project requires it.

A starting list for where computers can aid project control would include:

data entry and automatic data collection

manipulating data and providing alternate views

resource management and stock control

budgeting and cost control

group communication

tracking of data

printing and graphic illustration.



Assessing and implementing change

Change happens!

Work runs late in projects…

Tasks are more difficult than expected…

The client asks for features to be added…

Unforeseen project problems occur…

Costs change due to market conditions…

Workers leave…

Dealers run out of the old model of a product and want to supply a new improved version in its place…

It is the project manager’s job to monitor what’s happening and make decisions based on this. It can be quite a juggling act to shuffle things around. However, a project manager needs to distinguish between shuffling to control or manage day-to-day changes, and the sorts of changes that might require a re-think of project objectives or scope, or even the need to renegotiate a contract.

Changes to project scopeA client may want a small addition to hardware, a different software version, or change the number of files they want developed. Alternatively, someone on your own team may identify technology that would vastly improve outcomes of the project—something not foreseen during the planning. Or project problems may occur when something simply isn’t working, which requires major change.

The need for changes like these, are in fact, quite common, particularly in IT projects, where industry changes are rapid, and in projects that are covering new ground. Changes like this can alter the original specifications or project scope, and must be carefully and systematically controlled.

Project problems in general

If any project problems occur, no matter how small, the team need to be involved to:

document the problem



choose one solution from a range of solutions (beware of jumping to the first solution that comes along)

make a plan to implement the solution

if needs be, document the problem and solution and any ways that the project or its specifications are affected (in which case the project scope is affected).

Renegotiating the contract

Changing the specifications for a project, or altering details is, in fact, changing the contract that has already been approved. If a change affects the time, costs, quality or scope of a contract or project outcome, the terms of the contract may need to be renegotiated. Costs might have to be added to the payments, or renegotiated. Delivery schedules may need to be adjusted.

You should be able to use the project plan as the baseline to identify and control changes. In most corporate settings there may need to be liaison and communication between the project manager, the contract manager, the accounts payable clerk and the supplier, to cover all consequences of changes to contract requirements. Payment is only made when deliverables meet requirements.

Steps in change controlWithout a strictly negotiated process to evaluate the need for and impact of changes, the business case and associated project plan can be disrupted, and so cause drastic rescheduling of tasks or even rescheduling of the entire project. In this context, changes can be internal or external.

Internal changes are often those that arise in project development due to:

misinterpretation of requirements

errors of principle or fact

estimation errors

invalid logic

technical issues that could not have been foreseen in planning.

External changes arise through user or client decisions, oversights, new ideas, requirements of other projects and so forth, and were not part of the original specifications.

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



Some change control criteria

Sensible change control requires:

that all changes be requested in writing and submitted on a form for approval by a change control team, usually made up of key stakeholders and the project manager

identifying that a change is necessary and making sure that the change is beneficial to the project

that changes to the product scope are reflected in the definition of the project scope document

that all changes must be reflected in measurement of performance criteria for the project

determining that a change has taken place

management of the actual change.

Documentation is vital. Usually, one change leads to many more, so it’s important to manage this process carefully. You need to:

record reasons for changes

document the consequences of a change

make sure the changes are agreed to before they are put into practice.

Above all, it is important for everyone to realise that it is much better to negotiate around a conference table than drag everyone to court. The courts should only be used as a last resort.

Control of change involves three key steps:

1 Request for change

2 Evaluation of the change request

3 Decision and acceptance.

The request for change

All requests for change must be in writing, no matter the source, otherwise control is lost. Usually this is done via a brief memo to the project manager, and includes:

the originator’s name

date of request

description of the problem addressed

description of the change

justification for the change.



Evaluating the change request

The project manager liaises with other people, such as project team members, or professional users, to evaluate the change, to ask:

Is the change justified?

If justified, is it essential that it be made at this time or could it be deferred until later?

Does the change alter the business case of the project?

Which tasks are affected? Those completed, in progress, or to be commenced?

What is the estimate of duration and work effort required to implement the change?

Will it require rescheduling of the project and/or extension of the completion date of the project?

Will it require additional resources to carry out?

Does the change impact across sub-projects or systems?

Does the change require an alteration to the project development strategy?

Does it alter the complexity and risk of the project?

What risks are involved, whether the change is implemented or not implemented?

The results of this type of evaluation should be added to the memorandum requesting the change.

Decision and acceptance

The change is likely to be accepted if the project manager has no doubt that change should be made at this time, providing it will not:

require additional resources

alter the complexity

change the business case

extend the completion date of the project.

However, if any of these conditions is affected, the project’s steering committee (if it has one) will have to be involved.

If there is some doubt, or if the change is extensive, the project manager calls a meeting of interested parties, including the requester and evaluator of the change. At this meeting all aspects of the decision are discussed and a recommendation is made to proceed or act otherwise. This recommendation, in turn, may be referred to system and/or user department management for confirmation and approval by a steering committee.



Again, decisions need to be passed back in writing to the person who requested the change. As it turns out, proposed changes can end up being scheduled as a planned enhancement.

Policies and procedures

Remember that any changes that you receive and recommend must be documented in accordance with any relevant policies and procedures. Depending on the size and nature of your project, this could include:

Legislation (Federal, State and local) affecting the organisation’s administration, such as:

– public sector management Acts– financial management and accounting law and regulations– privacy legislation.

Government and organisational guidelines and procedures relating to:

– project governance– resources– security– strategic plans– recruitment– risk management– procurement guidelines– designation approvals

Industrial agreements.

A drastic example! Customs cargo system delay

Sometimes it takes an Act of Parliament to control a rogue project! The Australian Customs service required new software to manage massive quantities of goods flowing through Australian ports. There were substantial penalties in the contract, if the project ran late.

The project ran late. Users were concerned the program hadn’t been tested rigorously enough. As part of the change management process, Parliament had to pass an Act to amend the first Act, allowing the developers more time.

This was reported in the June 2005 Computer World magazine. If you are interested, visit the computer world site and read more. You should be able to find the article from several keywords in the above paragraph at http://www.computerworld.com.au

Change control example

Table 4 is a simple example of change control procedures in a real project.


http://www.computerworld.com.au/


Table 4: Change control request form with approval/denial details and statement of impacts on the project

Change request number: 152

Project name: Flash!

Date: 15/2/2005

Requested by: Rod McCleod, Sales and Marketing Manager

Phone: (02) 9784-4501

Change requested:

Add a new report that lists customer preferences from the customer management database.

Reason for change:

To provide information to the marketing department to assist with product development.

Approval/denial details

Approved: YES/NO

Conditions for approval:

None

Approved by: Luke Long, Project Manager

Date: 28/2/2005

Signature: (L. Long)

Reason for denial:

Impacts on project

Technical: None

Budget: $2800 increase

Schedule: 2 days

Outcomes: An additional report

Other projects: None



Reporting

Reporting is an important part of project management. You can think of it as a means of collecting and summarising data, as a communication tool, as a way of controlling a project, a tool for documenting project activities, and so on. For this reason we give it a section all on its own!

The three main types of regular project reports are:

1 Status reports

2 Progress reports

3 Forecasts.

Status and progress reportsBasically a status report describes where the project stands at a specific time, and in relation to control of scope, time and cost targets. A status report is based on comparisons such as:

where the tasks are in relation to due dates

where the budget and cash flow are in relation to estimates for this period

how close specification conformance and quality are

whether resources are over or under used.

It’s important to remember that too much status information is not necessarily a good thing, so keeping these reports simple and easy to read is the key to making the process effective. It is often recommended that status reports should be kept to one page in length and should include charts and headings to make reading easier.

Who should see a status report?

Next, it’s important to regularly distribute the reports to the right people. Stakeholders always have an interest in project costs as well as the progress of the overall project activities. Project team members need to know about task completions and progress against task lists. The main audience is the client and those working directly on the project. Other stakeholders are the secondary audience.



As an effective project manager you will use good communication skills to determine who needs to know what and when they need to know it. But first you have to gather the information to build your reports.

Creating a status report

Generating status reports is a two-stage process. Firstly team members are given a template of a progress report (discussed next) that they are to complete according to a schedule. You will then summarise all the information on these periodic progress reports and submit the appropriate status report to key stakeholders and functional managers.

Information should include progress against milestones, budget information, changes, quality guidelines and issues (both technical and project issues).

These reports are used to identify delays in activities, issues that team members are facing, and also risks. From this information you can create contingency plans and make any necessary changes to the overall project plan.

Progress reports

A progress report describes what the project team has accomplished during a certain period of time. It is common for projects to require team members to prepare a short monthly or weekly progress report. This type of report focuses on what the team members are actually doing. With each report you can look back and see how far you have come in your tasks.

Figure 3: Simple sample template for a team member progress report

Report design depends on what that the project manager feels key stakeholders need to know. A progress report, such as that in Figure 3, usually lists:

completed activities

incomplete activities (that were supposed to be complete, but are not)

activities in progress.



Summarising progress information in a report

After collecting progress information from individual team members, the project manager now has an idea of the current standing of the project, and should be able to prepare a report containing:

a list of completed activities

a list of incomplete activities

a list of activities in progress

an updated Gantt Chart

a list of issues still requiring resolution.

The summary report could also contain:

a summary of any new issues that have arisen

change requests that have been incorporated and integrated.

Reporting project status

The summarised information can be used to update the network diagram, the Gantt chart and alter the critical path if necessary, and comparisons can be made with the original plan or baseline schedule. In this way, team members and stakeholders can be informed as to:

how the project is progressing

if the project has the potential to fall behind

any lag times that need to be taken advantage of so that the project does not fall behind

any contingency plans the have been created.

Reports are a strong means of communication with team members.

Although meetings are the most effective way to communicate with a team, sometimes time does not allow for them. Instead, a status report, for example, and an updated Gantt cart can be distributed to all team members and stakeholders showing the changes in the durations of activities.

This can also be seen as a measure of personal and team performance. Each team member can evaluate their performance and see how the schedule is affected (if it is affected) by their performance.

Forecasts

Forecasts are a different type of report. So far we’ve been concerned with what has been planned, what is happening and how this compares with the plan. Forecasts are reports that predict trends for the project status. This style of report focuses on movements the client most wants to know—will



the project be finished on time, and will it work the way the contract stipulated? The forecast flags any need to revise client expectations, any trade-offs that may have to be made – for example, will the new operating system have to go to market without the promised security features.

Structure and format of reportsThe different reports can vary from a simple template to comprehensive and detailed information. There may be organisational, project, or other guidelines to determine the specific form of documentation. However, there are some specific formats for reports that are worth mentioning here.

Exception reports and variance reports

Exception reports take many formats, but basically they are only generated when something is outside of a previous specification tolerance. In most cases an arbitrary level of 10% variation from performance will generate an exception and cause a report to be produced. This applies to cost as well as time measurement criteria.

A variance report is a simple status report, which provides a snapshot of the project or any of the activities of the project. Figure 4 has another example, this time a variance report of project costs in a line graph, which gives a quick visual representation of performance variation and trend.

Figure 4: Sample of activity variance report for project costs (line graph)

However, the variance report doesn’t show how the project reached this status. It is merely an indicator of performance against plan. The same format can be used to report variance on the project as a whole as well.



Gantt charts

Although simple variance reports show budget and exception variations from plan, they don’t tell the whole story. A Gantt chart is one of the most convenient, most used, and easiest to represent project activities at a glance. Using Gantt charts is discussed in detail in Learning Pack 4: Using project management tools.

Templates, checklists and document controlMost of the fact-finding and reporting needed in project work has remarkable similarities from one project to another. When designing a form for collecting data, it is so easy to overlook the obvious items. So, instead of staring at a blank sheet of paper and wondering what forms to use, start by standing on the shoulders of those who have gone before you. Many web sites committed to excellence in project management have tried and tested reports and data collection templates that you can download.

Checklists

It’s also useful to create and use checklists to make sure that important issues aren’t missed when controlling the daily, weekly and monthly operations of the project team.

A checklist is a good memory-jogger. Even experienced pilots use checklists before flights to double check they haven’t forgotten a small but essential task. Again, start the design of your checklists by looking at samples from successful projects, and then modify them to your needs. (See the Resources section for where to get project templates and checklists).

Document control

In a project, you will often end up with countless documents and versions. As a project manager, you’ll need to make sure you and all of your team are aware of appropriate guidelines for naming, storing, and versioning the sometimes huge array of documents produced throughout the project. Apart from this, you’ll need to make sure that the correct version of key documents is delivered to key people and that there is some proof of receipt. Key documents could include, but are not limited to:

contracts

specifications

drawings

schedules

reports

important correspondence.



Summary

Once a project is underway it has to be carefully managed so that it remains on track according to the project plan. This requires monitoring and controlling. In this reading, you have looked at monitoring and control processes.

Monitoring a project largely involves keeping an eye on key activities by talking to team members and collecting useful data. For various reasons, projects can and do deviate from the best laid plans.

Managing the project means being able to take corrective action when it is required. There may be major changes that were not foreseen when the project was planned, so managing such changes is part of the project manager’s job.

Finally, we discussed different types of project reports and how they are used, and the value of using tries and tested templates for project management forms and checklists.


manage project progress -...

Documents