RSS Feed for the unit Implementing the project

Introduction

The Open University — Wed, 18 May 2011 10:08:30 GMT

This unit is from our archive and it is an adapted extract from Fundamentals of Senior Management (B713) which is no longer in presentation. If you wish to study formally at The Open University, you may wish to explore the courses we offer in this curriculum area.

The focus of this unit is on implementing a project. The first part considers how the activities of a project start. Although planning and action run side by side, it is often difficult to initiate action to progress the first tasks. Once things start to happen, the project enters a new stage. Management of the project changes, from stimulating the initial action to monitoring and reviewing it in order to control the project's progress. Control systems are essential in managing a project of any size, to ensure that the project achieves its intended outcomes. It is very rare for a project to run smoothly, however, and anyone managing a project can expect to have to keep up the momentum and to solve problems that arise. Good communications contribute a great deal to the process, and help all the stakeholders in developing a shared understanding of how the project is progressing. This unit addresses each of these considerations in turn.

Original Copyright © 2007 The Open University. Now made available within the Creative Commons framework under the CC Attribution – Non-commercial licence (see http://creativecommons.org/by-nc-sa/2.0/uk/).

Learning outcomes

The Open University — Wed, 18 May 2011 10:08:30 GMT

At the end of this unit you should be able to:

contribute to the implementation of project activities;
monitor, and recommend adjustments to, activities, resources and plans;
maintain communications with project stakeholders;
contribute to developing solutions to project problems.

1.1 The transition from planning to action

The Open University — Wed, 18 May 2011 10:08:30 GMT

In working on a project, it is sometimes difficult to make the transition from planning to action. It usually falls to the manager, as leader of the project, to make sure that activities are started; but not before it is clear who should carry out which tasks, and when. The first step for the project manager is to ensure that the plan is communicated to those who will be working on the project. It is not always safe to assume that others will understand the plan or its implications, particularly in terms of what they should be doing to make it happen. Plans are often focused on time-scales and schedules. If you have used computer-based packages to develop a plan, at a high level of detail, that plan can be difficult for others to interpret. Consider the following example.

Example 1: Understanding the plan

I was asked to review a project which the client suspected was not under control. This was a four-person project which was scheduled to finish within 8 months. I walked into the meeting room where I had agreed to meet the project manager and was surprised to find him putting together a matrix of four by four project schedules which he had just printed out. There were sixteen A4 sheets in total – certainly impressive!

We discussed the intimidating-looking schedule for a while: I don't think either of us understood it. We then moved to the whiteboard. An hour later we agreed on a schedule fitting onto one side A4 – at that point we started making progress.

(Craig and Jassim, 1995, p. 26)

Make sure that the key people responsible for taking action on the first tasks understand what is needed. You may need to check that all the procedures have been gone through to secure their commitment to the project, and it might be necessary to issue a formal instruction to start work.

1.2 Defining team responsibilities

The Open University — Wed, 18 May 2011 10:08:30 GMT

Depending on the size of a project, responsibility for each key stage may need to be allocated to a member of the project team. Clear allocation of roles and responsibilities for tasks and key stages ensures that each piece of work is ‘owned’ by a particular person, and that overall responsibility for the work is spread appropriately between members of the team. Establishing clear lines of accountability for each team member is important to give them:

a role in the overall plan;
authority to act on behalf of the project;
a sense of commitment;
an understanding of your expectations;
responsibility to report to you on progress.

1.2.1 Target dates

The Open University — Wed, 18 May 2011 10:08:30 GMT

The overall plan will indicate the start dates for each group of activities, or each task. A useful way of focusing activities on achieving outcomes is to provide clear dates for completion of stages and of final outcomes. If there are a number of different types of team, these may start and finish tasks at different times. Where the work of one team depends on another having completed in time, there are important issues to consider. Although a good control system will provide information about progress on the tasks, the relationships between the people in the teams can have a profound influence on the process, with the potential to add considerable value or to cause considerable disruption.

Activity 1

0 hours 15 minutes

Think back to projects in which you have had a part. From your experience, note in your Learning Journal (click here to learn more about using the OpenLearn Learning Journal) some of the ways in which you have seen teams add value to a project, and some ways in which projects can be disrupted by lack of co-operation between teams.

Discussion

Value can be added at any stage of a project, if teams focus on delivering the best that they can to their customers. In some cases the immediate customer of one team may be another team, who develop the project on the basis of the first team's work. As with any customers, finding out more about what they really want and delivering the best that can be produced within the scope and budget of the project will add value. Teams that achieve all that is required of them within the resource limitations and hand over their part of the project helpfully also add value. Value can be added by applying what has been learned from working on the project to improve working practices. New skills can be developed through project work, including team working, supervision, coaching and peer support. You have probably thought of many other ways in which value can be added.

Teams also have considerable power to disrupt. They can delay work so that their tasks are not completed on time, they can work carelessly and produce work of a poor quality. They can allow personal interactions to cause conflict and stress. They can adopt attitudes that present a poor image of the organisation to external stakeholders. They can simply behave badly.

1.3 Motivating and preparing staff

The Open University — Wed, 18 May 2011 10:08:30 GMT

Motivation is important. In resourcing the project it may be worthwhile to build in a reward system that helps to motivate. This depends on the availability of the resources to make this possible. Even if the material rewards are good, the conditions in which staff work and the relationships between them always affect performance. A project manager is often able to influence conditions and culture. The tasks allocated to staff must be realistic and achievable, and it is helpful to agree these with teams or individuals. Staff often have to retain other workloads whilst working on projects, and it may be necessary to negotiate with senior managers to ensure that project staff have sufficient time and energy to do what is required.

New skills and understanding may need to be developed, in order for new tasks to be carried out. Sometimes staff are allocated simply because they have time to work away from their usual duties, even though they may not have the competence to carry out the project tasks. The manager of the project may have to arrange for training and support, whether or not this was anticipated in the initial planning.

Once staff have agreed to carry out their tasks, it is helpful to check that they understand how their contribution fits into the bigger picture. There is an opportunity to develop a project ‘culture’ of collaboration towards a successful goal. The boundaried nature of a project makes it possible to create a distinct culture that emphasises the positive aspects of the environment in which the project is located.

1.4 Resourcing the project

The Open University — Wed, 18 May 2011 10:08:30 GMT

Work will be delayed if the necessary materials and equipment are not readily available, or if the accommodation for the project has not been arranged. Although the project manager is responsible for overall resource allocation and utilisation, much of the work can be delegated. By conferring responsibility to achieve an outcome within the budget, more direct links between costs and outcomes are established. In most projects there will be organisational internal controls and statutory requirements to manage resources, for example in handling money or other materials. In setting up the project responsibilities it may be necessary to identify people with particular qualifications or experience to manage specialist areas of work. Even when all the necessary physical resourcing has been agreed and planned with a sufficient budget to enable it all to happen, it will often fall to a project manager to take care of practical details and to encourage everyone to take action.

Activity 2

Identify five steps a project manager can take to ensure that the tasks of a project start on time.

Discussion

These steps could include: recruit staff, allocate roles and responsibilities, motivate, reward, set objectives, provide training and support, arrange supervision, agree start times, ensure that accommodation is prepared, ensure that materials and equipment are provided, ensure that the plan is shared and understood, delegate responsibility for achieving outcomes.

2.1 Unique problems and constraints

The Open University — Wed, 18 May 2011 10:08:30 GMT

In an ideal world, projects would be completed on time, within specified budgets and to the standards set out in the plans. In practice, any project involves a set of unique problems and constraints that inevitably create complexity and risk. Plans are liable to change as work progresses, and each stage in the process may have to be revisited several times before completion. Projects do not exist in a vacuum: they often take place in rapidly changing contexts, and the impact of the changing environment on the life-cycle of the project has to be managed. In projects, new issues will emerge as activities evolve. In this section we discuss ways of monitoring a project as it progresses, and of identifying any emerging risks or potential for improvement, keeping activities in line with the plan or adjusting plans accordingly.

Attached below as a pdf is an example of a type of bar chart that shows progress to date and the amount of work yet to be done. To be valid, progress needs to be updated regularly.

Please click on the 'View document' link below to view the tracking bar chart. (PDF, 1 page, 15.0 kb)

View document

2.2 Monitoring as control

The Open University — Wed, 18 May 2011 10:08:30 GMT

To control you need a plan that indicates what should happen and information that tells you what is actually happening. This is monitoring activity. By comparing the information about actual progress against the plan, you will be able to identify any variations.

Control is an important part of project management. It involves:

reporting the progress of the project against the plan;
analysing the reasons for variance between progress and plan;
taking action to eliminate variance.

However sound your project plan, it is certain to need adjusting and updating as you go along. There are techniques that help to make this possible, and use of project planning software will often make the task much easier.

The box below shows the elements of project control:

a standard – the project plan
collection of monitoring information, primarily from team members
a mechanism for comparing progress against the project plan to identify problems
a process to identify the causes of problems, and to generate solutions
winning support and agreement to proposed changes to the plan
implementing corrective action, either to bring the project back in line with the plan or to change the plan.

It is also important to collect and analyse data to report back to stakeholders, who will remain involved in monitoring and negotiation throughout the life of the project.

View larger image

Figure 1 The essential elements of project control

Long description

Expect that, as the project progresses, there will be things that you will want to change within its boundaries. There will also be changes in the environment of the project, that will impact on the tasks and activities that are part of the project itself. Whenever a review of project progress leads to a decision to make a change in the plan, it is essential to record the changes on the plan itself so that a master plan is maintained that is up to date. If you always record changes to the plan you will maintain a ‘living’ document as the basis for continuing action.

2.2.1 Gathering information

The Open University — Wed, 18 May 2011 10:08:30 GMT

Successful control of a project depends on the flow of information, so it is important to have systems in place to make sure that you get feedback on what is happening. If the project team is meeting regularly to review progress, monitoring becomes more dynamic and changes to the plan can be achieved by consensus. Involving the team not only helps to keep everyone on target – it also builds commitment.

Monitoring is the most important activity during the implementation phase of a project, because it is the only way in which you can control the work to be sure that the objectives of the project will be met. To keep track of what is happening you may have to consider gathering information on two levels:

macro levels – to include overall business objectives, time, budget, quality;
micro levels – to include tracking individual tasks; that they have been initiated, that they are running on track and that they are due to complete as planned.

Project status reports and project status meetings are formal reporting structures that enable you to collect and collate this information. However, if you rely on others to provide all of your information you may miss early signs of difficulties – many experienced project managers make a point of ‘walking the project’ to keep in touch with the day-to-day issues that emerge as work progresses.

Activity 3

0 hours 10 minutes

What might you as project manager be able to monitor by ‘walking the project’ that you would not know about from formal reports?

Discussion

By keeping a level of informal contact with the most important activities you will be better able to monitor the atmosphere in which teams are working. You will be in a better position to judge whether the interpersonal relationships are creating productive energy or contributing to conflict and delay. You will be able to respond quickly if teams are facing delays because of failures in deliveries of materials or equipment. You will be more likely to notice if staff are being pulled away from the project because of other work pressures.

Control is only possible if you have a plan against which to measure progress. If the plan is clear about what should be achieved and when, it is possible to monitor progress to be sure that each outcome is of the right quality and achieved at the right time.

2.2.2 Milestones

The Open University — Wed, 18 May 2011 10:08:30 GMT

Milestones are measuring points that are used in reviewing the progress of a project. Milestones can be set in different ways, to reflect different purposes. For example, milestones are often used to provide an agenda for regular meetings which review the project. These reviews should take place, weekly, monthly or quarterly, depending on the nature of the project.

Another approach is to set the milestones to reflect key phases of the project. Sometimes such milestones are established in this way to enable reviews to consider whether the project should be continued or should stop at this stage. Some organisations take a more challenging approach and inquire at each review whether the project should be terminated, expecting an adequate defence to be made in terms of the continuing value of the project to the organisation. In Example 2 – Turning back at ‘tollgates’, this review stage was called a ‘tollgate review’.

Example 2: Turning back at ‘tollgates’

I was on a team developing a project for an international information technology organisation when the project was discontinued at a ‘tollgate’ review. The project was to develop and pilot a way of consulting about a new information system prior to developing the specification. The project had progressed through several previous reviews and had received approval and support, so we were not particularly worried about the response we were likely to receive at this next review. We prepared a briefing explaining how the event would be designed and we had provisional arrangements made to run pilot programmes in Sweden, Argentina and Greece. We expected the green light to confirm the arrangements and start within a month or two. However, we were all shocked to learn that the project had been discontinued at the tollgate review. Apparently, the strategy had been changed and the new system had to be introduced quickly and without consultation. The project staff were paid off and the project closed immediately.

(a manager from the Course Team)

2.3 Interdependency of systems

The Open University — Wed, 18 May 2011 10:08:30 GMT

The control system approach to project control provides a simple overview of the process of planning, measuring against the plan and taking action to bring things back into line if necessary. This suggests that events will move in a fairly linear way. Life is messier than this, however, and every time that something happens it will have an impact on everything else around it – so the interdependency of systems is important to consider.

Example 3: A symbiotic relationship

An organic rice farmer in Japan has ingeniously devised a good way to overcome pests. Takao Furuno's farming method has been called a ‘one-bird revolution’. Since its introduction ten years ago, it has been eagerly taken up by 10,000 Japanese farmers. Its simplicity adds to its beauty. It revolves around the duck.

Soon after the rice seedlings are planted, ducklings are released into the paddy fields. The ducklings readily launch themselves into their new habitat and eat the insects and snails that attack the seedlings. They also use their feet to dig up weeds to eat, and by doing so they oxygenate the water and encourage the roots of the rice plants to grow.

The amazing thing is that ducklings don't like rice seedlings – something to do with the silica content. Farmers adopting this new method no longer need to spend up to 240 hours per hectare in manual weeding every year; they can sell the ducks at market, and can increase the rice yield by between 20% and 50%.

Takao, who worked out his method by a ‘combination of contemplation, inspiration and experimentation’ has not patented his method, as he wanted it to be widely adopted.

(from ‘One bird – ten thousand treasures’, Mae-Wan Ho, The Ecologist, October 1999, reprinted in Resurgence, No. 199, March/April 2000, p. 15)

Activity 4

0 hours 10 minutes

A symbiotic relationship can be positive, or the impact that occurs when something happens can have a negative result. Think back to a project that you were working on and consider what examples there were of interdependency. Takao said that he used ‘a combination of contemplation, inspiration and experimentation’ to work out this method. How did you see the interdependency.

Discussion

You need to be alert to what is happening in different areas of the project. It will help you to identify potential interdependencies that could work either for you or against you. The sooner that these are identified, the sooner you can take action.

2.4 Project status reports

The Open University — Wed, 18 May 2011 10:08:30 GMT

Project status reports are regular and formal. You will need to decide how often they are necessary – depending on the size and nature of the project, it might be weekly, monthly or quarterly. In some situations reports might need to be hourly, if a problem is causing serious concern and has the potential to delay progress seriously. Daily reports might be necessary if there are implications for arranging work for the following day.

The degree of risk involved, and the time it would take to recover from failure to complete important milestones, are guides for deciding the frequency of reporting. Other considerations might include how quickly the project could get out of control, and the time it would take to implement contingency plans. The project sponsor may have a preference about the frequency of reports and review meetings.

To prepare the report, you will need to have information from the members of the project team on:

completion of delegated tasks;
completion of key stages;
any work that is behind schedule (and why);
any issues that need to be resolved (as soon as they arise);
any difficulties anticipated in the near future.

Some project managers find a standard reporting template useful, so that team members can see at a glance what you need to know and just fill in the gaps. A standard report might include:

the project title;
a brief description of the key stage covered by the report;
the name of the person responsible for this key stage;
the date of the report;
actual progress tracked against planned progress towards project ‘milestones’;
a summary of progress on this key stage, including explanation of any slippage and remedial action taken;
any issues awaiting resolution;
the milestones due in the next reporting period and the date of the next report.

Once you have set up a system for regular reporting you will probably have to make sure that it happens, at least in the early stages. Be prepared to chase up reports and to insist that they are necessary and must be presented on time.

Activity 5

0 hours 15 minutes

Read the following and then answer the question below.

Risk and contingency planning

Risk is the chance of something occurring that has an adverse effect on the project. Many risks can be foreseen and identified. For example, if the project involves development of computer-based systems, time needs to be allowed for ‘de-bugging’ once the systems are installed.
The main categories of risk can be summarised as:

physical loss of or damage to information, equipment or buildings as a result of an accident, fire or natural disasters;

technical systems that do not work or do not work well enough to deliver the anticipated benefits;

labour key people unable to contribute to the project because of, for example, illness, career change or industrial action;

political/social for example withdrawal of support for the project as a result of change of government, a policy change by senior management, or protests from the community, the media, patients, service users or staff;

liability legal action or the threat of it because some aspect of the project is considered to be illegal or because there may be compensation claims if something goes wrong.

In view of all these possibilities, the careful examination of the question below, early on in the project, can save a lot of (though not all!) problems later:
‘What could go wrong in this project?’
Having identified potential areas of difficulty you can then examine these by asking, in respect of each one:

How likely is this to happen?

How serious would it be if it did?

Having raised these questions, you can then consider what you might do either on your own or with a team. Some of the less likely possibilities and those that would really just be minor irritants may not need a lot of attention. Others could be seen as quite critical to the success of the project and you can, at an early stage, plan what to do if the worst happens.

What key questions do you think stakeholders would want you to answer when you prepare a report about the progress of the project?

Discussion

We think that the central questions are:

Is the project on schedule?
Is it within the allocated budget?
Have the milestones been achieved?
If not, what action has been taken to correct the situation?

Other questions may be appropriate, including whether problems have been identified and solved, whether experience so far has any implications for future plans, whether any additional resource is required or whether there is any need for revisions to the overall plan.

The information gained from project status reports will be helpful in compiling reports to stakeholders, but different types of report may be appropriate for stakeholders with different concerns. For example, the project sponsor may be most concerned with the overall progress against goals, but stakeholders concerned with only one group of project objectives may only want information about these. There may be confidential information to be shared within a limited group of stakeholders. Some stakeholders will only have an interest in the overview and the implications for the organisation.

Example 4: Overview and detail

A junior estate manager who worked for a conference centre reported a personal experience of reporting at a different level. He said, ‘I was asked to make a presentation to the Chief Executive about the re-location of our residential accommodation and I was very worried that he would ask me to explain why we were so far behind schedule. We had found asbestos in one of the ceilings and had immediately stopped work and called in specialists which had, of course delayed everything. In fact, all that the CE wanted to know was whether we were going to keep to the revised schedule now. He was very pleased to hear that we had asked the specialists to check all of the other rooms that would be part of this move so that there would be no more nasty surprises. It made me realise that in reporting at that level I had to give an overview and show that we could stand back from problems and look ahead to make sure that we achieved the main outcomes as well as possible.’

Reporting often raises issues for those who receive the reports. You may want to consider that people often react with questions at the level of detail that you have offered. If you limit what you offer to target the key concerns from each perspective you are likely to reduce the extent to which you have to smooth anxiety or deal with misunderstandings!

2.5 Project meetings schedule

The Open University — Wed, 18 May 2011 10:08:30 GMT

You need to decide early on what meetings are essential to the monitoring process. All your stakeholders will expect to receive reports at regular intervals, whether formally or informally. So you need to ask yourself:

Who needs to be informed?
About what?

How often?
By what means?

Effective communication involves giving information, collecting information and listening to people. To ensure the smooth running of your project, you might need any or all of the following:

formal minuted meetings which probably run to a schedule which is outside your control;
meetings with your sponsor (which might be on a one-to-one basis);
progress meetings with the project team;
individual meetings on a one-to-one basis with team members;
ad hoc problem-solving meetings when particular issues need to be resolved.

Meetings need a clear purpose and focus, and they should be recorded on project schedules. They should be time-limited and given proper priority in diaries, so that time is not wasted by waiting for inputs from key people. Meetings will only be respected if they are managed to avoid wasting time and effort.

Activity 6

0 hours 15 minutes

Use your Learning Journal to prepare an agenda for a project meeting for a recent project that you have worked on. What is the purpose of the meeting? Who needs to be invited to the meeting? What will their interest be in attending the meeting?

Discussion

In preparing the agenda, you might also consider what else you need to make available at the meeting. Will you do a slide presentation? Will you give the participants at the meeting copies of the overheads? Is a project status report going to be delivered? Will you need to provide a summary of the key points of this report? What questions might the participants ask?

2.6 Maintaining balance

The Open University — Wed, 18 May 2011 10:08:30 GMT

Monitoring is also concerned with achieving a balance of the three dimensions of the project:

cost – the resources available;
time – the schedule;
quality – the scope and appropriateness of the outputs or outcomes.

Many of the difficulties in implementing a project are caused by poor time management. This will have a direct effect on the costs of the project, as well as on the quality of what is achieved. So there need to be systems for monitoring:

the time spent on project tasks;
the resources used (people, materials and equipment);
compliance with applicable quality standards.

These are the three dynamics that are always key to keeping a balance in managing a project. There are a number of options for how you might take action to maintain this balance, once monitoring has provided you with information that suggests that action is needed.

Splitting the key stages to avoid each following another when there is no necessity to have one in place before the next: If it is possible to carry out two or more key stages concurrently, you will speed the project up, but you will need to resource all the concurrent stages rather than waiting for one to finish so that staff can be moved to the next stage.
Making savings by removing or reducing contingencies from estimates: as the project work progresses you could review the contingency time and budgets that had been estimated. You will be in a better position to judge how much contingency is likely to be needed as the project progresses.
Re-evaluating the dependencies in the logic diagram: You may have been over-cautious in making the first judgements about the sequence of activities. As some outcomes are achieved, you may find that you can avoid some of the dependencies.
You may find that you can make more use of slack time to speed up completion of tasks.
Avoiding duplication of effort: If you can minimise duplication you can make savings of time and effort.
Re-negotiating lengthened time-scales if an unanticipated problem causes a delay that cannot be recovered: If this is the situation, it is worth calculating whether lengthening the time-scale would be more cost-effective than increasing the resources to enable completion on time.
Increasing the resources available will usually increase the costs, so this should be considered alongside other options. It may be possible to increase resources at a limited cost by reviewing the use of existing staff. For example, instead of getting new people with appropriate expertise assigned to a key stage which is falling behind schedule, you may already have such people within the team but carrying out activities that have less need of that expertise.
If a project is facing serious delays or is running over budgeted costs, it is worth considering the quality targets. Reducing the quality or scope of specified outputs or outcomes may be possible. In considering this option, it is worth reviewing what quality means to each of the key stakeholders. Additional features may have been included in the project and these add very little value for the majority of stakeholders.

Monitoring expenditure is usually exercised through regular reports. In many organisations the financial aspects of a project would be subject to their usual financial procedures. There may be decisions to make about the number and levels of budgets, and about how frequently budget-holders should receive information about expenditure and reports on their current position.

2.7 Tracking progress

The Open University — Wed, 18 May 2011 10:08:30 GMT

Gantt charts and critical path diagrams are useful for tracking project activity and for making necessary changes to the project plan. Project-planning software may also be used; the original chart is kept as the standard and any modifications are superimposed.

The example of the joint strategy for commissioning training services demonstrates how tracking produced information that led to a change of plan.

Example 5: A joint strategy for commissioning training services

Amanda drew up a plan for developing a strategy for commissioning training services for a large public service organisation. Three different approved agencies were involved. Completion of the key stages of the project went according to schedule up to the point when the first draft of the joint strategy was issued to each agency for consultation (22nd September). Five weeks had been allowed for this consultation, and a further two weeks for the lead manager within each agency to produce and send a written response to Amanda.

Three weeks into the consultation, Amanda contacted the lead managers to confirm that they would be able to meet this schedule. Agencies A and B were confident that their responses would be with Amanda on time, although Agency B had decided to extend the consultation period to six weeks, leaving only one week to write up its response. But Agency C had a problem: the chair of its management committee was unexpectedly abroad and this would delay the response by two weeks. Since the consultation key stage was on the critical path, the project would no longer be on target unless some adjustments could be made.

Figure 2: Portion of a critical path diagram shows the relevant section of the critical path diagram.

View larger image

Figure 2 Portion of a critical path diagram

Long description

Using the critical path diagram, Amanda identified a number of options:

postpone the 8th December steering group meeting;
tell Agency C that it would have to get its response in on time;
complete the redraft more quickly;
put pressure on the printers to shorten the time they needed to print the document.

Amanda decided that ignoring the absence of a key consultee could jeopardise implementation of the strategy. She was also concerned that compressing the time she had allowed for redrafting could compromise the quality of the document that was to go to the steering committee.

The constraints on adjusting the schedule included the approaching Christmas period. If the 8th December steering group meeting was cancelled, the group would not be able to meet again until 6th January. Amanda approached the printers who were able to cut the print time down to two weeks, provided that this was outside of the Christmas and New Year period. This meant that the strategy could be launched as planned on 17th February, even though the steering group meeting was postponed to 6th January.

Control involves not only gathering but also reviewing information, to identify implications for the progress of the project so that action can be taken to get back on track.

2.8 Controlling changes to the project

The Open University — Wed, 18 May 2011 10:08:30 GMT

Sometimes an addition or change to the project will be requested. This can be difficult for those who manage the project, because you will want both to maintain good relations with your client and to protect your profit margin and budget for resources. The first step is to assess the extent to which this will cause a need for additional time or resources. Perhaps the change can be accommodated in the project plan within the existing time-scale and budget, for example by altering some of the tasks in the later stages. Once the implications for time and cost of the requested change are known, you can decide how to respond to the client.

The change might be agreed without any charge to the client. There might be a case for making an additional charge, and you will have the full costing for the modification to support your claim. You may want to negotiate with the client to achieve a solution that suits both of you, again with full understanding of the implications. Whatever is decided, you will need to be fully informed of the cost and time implications of the proposed change before you enter discussions about how it could be managed.

Once any change has been agreed, it is usual to review the project documentation, making a formal amendment to the project brief, and amending the schedules and budgets and noting changes in the plan. You will also have to communicate the changes to anyone who needs to know in order to take appropriate action.

Activity 7

0 hours 15 minutes

What happened on recent projects, when a stakeholder requested an addition to the project? How was this handled and what was the outcome? What could have been done differently?

Discussion

Sometimes, we agree to the request of the project sponsor for additional work to be included in the project. At the time, it seems that it will be easy to implement. There are times when it creates additional problems that were not foreseen. It is useful to reflect on what happened as a result of the additional work so that we can learn how to manage these changes appropriately in a future project.

3.1 Introduction

The Open University — Wed, 18 May 2011 10:08:30 GMT

Communication on project work is the glue that holds everything together!
(Young 1998)

The success of a project is principally determined by its stakeholders, including sponsors and project team, and you can only know how you are doing by keeping channels of communication open. In this section, we examine briefly some of the issues involved in communicating with all people involved with the project, starting from its launch:

introducing the project team and their roles;
explaining the benefits of the project and its anticipated outputs and outcomes;
describing the project plan;
setting the ground rules for communication;
responding to questions.

Launching the project also allows you to set the tone of communications during the event. You may arrange to be formal or informal, accessible or distant, friendly and open or closed and withdrawn. However, you present yourself and the event will set the pattern for future communications.

3.2 Communicating with the project team and other stakeholders

The Open University — Wed, 18 May 2011 10:08:30 GMT

In project management, the quality of communication can make the difference between achieving your objectives and falling short of them. Projects often fail not because of problems with the work itself, but because the people involved are not working together effectively.

Project managers communicate in diverse ways: face-to-face or by telephone, in written and electronic forms, through presentations and reports. The purpose of communication is primarily to explain to others what has been achieved so far and what remains to be completed, and to listen and respond to the needs and views of others concerned with the project.

Example 6: Listening to the needs of stakeholders

I had an example of the importance of active listening in the context of a critical cultural-change project I managed for BT Cellnet which involved a mobile switching centre. The users in the new mobile switching centre were not content with the supply of a microwave cooking facility for the new building. People worked at weekends, late at night or during call-outs. They had indicated that they preferred to have a conventional cooker so they could prepare food such as pies, non-frozen meals and vegetables to provide a proper meal.

I set up a meeting with the users to ascertain the reasons why they wanted this facility, what the consequences were if I did not provide what they wanted and to look for alternative options that satisfied all parties.

During this meeting the users stated their requirements clearly and precisely. They felt very strongly about not being able to prepare food in the way that they wished to prepare food. A microwave was not an acceptable alternative to a conventional cooker. If they were not supplied with a conventional cooker, staff would no longer be prepared to work longer hours or show goodwill towards working by exception such as attending call-outs or staying longer at work to resolve urgent issues. They did not wish to discuss any other alternative.

I did not capture the views of the users. I heard what the users were saying during this meeting but I did not actively listen to them and act on what was said. I missed out on vital information (the reasons why users felt that this was the most important requirement to them and why other requirements did not matter so much to them).

Yes, in the end I decided to replace the microwave cookers with conventional cookers to meet the requirements of the users. The users in this particular part of the country were used to cooking real meals. I did not discuss the importance to them in detail, and therefore, did not understand. It did not matter what else I provided them – the cooker was more important than facilities. They felt so strongly about this that they said that I could reduce their desk space but provide the cooker!

By installing a heat/smoke detector and automatic shut off facilities, I was able to compromise and provide the cooker and I had a very happy user community, with a lot of flexibility thrown in.

(Eddie Fisher, Senior Programme Manager, Vodafone Group plc)

In this example, the need to maintain full cooking facilities for the staff was seen as highly important. When staff regularly work outside normal hours, the social environment can contribute considerably to the identity and independence of the team. For example, in Fire Service facilities, fire fighters need to have accommodation for long periods of duty, and the cooking and dining arrangements are recognised as contributing to the maintenance of the team. Cooking and eating together have often been seen as a way of building strong cohesion.

Building a project team is a continuing process that needs to be constantly worked at. The project team may be drawn from a variety of different departments within your organisation, or from different agencies, and may be very diverse in knowledge, skills and experience. Effective team working in a multi-disciplinary context can be hindered by lack of understanding of each other's roles.

3.3 Managing conflict

The Open University — Wed, 18 May 2011 10:08:30 GMT

Conflict can emerge when a project is thought to be absorbing scarce resources or shifting the balance of power.

The schedule for project meetings provides a framework for communication while the project is in progress. Meetings with team members on a one-to-one basis, in addition to group meetings, will help them to feel supported and could be an opportunity to provide coaching when necessary.

Example 7: Reducing risks from conflict

It is inevitable that conflict will develop at some stage in any project team composed of people with different personalities, backgrounds, experiences and specialist skills. Interpersonal conflict may arise where people do not want to get along because of different specialisms, racial prejudices, ethics, morals and the like. Typical causes of conflict include breakdown in communications, conflicting objectives and lack of trust. Ambition, jealousy and simply the wrong ‘chemistry’ are not unusual. There is often fear of change, or of exposure of some inadequacy or of failure.

Conflict can be healthy to the success of the project team, provided that it teaches everyone something about how to deal with and participate in resolution of the conflict. Look at all the communication channels and human interfaces to identify conflict risks. It can help to hold a risk identification workshop, or to carry out team building by openly declaring risks.

Risks by themselves will not disappear. You should devise a risk mitigation plan to deal with identified risks in a controlled way by being proactive. This might involve improving communications, substituting some personnel, or making changes in the project organisation. It is best if you can do this in the early stages. You also need to be reactive and put together contingency plans. Be on the lookout for new conflicts, because peoples’ circumstances and behaviour will change as the project progresses through the various phases. We humans like company even if people affect us, shape us and influence our feelings, attitudes and thoughts. Being a member of a project team affects individuals. Where two work together for their mutual benefit, they are co-operating. It is a valuable behaviour. Competition arises when two or more people vie for a goal where not everyone can be a winner. The alert project manager can develop a behaviour influence strategy whereby he will encourage team members to say good things about each other. People tend to want to help those who say good things about them. Project managers need to encourage team members to exchange favours: smaller ones first, larger ones later once trust/good relationships have been established.

(Eddie Fisher, Senior Programme Manager, Vodafone, Ltd.)

Activity 8

0 hours 15 minutes

Consider situations where there has been conflict? How did this conflict occur? What happened to improve the situation? Where could you see that communications had failed? What was done to improve communications?

4.1 Dealing with risk

The Open University — Wed, 18 May 2011 10:08:30 GMT

Projects are high-risk activities, and it is in the early stages that uncertainty is greatest. Some of this uncertainty can be removed during design and planning, but in practice a great deal may remain. Risks can be ranked according to their probability and likely impact, and a risk log can be kept detailing this information. Throughout the progress of the project you will need to review your risk log, to check whether any risks have become either more or less probable, and whether any new risks have appeared. Formal risk review should be a team activity, and could be included as a regular agenda item at every team meeting. Discussing this issue with the project team helps ensure that rankings are realistic, and that ways are found of dealing with potential crises. If everyone is aware of the triggers for each risk, difficulties are more likely to be spotted early on before too much damage is done.

When monitoring project risks and adjusting activities you need to pay particular attention to:

tasks inside key stages;
points at which several people are involved in one task;
tasks following a merge in the logic diagram;
key stages or tasks which will take a long time to complete;
the relationship between each key stage and the next;
any point at which the people involved are doing a task for the first time;
tasks involving new or unfamiliar technology;
key stages where there is very little or no slack or float in the schedule.

When a risk becomes reality, its implications must be assessed, including:

the effect on costs and resources;
possible consequences if the problem is not addressed;
which aspects of the project are affected;
how serious the problem is thought to be.

Depending on the reporting arrangements you have in place, you may need to notify your sponsors of any problems immediately. It is more likely, however, that you would want to identify possible solutions first, so that you can make recommendations for action at the same time.

4.2 Problem solving

The Open University — Wed, 18 May 2011 10:08:30 GMT

Involving the whole team in the problem-solving process shows that you value their experience and knowledge in devising a solution. It may also be appropriate to involve other stakeholders and/or the project sponsor. If problems are solved jointly there is usually wider ownership of the solutions and their implications; and, if more resources are agreed to be needed or new procedures are put into place, there is also likely to be more support.

Problem solving can be broken down into a series of steps, as shown in Figure 3: Steps in problem solving.

View larger image

Figure 3: Steps in problem solving (based on Young, 1998)

Long description

4.2.1 Defining the problem

The Open University — Wed, 18 May 2011 10:08:30 GMT

It is vital that the problem is identified correctly. If the risk management system is working properly, the problem should not have hit you completely out of the blue, and you should already have some idea what it is about. But, although there is often a temptation to skip the definition phase and go straight to causes and solutions, it is important to be as clear as possible about the nature of the problem as seen from different perspectives, by answering questions such as those below.

What? – Can the problem be broken down into smaller parts? Is any one of these smaller parts more significant than the others?
Why? – Why has the problem arisen now? Why wasn't it noticed before?
When? – Is this a recurring problem? Is it part of a pattern? Might the timing be significant in some other way?
How? – What was it that drew your attention to this problem? How have problems like this been dealt with before?
Where? – Is the location of the problem significant? Does it also occur elsewhere?
Who? – Are there particular people who need to be consulted about the problem or who would benefit most from solving it?

Time spent collecting information at this stage is time well spent, because it helps to ensure that later decisions have a sound basis.

4.2.2 Identifying possible causes

The Open University — Wed, 18 May 2011 10:08:30 GMT

The possible causes of a problem can be written onto Post-it notes or similar, and arranged on a flipchart or whiteboard in the form of a ‘fishbone diagram’. This can be a useful method to help a group to examine causes of problems, and perhaps also to clarify your own thoughts. Figure 4 shows a fishbone diagram produced by Midway Airlines to analyse the causes of delayed flight departures.

View larger image

Figure 4 Fishbone diagram of causes of delayed flight departures (from Wyckoff, 1992)

Long description

To construct a fishbone diagram, you begin by writing the problem in a box on the right-hand side. Next you draw in the backbone and some ribs, each of which should have a heading denoting the area it addresses, such as:

people;
process, procedures or method;
materials;
equipment.

Such headings give the process some structure, but are not essential. If the problem is clearly located within the people area, for example, you could use the ribs of the fish for the main reasons, asking the question ‘Why is the problem occurring?’ Each of these reasons could then be split into sub-reasons, by asking the same question again.

Activity 9

0 hours 30 minutes

1. Think of something that recently went wrong at work. Draw this out as a fishbone diagram, tracing each contributing factor back to the causes of the problem. Keep asking, ‘Why did this happen?’ until you are sure that you have identified all of the contributing causes.

2. What can you do to prevent this problem from recurring? Consider each cause that you have identified, and what could be done to prevent a similar problem arising again.

Discussion

You may like to discuss your diagram and your suggestions for solutions with your manager or the team who encountered this problem. It may be helpful to draw up the diagram with others who experienced the problem because, if they are involved in analysing the causes, it is likely to be easier to engage their support in implementing solutions.

When the possible causes are laid out like this, the structure helps to show duplications and links between them, so that you can eliminate any that do not apply. Causes on more than one arrow may be significant, and could be described as primary causes.

Fishbone diagrams help break down an issue into more manageable pieces, encouraging the team to escape from the cage of linear thinking and generate new ideas. Possible solutions may begin to emerge for even the most intractable problems if these are looked at in this different way.

Using data collected over one month, Midway Airlines constructed a histogram illustrating how many times each cause of delay had arisen (Figure 5: Histogram of Midway Airlines flight departure delays). Using the Pareto principle, which says that 80 per cent of a problem is generated by 20 per cent of the causes, helps to identify priorities for action.

View larger image

Figure 5 Histogram of Midway Airlines flight departure delays

Long description

Activity 10

0 hours 10 minutes

Using this histogram, identify the main causes of flight departure delays.

Discussion

The histogram showed that the main causes the airline should concentrate on were:

acceptance of late passengers;
waiting for pushback;
waiting for refuelling;
late weight and balance sheet.

All other causes added together only contributed 11.7 per cent to the total.

4.2.3 Restating the problem

The Open University — Wed, 18 May 2011 10:08:30 GMT

If your analysis of the problem and its possible causes is thorough, it should enable you to rewrite the problem statement to include the causes. If you can clarify your objective by defining a desired end-state, you are more likely to produce a good solution.

4.2.4 Collecting possible solutions

The Open University — Wed, 18 May 2011 10:08:30 GMT

This is the most creative part of the problem-solving process: it involves breaking the mindset within which situations are normally interpreted. Brainstorming is a good way to generate new approaches, by making sure that even apparently ridiculous ideas are not thrown out in the initial stages. Brainstorming has two basic principles:

quantity is more important than quality, in the creative phase;
critical comments are not allowed, at this stage.

It is important not to stop just because the flow of ideas has slowed. That is often the point at which really good ideas start to come.

4.2.5 Choosing the best option

The Open University — Wed, 18 May 2011 10:08:30 GMT

When you have collected a broad range of options, each possible solution should be assessed for its feasibility. As the feasible options are narrowed down, you may choose to analyse three or four in detail. Appraise the possible consequences of implementing each of these, against your criteria for cost, time and quality.

4.2.6 Getting agreement to the chosen solution

The Open University — Wed, 18 May 2011 10:08:30 GMT

It is important to establish consensus as far as possible within the project team on the best solution, and to record your decision. Depending on your reporting arrangements and the severity of the problem, you may then need to prepare a formal report with recommendations for action and take it to the project sponsor(s) for agreement. Solutions have to be ‘sold’ to ensure that they are acceptable.

4.2.7 Implementing the solution

The Open University — Wed, 18 May 2011 10:08:30 GMT

Getting agreement will not in itself ensure effective implementation. An action plan is needed, to set out exactly what each person now has to do. Your adjusted project plan (especially the critical path diagram and Gantt chart) and observation of what is happening should enable you to monitor how the recommended actions are being carried out.

In Example 8 the leader of a children and families team describes how they tackled a quality problem as part of a project to improve the process of reviewing cases.

Example 8: A quality problem in a social work team

From supervision of my team, I had some very tangible evidence that there was a quality problem. The quality of case reviews varied considerably from worker to worker and from case to case. What concerned me most was that care plans were sometimes vague, and even when their quality was high, there was evidence of drift. Deadline dates for key events were not adhered to and some actions were getting lost altogether. Even the dates for reviews were sometimes not kept to, so problems in implementing care plans were not picked up and rectified. Don't get me wrong. I'm very proud of the team and the work they do – and so are they. Everyone has a heavy caseload and they are often very complex cases. Someone or something will always disrupt the best of plans. It's often the everyday wheeling and dealing that moves a case on, leaving the formal plan way behind.

The team were going through the motions of completing the mass of forms but I don’t think they really saw any relationship between the bureaucracy and the quality of their work. They were demoralised really. There seemed to be some management problems as well: team leaders often didn't attend reviews and this seemed to be becoming the norm. Good delegation, you could say, but if we don’t take reviews seriously enough to attend, then why should our staff?

And where were the service users in all of this? To me, children and their families can find very little in the process that they can be positive about. Generally speaking, it must be a totally alienating experience. Some key workers do a good job of taking families through the review process before it takes place, explaining what's going to happen, but even then it can be painful. Parents are always included, of course, but they are outnumbered and outgunned. Children and their families have a chance to comment on the process and outcome, but it doesn't feel to me like really listening to customers. I think they just accept the review process as another hoop to jump through.

So I had some tangible cause for concern and some gut reactions that I needed to check out.

Activity 11

0 hours 20 minutes

On the basis of the information in the case study, draw a fishbone diagram to define the problem and identify its possible causes.
How would you find out which were the main causes that needed to be addressed?

Discussion

You may not be familiar with the social work setting, but you will probably have identified the central problem issue as being poor quality of childcare reviews. You may also have recognised problems of communication, shortage in equipment and resources, and personnel; and failings in the use of procedures and systems. Figure 6 (causes of poor quality of childcare reviews) shows the fishbone diagram the team leader drew with her team.

View larger image

Figure 6 Fishbone diagram of causes of poor quality of childcare reviews (Wyckoff, 1992)

Long description

To collect more data, the team leader consulted a number of people involved in the process, using structured interviews with individuals and small groups. The team also devised evaluation forms for use with different groups of stakeholders. The number of reviews carried out on time was monitored, and a bar chart (Figure 7: Quarterly review of care plans against agreed quality requirements) was drawn after auditing a sample of case files against quality criteria.

View larger image

Figure 7 Quarterly review of care plans against agreed quality requirements

Long description

The data collected by the team, as well as the problem-solving process they went through, helped them to explore solutions to the quality problems in their work.

5 Summary

The Open University — Wed, 18 May 2011 10:08:30 GMT

In this unit we have focused on effective management of the routine activities of a project. I began by considering what a manager can do to ensure that tasks and activities start on time. You should now be able to take the steps that are required to implement a project. Appropriate people need to be appointed to teams and to be clear about individual and group responsibilities. The accommodation and equipment must be secured, together with ensuring that the necessary resources are in place to enable staff to start work.

Once work is in progress one of the manager's roles is to monitor the process, to check if everything is running according to the plan. Usually there will be many deviations from the plan, because of the many events that impact on the daily life of a project. It is usually necessary to make adjustments to the timing and scheduling of activities, and also to the provision and flow of resources. These changes need to be noted in the plan, so that the overall progress towards objectives can be reviewed.

Ways have been discussed in which stakeholders can be kept informed about progress. There are often many different types of stakeholder with different concerns. It is often necessary to use different ways of communicating with these groups to ensure that they support the project or, if there is any conflict, that stakeholders do not present barriers to progress

Predicting, identifying and tackling problems which arise during the life of a project has also been covered. The risk log provides a framework that can be used to make regular checks for potential problems that were predicted in the earlier stages of the project. I identified stages of a project that often present risks. I introduced some techniques that can help identify the causes of problems, including a set of questions to ask before a decision is made and the use of fishbone diagrams and histograms. In addressing risks and problem areas managers must decide how to adjust the plan so as to keep the necessary balance of time, budget and quality, and to ensure that the objectives of the project are achieved.

Next steps

The Open University — Wed, 18 May 2011 10:08:30 GMT

After completing this unit you may wish to study another OpenLearn Study Unit or find out more about this topic. Here are some suggestions:

If you wish to study formally at The Open University, you may wish to explore the courses we offer in this curriculum area:

Or find out about studying and developing your skills with The Open University:

Or you might like to:

Post a message to the unit forum, to share your thoughts about the unit or talk to other OpenLearners
Review or add to your Learning Journal
Rate this unit

References

The Open University — Wed, 18 May 2011 10:08:30 GMT

Connor, A. (1993) Monitoring and Evaluation Made Easy, HMSO.

Craig, S. and Jassim, H. (1995) People and Project Management for IT, McGraw-Hill.

Mae-Wan Ho (1999) ‘One bird – ten thousand treasures’, The Ecologist, October 1999, reprinted in Resurgence, No. 199, March/April 2000, p. 15.

Schlesinger, P.F. and Kotter, J.P. (1992) Organisation: Text, Cases and Readings on the Management of Organisational Design and Change, Irwin.

Walmsley, S. (1996) ‘Project Management as a tool in implementing major organisational change: a case study’, Local Government Policy Making, Vol. 23, No. 1.

Wyckoff, D.D. (1992) ‘New tools for achieving service quality’ in C.H. Lovelock (ed.) Managing Services: Marketing Operations and Human Resources (2nd edition), pp. 236–49, Prentice Hall.

Young, T.L. (1998) The Handbook of Project Management, Kogan Page.

Acknowledgements

The Open University — Wed, 18 May 2011 10:08:30 GMT

The unit has been adapted for OpenLearn by The Open University Business School from The Open University course B713 Fundamentals of Senior Management.

Except for third party materials and otherwise stated (see terms and conditions), this content is made available under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Licence

Figures

Figure 3: Based on Young, T.L. (1998), The Handbook of Project Management, Kogan Page;

Figure 4: Wyckoff, D.D. (1992), ‘New tools for achieving service quality’, in Lovelock, C.H. (ed.) Managing Service: Marketing Operations and Human Resources, (2nd edition), Prentice Hall;

Figure 6: Wyckoff, D.D. (1992), ‘New tools for achieving service quality’, in Lovelock, C.H. (ed.) Managing Service: Marketing Operations and Human Resources, (2nd edition), Prentice Hall.

Every effort has been made to contact copyright owners. If any have been inadvertently overlooked, the publishers will be pleased to make the necessary arrangements at the first opportunity.

Don't miss out

1. Join the 200,000 students currently studying with The Open University.

2. Enjoyed this? Browse through our host of free course materials on LearningSpace.

3. Or browse more topics on OpenLearn.