 OK – our project is running late (so what’s new?!). We’ve now completed 3 weeks of work since we started looking at tracking in Microsoft Project: 25 – Beginning Tracking, where the 25-day Aircraft A project was due to finish on 3 Feb 06. However, the reports we sent out last month have returned giving us an update based on a status date of 20 Jan 06. Delays have occurred and the latest project estimate after updating and levelling last week’s (Microsoft Project: 27 – Progress Data Input) input is now 9 Feb 06 – 3 days late. Load the latest project for Aircraft A from this link: http://www.mousetrax.com/pub/Aircraft_A28.zip. (You will need to reset the Current Date to 23 Jan 06 to see the blue gridline.)
So what can we do about that? There are a number of options that come to mind ranging from doing nothing, through working overtime, adding more resources, to changing the calendars.
To make things worse, let’s say that one of the Propulsion workers and one of the Electricians had an accident driving in to work and will be away for at least one month. Whilst we wish them a speedy recovery, where do we now stand with the project? The first thing to do is to update the project to see the effect.
Update Project
View/Resource Sheet and double-click on Propulsion and in the Resource Information dialog, change the first Available To date to 20 Jan 06.
Repeat this to set the next line Available From to 23 Jan 06 and with 100% Units (one man).
On clicking OK, note that the Propulsion trade font has turned red to indicate overallocation.
Follow the same procedure for the Electrical trades, reducing the Units to 200% and OK.
Whilst we’re in the Resource Sheet, enter Overtime rates for all 3 trades to 70, 65,and 60 respectively.
Note also the warning indicator – hover the mouse over the indicator to read the balloon text.
Let’s follow that advice to see the effect. (See Microsoft Project: 19 – Levelling for Results to remind you how to level.) Oh dear! The project will now take 30 days (compared to the original 25 days) and will now end on 13 Feb 06.
So, what do we do about it?
Do Nothing
I’m not joking! Do nothing might be a perfectly acceptable option. For example, the aircraft might not be required for operations until 20 Feb, and the owners are content to receive the aircraft back by 18 Feb. So, no worries, just let the project continue. I include this as the “do nothing” option is often not considered and panic unnecessarily ensues to get the project finished on the original date, which, as we will see, will cost more money. Doing nothing will not, of its own, cost more as the number of man-hours has not changed, though there may be extra overheads.
Overtime
Let’s see how overtime can help. Firstly, there would seem to be little point in working overtime on the non-critical tasks (the BLUE bars) as, by definition, this will not reduce the project duration. We can clearly see the critical path (RED) and its tasks. Applying overtime to Task 4 would seem to be a good starter. Select Task 4, split the screen, right-click in the lower pane and select Resource Work. As we want the Duration to be reduced, change the Task Type to Fixed Work.
Click OK to accept the Fixed Work mode before changing any data.
Now we can enter Overtime Work which has the effect of reducing the Duration (at an extra overtime cost, of course). Here comes a judgement, based on trial and error, to get the end date back to a more acceptable date. That will become a management decision which you will have to make for yourselves. For exercise purposes, let’s ask the men to work 2 to 3 hours overtime per day during this task. As the current Duration is 56 hours (7 days X 8 hours) let’s ask them to work 16 hours overtime and see what effect that has. Enter 16 in each of the Ovt. Work cells and then press OK.
The Duration of Task 10 should have dropped from 7 days to 5 days and the end date has come forward to 10 Feb 06. Now level. If you get an overallocation warning because of the overtime, just select Skip All.
The Duration is reduced back to 28 Days and finishes on 9 Feb 06, recovering the situation before we lost the 2 men. Again, do we accept that or do we want to do more?
I’ll leave you to try adding more overtime to tasks – Task 11, which is now critical, looks ripe for a bit of overtime.
Calendar
Another method available to us is to change the calendars. You can do this for individual tasks, resources or the project calendar. Let’s say we make the team work on Saturday 28 Jan 06. Tools/Change Working Time… click Saturday 28 January 2006, Nondefault working time and OK.
As we would expect, the Duration remains the same at 28 days but the end date is brought forward by one day to 8 Feb 06.
I won’t take this any further as you can see that by changing the calendar or asking people to work overtime, we can bring the end date forward. This is one good reason for always planning your projects to work normal working hours with a normal calendar. It allows us to use overtime and calendars as tools to help us get out of trouble! There are other ways of course, like getting more resources to help, but I hope you can now see the potential methods for “crashing” or shortening the project.
Questions
Finally, last month I posed 3 questions:
- How often do I need a return?
- With what accuracy?
- What am I going to do with the information?
With a program as sophisticated as Project and computers to make it quick and easy to see change, it is very easy to over-manage. We need to allow local management to use its initiative to get things done. If they run into trouble the first day, they might work overtime to catch up, either that night, or at the end of the week, or whatever. Thus calling for a daily return would take that initiative away and irritate the work force. Asking for data once a week would seem a reasonable input period for a six week project. On the other hand, for a project scheduled for 2 years, weekly returns could be considered too often, perhaps monthly returns would suffice. This pre-supposes an element of trust, that we are to be informed of any major problem at any time.
However, when we do ask them for data, give some idea of the degree of accuracy by, for example, asking for the number of man-hours left to be done, or the number of man-weeks left as this will save them having to make unnecessarily accurate calculations. The accuracy of the data can be hinted in the form we created last month. We could re-name the Column headings to include the units you want. For example, Work Done (to the nearest man-hour), would seem adequate for us in our aircraft project, whereas to the nearest man-week for a 2 year project could suffice. It can only be helpful to the resource to indicate the accuracy we need.
All our deliberations on data input should be prefixed with some idea of what we’re going to do with the information. To be ridiculous to make the point: if we ask for daily returns, by the time we’ve entered the data, levelled and produced a new plan for the next day, the workers will be well into the day’s work when our new schedule reaches them. On the other hand, if we leave the issue of a new schedule too long, it might well be finished late before we can do anything about it. We should also think about the effect on other projects if we are working in a multi-project environment. This is particularly pertinent if we are using a resource pool, as changing one project could well have a ripple effect through everyone else’s projects.
Such situations need to be clearly laid down in the Project Policy Statement for the organization (you do have one don’t you?). Every organization has its own way of doing things and one cannot be dogmatic. However, as a rule of thumb, let’s consider a 3 month-long project. I would suggest we get weekly returns of progress and enter them into the project plan. Observe the detail and decide if anything is going so wrong that a new plan is needed. If not, let local management catch up with late tasks, but ask them to inform you if the lateness is likely to cause a major delay. If not, await the next week’s input. After the 3rd week, consider issuing a new schedule beginning on the 5th week. Continuing that pattern, overall we would have the initial plan, one after the 1st month, one after the 2nd month and let the project run out to a successful conclusion by simple tweaking of the schedule with the local management.
Beware of over-managing your project!
Conclusion
In the past few months we have considered a variety of methods of tracking, supplying and applying updates, and then rescheduling to complete the project. We may well need a combination of these techniques to keep the project on track.
Next Month
This issue completes an introductory look at the way Project is designed to help us manage our projects. As 2006 unfolds, I intend to look in greater depth at some of the other facilities provided within Project.
May the New Year bring you success in your management of your projects.
|
