The step-by-step guide:
|PROJECT REPORT||Project Name: Office Re-fit Project|
|Reporting period: Week commencing 18 July|
|Project on track?||No 2 weeks late currently||Estimated completion date||26 August|
|Estimated completion budget||355,000|
|Description of status|| |
|Main actions done this week|| |
|Main actions to be completed next week|| |
|Issues to be aware of|| |
|Risks to be aware of|| |
|Approvals required|| |
Although this report is very short and simple, it provides most customers with all the information they need to have a sufficient understanding of the project status. The aim is not to overload your customer with detailed information, but to provide enough to give a good idea of status, to avoid them getting any surprises if there are problems with the project, and to give them confidence that the project is in safe hands!
The project manager should be monitoring the progress of the project continuously. This will happen informally all the time as you work on the project, and once a week formally with the project team in your review meeting. The basic process for monitoring and managing progress is to look at what tasks are completed, and what should have been completed and then ask yourself the following series of questions:
Are you on schedule or not, relative to the plan? Are there any trends you are worried about?
If there is any slippage, what is the impact? Are the late tasks on the critical path or not?
How much time are you late? So how much do you need to recover to bring yourself back on track? Are you likely to slip beyond your contingency time?
What options are there for recovering this time?
Which option is best?
Key drivers for success 4: Drive progress relentlessly
A project has a defined objective which is meant to be complete within a pre-defined amount of time. On some days you will find the project team are successful in moving the project forward, on other days they will be less so. Perhaps the task they are doing is complex, or a difficult issue has arisen, or simply the team is not motivated on that day. No one works flat-out all the time, but in your role as the project manager you need to ensure that progress is being made all the time.
When you relax and do not push the project team to keep delivering, they will also tend to relax and progress will slow down. Usually if the odd day or two is lost it can be recovered, but if you are not careful you will be starting a trend for the project to be late.
When slippage has occurred, there are an infinite variety of actions you can take. The actions you choose will depend on the specific situation you are in, but typically include:
Getting your team to do subsequent tasks more quickly. This is often the simplest way of recovering time. It is not always possible, but often if you ask people to focus on your project and put in a little more effort, some slippage can be recovered. If you work to keep the project team motivated and interested in the project, they will often automatically make up for any slippage that occurs. This only really works if you are tracking your project closely and you need the team to catch up a small amount of time, such as a few days.
Accepting the slippage and using some contingency. This is a valid option, but even if you are going to use up some of your contingency you should see if there is another way of recovering the time.
Adding more resources. This sometimes works, but it means you may convert a slippage in time into extra budget.
Looking at alternative ways to do what you are trying to do. There are lots of ways projects can be done differently. If you look at the tasks are there any that can be shortened? Or can any dependencies be removed so tasks can be done sooner?
Changing the project in some way. If you reduce your scope and deliver less, the project can sometimes be done more quickly. This should not be done lightly and always requires your customer's approval, but if you really are going to be late you should ask your customer: 'Would you prefer the project to be late, or on time but deliver less?'
Doing nothing. Accept the slippage and be late. This is a possible option and sometimes you have no choice, but it is not always acceptable to your project customer. If you keep doing this you should ask yourself what value you are actually adding as the project manager.
Key drivers for success 5: Be flexible and creative
Although the progress of a project follows a well-defined plan, the reality is that day-to-day working is very dynamic and constantly raising challenges. You must respond flexibly to the challenges that arise, and recognise if what you are doing is not working, as there is certainly another approach that will work better. When problems arise that seem intractable, try to think in different ways and usually you will find a way around them. Also don't forget to use the project team when there is a problem, asking everyone in the team for solutions will often throw up innovative and practical solutions.
The best project managers adopt the attitude that all problems can be solved, and that by thinking and rapidly applying that thinking, all projects can be successful. This is not to say they do impossible things, but by being flexible and creative in overcoming obstacles on projects, they get around most problems.
A good project manager faces challenges such as late tasks with the attitude that there is always a solution, and actively seeks to find and implement it.
At the start of a project you should have very few issues. If there are any, they should have been documented as problems in your Project Definition. However, issues will arise as the project progresses. Unforeseen problems have a habit of occurring; in fact one of the most important tasks of a project manager is in ensuring such problems are resolved. Success in a project is not about having no problems it is about delivering in spite of them! What differentiates really good project managers from average ones is the ability to overcome problems rather than accepting them as facts of life.
As issues are identified they should be reported to you. This should be done by all members of the project team as soon as they are identified. To be sure you are aware of all problems, ask all team members at the weekly review session if there are any new issues. You must keep on top of issues, as the number of them can build up. A large project may have tens or even hundreds of issues.
Once you become aware of issues, document them in an issues log, which provides a simple tool to allow you to manage them. For every issue identify:
What the issue is.
When it was identified.
What impact it is having on the project.
Who is going to resolve the issue? This person is usually called the issue owner.
What the action to resolve the issue is.
When it needs to be resolved by.
When the next update on progress to fix the issue is due.
Whether it is open (still a problem to the project) or closed (it has been resolved and is no longer a problem). This is shown on the issues log as 'O' for open, and 'C' for closed.
An example of part of an issues log for the office re-fit project is shown in Table 4.2.
|PROJECT ISSUE LOG||Project Name: Office Re-fit Project|
|Last Updated: 8 July|
|No.||Issue description||When identified||Impact on project||Owner||Action to resolve||Date to be resolved||Update due||O/C|
|1||We do not have agreement about the version of software to load on the PCs.||31 May||Unless this is agreed we cannot order the correct software and this will delay the project.||Mike||Arrange session with interested parties and decide on software.||17 June||N/A||C|
|2||There are only two sets of keys for the office and as they are security keys we cannot easily get more cut.||31 May||Without easy access to the office for all staff involved in the project, as and when they require, we risk slowing down progress.||Dave||Allocate one member of the project team to be on site during all office hours. Immediately start process of getting additional keys cut and allocate to nominated team members.||14 June||Confirm who is going to be on site all the time.||C|
|3||Mike's wife has been taken ill and he needs to take some time off to look after his children.||10 June||We cannot progress on task 4 on the project without Mike's skills, and this will delay completion.||Project Manager||Source contract IT staff to support task whilst Mike is off.||4 July||27 June Met temps and candidate selected.||C|
|4||The lift has broken down and we cannot get furniture to 3rd floor offices.||16 June||We cannot progress with task 3 on the plan and without this being completed we will delay the project.||Project Manager||Chase lift maintenance crew. Offer extra payment if they come in overnight to fix. In interim contract 3 4 removal staff to carry desks upstairs.||20 June||19 June Confirm repair complete.||C|
|5||The desks cost more than expected.||21 June||The desks are 400 each rather than 300, resulting in a 10k over-spend. We have sufficient contingency budget to cover this so if it cannot be resolved we will accept higher cost.||Dave||Try to: |
negotiate discount with supplier.
Seek alternative supplier (though not expected to be successful at this time).
However if not possible, order desks at higher price as this is on the critical path.
|27 June||Desks ordered at higher cost.||C|
|6||The carpet has been delivered but we are 150m2 short.||5 July||We cannot complete upstairs offices without this.||Dave||Carpet the area we can and start to install in those areas. Chase supplier for additional carpet and hold back all payment until it arrives.||21 July||14 July Dave to report to project manager on progress.||O|
|7||There is insufficient phone cabling for 100 desk phones.||6 July||We will not be able to install all 100 phones as requested.||Dave||Get quote from contractor to put additional cabling in place and then initiate work.||1 August (or will delay installation).||13 July Return quote from contractor.||O|
|8||The PC supplier can only provide 90 PCs in the first batch.||8 July||We need 100 PCs for all the staff, and so 10 staff will be without PCs.||Mike||Take the first batch of 90. The remaining 10 are not required until late July get commitment to this from supplier. If necessary we can overlap tasks 4.5 and 4.6 and start installing those PCs we have.||29 July||22 July Update on status of order.||O|
You should manage the actions in the issues log like any other task on the project and ensure they are being progressed. It is best to review this log on a daily basis to make sure issues are being resolved. Regularly contact owners of issues and ask them to confirm progress is being made. If an issue is having a major impact on the project, or actions are due for completion in the next day or two, phone whoever is responsible for the action daily and make sure it is done. At your weekly review meeting check that the owners are undertaking their actions. Important information in this table is the 'Date to be resolved', which needs to be treated as if it is a task end date on the plan and should not slip. Additionally, because some issues do take several weeks to resolve, by putting information in the 'Update due' column, you can start to ensure that progress is being made even if the issue is not fully resolved.
A sign of a project in trouble is when issues do not get resolved and the list keeps on getting longer and longer.
Remember your job is to manage the project not to do everything. So although you can own some issues, you should not be the owner of all of them unless it is a one-man project team.
At the beginning of a project, think of all the risks that exist and prioritise them by the impact and likelihood, as described in the section 'Risks' at the start of this chapter. Start by reviewing the assumptions in your Project Definition and decide if any of these add significant risk to your project.
For larger projects, a good way to do this is to run a brainstorm with the project team as part of the mobilisation session. Once you have this initial log, you need to keep it updated. If additional risks are identified, they should be reported to you. At your weekly review session ask all team members if there are any new risks.
Once you become aware of risks, then you should document them in a risk log. For every risk identify:
What the risk is.
What is the likelihood of it occurring.
What the impact will be, if it occurs.
What its overall priority is.
Who is responsible for managing this risk.
What the next action to resolve this risk is.
When any actions need to be completed.
What the current status of the risk is.
An example of a risk log is given in Table 4.3.
|PROJECT RISK LOG||Project Name: Office Re-fit Project|
|Last Updated: 18 July|
|No.||Risk||Likelihood||Impact||Priority||Owner||Proposed action||Date to be actioned||Current status|
|1||This is an unfamiliar project to plan and experience is limited and therefore there is a risk of underestimating time and budget.||M (2)||M (2)||4||Project Manager||We have put some contingency into the plan to reduce the likelihood of this risk.||No action manage as part of project.||As part of normal progress updates.|
|2||The project extends beyond the time at which the existing offices have to be evacuated, and the new office is not ready for staff. The current date we must leave the existing office is 1 October.||L (1)||H (3)||3||Project Manager||With sufficient contingency this has a low likelihood. However we must keep monitoring the situation. With two months' notice the landlord will extend existing offices at a premium price for an additional one month. We must decide by 1 August whether this is necessary.||Decision meeting scheduled for 22 July||Open and still a risk. Try to resolve this week and decide whether to have extension or not.|
|3||The office we are taking over is in an old building and has been vacant for some time. We have assumed there are no significant problems which will need to be resolved.||M (2)||H (3)||6||Dave||Perform full survey of office before finalising plan and committing to timescales.||3 June||Closed.|
|4||In our original plan we have assumed the existing telephony PABX will have sufficient capacity and functionality.||M||H||6||Adam||Test existing PABX and check compatibility with supplier. Consider raising a change to the project to include upgrading the PABX.||Must be resolved by 29 July.||Open testing due this week. Change request prepared in case required.|
|5||We need to switch off the electricity for a few hours, which requires agreement of all other tenants in building. This may be difficult to get.||L||M||2||Contractor||Monitor situation.||Open|
|6||Concern that the new desk furniture will not be liked by the staff, creating a bad feeling about the move of offices.||L||L||1||Dave||No action required.||Closed|
|7||The new phone handsets we have bought are not suitable for the new building.||L||H||3||Adam||Test handsets in building and ensure calls can be made.||Closed|
|8||The existing cupboard space within the office is insufficient for our needs. We do not intend to install any new cupboards.||L||L||1||Dave||No action current understanding is that it is enough. If a problem there is space for additional cupboards.||Monitor|
|9||We do not have the landlord's permission for the work we intend to carry out.||L||H||3||Project Manager||Resolve via facilities ensure we have evidence of full approval.||Closed|
You should manage the actions in the risk log like any other task on the project and ensure they are being completed. At your weekly review meeting check that this is happening.
As the project progresses, it is common for the understanding of the end goal to improve, and as a result for it to become apparent that something on the project needs to change. Alternatively, the customer may decide that the end deliverables are not now what is needed and he or she desires to change them. Unless changes are controlled, you will not know what the outcome of the project will be. The project may be late or it could fail or if change is continuous, the project may simply never finish. The way to control changes is via a change management process.
The change management process uses a change control form. Once changes have been identified they should be documented with the following information:
Document what the change is.
Describe why the change is being proposed.
Identify when the change needs to be accepted by, if it is to work.
Identify the impact of the change will it change the length of the project, or the cost? Does it change the level of quality or risk?
Note what the proposed action with regard to this change is.
Keep track of the current status of the change: it can either be 'in review'; it can be 'accepted' (i.e. it is agreed and has been built into plans); or 'rejected' (i.e. the project will continue unchanged).
Sign off from the customer to the change.
An example of a completed change form is given in Table 4.4.
|PROJECT CHANGE||Project Name: Office Re-fit Project|
|Last Updated: 16 July|
|Description of proposed change|
|The current project will deliver desks and PC facilities for 100 staff. This change would increase, by an additional 10 desks, to 110.|
|Reason for change|
|This would provide the opportunity to shut down the small office in London Road, which has 10 staff in it. Originally this was not viable as the lease is for a further two years. However, the landlord has agreed he will allow us to move out early without penalty so he can re-develop the site. There is floor-space in the new office and if done, we will save the rental on the London Road office from 1 November.|
|When this needs to be agreed by||22 July|
|Impact on the project|
|Timescale: +4 days|
|Cost: 20k for furniture, fitting and PCs, 2k for additional labour.|
|Other: Some minor risk implications. PCs are arriving next week; we think an additional 10 can be sourced quickly. The furniture was ordered about two weeka ago and will arrive in two weeks. The supplier has indicated he can provide the additional 10 within a couple of days of completing the main order, as long as he receives the order by 25 July.|
|We propose that this change is accepted. The timescale impact is minimal, and cost is modest compared to savings.|
|Customer approval||not yet approved for review this week|
|Date of customer approval||not yet approved for review this week|
As part of your weekly review with your customer, you should go through the proposed changes and how they will impact the project. Your customer should then decide whether to accept or reject them. If the change is accepted, it needs to be explained to other project team members and, where necessary, the Project Plan and Project Budget must be updated.
For big projects, or those which have a lot of changes, you may need to keep track of all the changes in a change log. An example of a change log is given in Table 4.5.
|PROJECT CHANGE LOG||Project Name: Office Re-fit Project|
|Last Updated: 25 July|
|No.||Change description||Owner||Current status||Update due|
|1||Include refitting of all cupboard space in office||Dave||Rejected||n/a|
|2||Change PC specification to flat screen||Mike||Accepted||n/a|
|3||Expansion to 110 desks||Dave||In review||29/07|
|4||Expansion of project to include upgrading telephony PABX||Dave||In review||29/07|
By performing the previous parts of Step 4 you understand your project's progress, you understand issues and risks and the changes that are being asked for. You have all the information you need to manage the project, but managing a project is not simply about understanding it, it is about taking action.
Key drivers for success 6: Be the project manager!
There are always lots of things to do on a project: tasks that need to be completed, issues that need to be resolved, risk and changes that need to be analysed, and customers who need to be briefed on progress. There is sometimes a temptation for the project manager to get involved in doing the work and not focus on managing it.
The title project manager is a deliberate one it is not project doer, project team member, or project worker. The role is to manage the project and it is an essential role. If people simply work on a project without someone looking over, co-ordinating, directing and controlling all the different activities it is unlikely to be a success unless it is a very simple task.
Of course you may be working on a project by yourself, or it may be a very small project, in which case you do not have a full-time project manager, and you will get involved in doing the tasks on the plan as well. However, even in this situation, do not confuse the work of doing tasks with managing the project.
A good analogy is with the conductor of an orchestra. No-one expects a great conductor to pick up an instrument halfway through a concert and start playing. Everyone understands that his or her role is to conduct, and that this is a critical role. The same should be true for a project manager, your role is to manage the project and this is an essential role.
Action can take many forms: you may need to ask permission to access a building; you may need to phone someone to check they are doing the work they are meant to be doing; you may need to buy some stationery for the project team; you may need to hire a contractor to get some work done more quickly; you may need to talk to a project team member to motivate them to work faster, and so on. The actions will cover the spectrum from large and complex tasks through to simple, quick acts. Whatever the actions are, they do not just need to be decided upon and planned, you need to make sure they happen!
Some project managers have the false impression that project management is about monitoring and reporting, with some supporting administration. These are important parts of project management, but the key role of the project manager is to keep progress going on the project and to take whatever actions are necessary to keep this happening.
The action you take depends on what the information you have collected shows. You must assess it all and decide what needs to be done and implement the action in the most appropriate manner. Project management processes and tools show when you need to take action (for example, to recover time so you are not late or to overcome issues) but they cannot tell you how to do this. Now is the time to use your common sense and experience to come up with solutions and having determined solutions, to implement them.
Table 4.6 shows some examples of typical problems on projects and what actions can be taken to overcome them.
|Typical problems||Constructive actions|
|When the project team starts to create a deliverable, they find the definition provided by the customer is not clear enough.|| |
|When the project team starts to create a deliverable, they find that it cannot easily be created in the way it is defined without significant delay or cost.|| |
|A member of the project team is unavailable due to illness and it is unclear how long the individual will be unavailable for.|| |
|The project is running late.|| |
The nature of projects is such that sometimes there will be problems. An unforeseen issue will arise which jeopardises the project, or a risk happens that you cannot do anything about. As the project manager, your job is to try and stop this happening and if it does happen, to minimise the impact on the project. However well you apply structure, rigour and good discipline, you are not a miracle worker and sometimes the project will be late or over-spent.
One of the key differences between a good project manager and a poor one is that a good project manager makes sure that a project delivers no surprises. If the project goes wrong, there should at least have been a prediction that it might go wrong (this is the purpose of the risk log). And when it goes wrong, your customer should know; it should not be a secret. Although giving bad news about a project is never a pleasant thing to do, hiding it and leaving your customer with a potentially bigger problem is far worse.
Often customers are very happy with projects that are late compared to the original plan, or a little over-spent. However, this is only true when they have been kept informed, and understand why it is late and more expensive. Through good information flows, as the project progresses, the customer should be briefed if the project is expected to be late.
Key drivers for success 7: Communicate continuously
Project management is at its heart about people management. It is about listening and understanding what your customer wants, explaining what you want people to do, instructing the team on the order of tasks, and watching for problems as they arise.
Although project management requires you to sit by yourself sometimes, to think through what needs to be done and the best way to do it, it is work that relies on the constant and continuous interaction with people. The best project managers spend a large proportion of their time communicating with customers, the project team, and anyone who can impact progress on the project. This ongoing action of listening and talking is key to successful project management.
The Project Plan and the Project Budget are your predictions at the start of the project of what it will take to deliver the project. As such, your success is about meeting the timescale and the budget agreed. However, the plan and budget are also tools to help you manage the project as it happens. In some situations the plan or the budget become so different from reality that you need to update them. This should be an uncommon occurrence as what you are effectively doing is changing the way you will deliver the project. You are also changing the basis of measurement of the project.
If any change you make moves a milestone on the plan, alters the overall timescale or changes the budget for a project, you must agree it with the project customer.
The times to make changes are:
If you realise that there is a better way to complete the project. This does sometimes happen and is obviously a good thing!
When you implement agreed changes. If a customer agrees to a change that results in the timeline or budget for the project changing, then the plan or budget must be updated to reflect this.
When the issue(s) becomes unresolvable in the timescale or budget originally allocated and there is a significant resulting overrun in time or money. Changing the plan or budget is not something to be done lightly, and should be done with a heavy heart, but occasionally it is necessary.
When the plan or budget does need to be updated, then go through the relevant parts of Chapter 2 again.
Top of Page