The Money Files

by
A blog that looks at all aspects of project and program finances from budgets and accounting to getting a pay rise and managing contracts.

About this Blog

RSS

Recent Posts

What’s New in Project Cost Management (pt 1)

Who Does What in KPI Project Reporting

Should You Do Project Work on a Retainer?

Why You Don’t Need Money to Have a Successful Project

What’s the difference between a stakeholder and a supplier?

5 Common Approaches for Performance Measurement

How do you track the performance of your project? Here are 5 ways that you can do it.

1. Fixed Formula

This is pretty easy. Assign a fixed percentage when the work starts. Then make it up to 100% by allocating the rest when the task finishes.

The Pareto principle is a good one to use if you don’t know how to split your task percentages. Assign 20% complete to the job when it starts, and the remaining 80% when your team member reports the work complete (because at that point it’s 100% complete).

It’s simple to work out but it’s not terribly accurate. It’s only good for small pieces of work and short tasks where it would be too difficult or not worth it to work out percent complete across a couple of days. It can also be used where the task is no longer than a week long. If you are updating your project plan once a week, and the task is no longer than a week long, the task is either started or finished so the 20/80 split (or 50/50 or whatever you think is appropriate) works out pretty well.

2. Weighted Milestones

When you’ve got plenty of milestones along the way, you can work out project performance by tracking how many you’ve hit.

In other words, you can pre-assign progress (percent complete) to certain milestones or parts of tasks. When you hit Milestone 1 you can say the project is 15% complete, at Milestone 2 it goes up to 20%, at Milestone 3 you’re 65% complete and so on. Until your final milestone at project completion where your project (or task) gets updated to be 100% complete.

This is also a way to split payments to vendors – many contracts have a schedule of payments linked to the achievement of key milestones. Your budget could be weighted in the same way as how you track performance.

3. Percentage Complete

We’ve talked about % complete already, but this version of it is just based on the project manager’s guess best professional judgement. They update the schedule or tracker weekly (or whenever it’s appropriate) with their take on project performance by assigning a percent complete.

This isn’t hugely accurate either – although it depends on the project manager. It takes experience to be able to pick a percentage out of the air and have it reflect reality. Generally, project management tools can help with this by playing back to you the % complete of your project schedule, so at least in that case you should have something underpinning the number you give.

4. Percentage Complete with Gates

This is similar to weighted milestones but instead of waiting to hit the ‘gate’ point, you can report any percentage complete up to the approved limit for that milestone.

For example, when you hit Milestone 1 you can say the project is 15% complete, as we saw above. With weighted milestones, until that point the project would be 0% complete. With gates, you can set a % complete every day if you like, working up to 15% at the point of hitting the gate (the target milestone date or achievement).

It’s like a blend of using your professional judgement but being constrained to not say you are too far ahead because you can only ever hit a certain percent complete through the nature of where you are on the project.

It sounds complicated to explain but this is my favourite approach for measuring project performance.

5. Level of Effort

Finally, you can track effort against the elapsed time. Alternatively, you can track against some other task or work package on the plan. For example, ‘Complete Testing Documentation’ might be linked to ‘Complete Testing’ and the two activities progress in parallel.

You’d track performance for ‘Complete Testing’ and then, as you know that testing documents are being updated as you go, apply the same % complete to ‘Complete Testing Documentation.’

Which one(s) of these do you use? And which do you avoid? Do you use these as standalone techniques or do they link to your Earned Value Management activities? Let us know in the comments below!

Posted on: April 23, 2017 11:59 PM | Permalink | Comments (5)

7 Reasons to crash your schedule

Categories: scheduling

Too lateCrashing your schedule is hard work and not something that is advisable in many cases. So why would you do it? Here are 7 reasons why schedule crashing might be the right thing to do.

1. To get the greatest schedule compression

The main reason for crashing your schedule is to get the project done faster. If you need to bring your project’s end date forward then crashing gives you the most schedule compression for the least impact and the smallest cost.

2. When part of the project jeopardises progress

You could also look at crashing when you are facing one part of the project putting the rest of the project at risk. If a particular workstream isn’t going well it could suddenly become the route of the critical path. That might be OK, but equally you might feel that this difficult strand of work is going to hold the rest of the project to ransom. Crashing the schedule around those tricky tasks is one way to get yourself out of difficulty.

3. When meeting a fixed deadline

Projects require change and changes (however formal and appropriate your change control processes) have a habit of adding more time into the plan. When you are dealing with fixed date projects that’s not a good thing. So what happens when your necessary and obligatory changes start adding more time to your fixed date project? You have two choices: tell the project sponsor that you can’t do it and that your end date has to change or try crashing and see if you can claw back some time.

Whether you choose to crash or not will largely depend on your relationship with your project sponsor and how ‘fixed’ your fixed date project really is. I know that many project managers are given a fixed date to deliver by but with this often has some flexibility (especially if the compulsory changes that add more time are requested by the project sponsor).

4. When you are delayed

Delays early in the project necessarily have an impact on later work. You might consider crashing your schedule as a way to make up for some of the lost time.

5. When the team is needed on other work

And now we reach the reasons that are to do with resources. Your project simply might not be the most important thing happening in the business right now. Your team might be needed on other projects – or at least a particular subject matter expert might be.

Crashing your schedule is one way to free up certain resources more quickly. You could look at crashing a workstream so that your critical resources are available for other tasks or projects. The alternative to this is that you let them go (or are asked to let them go and can’t say no) and then find someone else to do the work. That’s a valid route too but depending on how far you are through the project you might find it easier to simply crash and deliver what you can with the original resources earlier.

6. When another resource is free

Sometimes the opposite happens – more resources suddenly become available. Ooo, more people for your project. The impact this can have on your schedule can go one of two ways:

  • You add an additional resource, refocus the resource allocation and deliver on certain tasks faster

Or

  • You add an additional resource and it takes them ages to get up to speed so actually you don’t make any time saving at all.

Only you will know which of these scenarios is most likely on your project, and who the extra resource is matters hugely. A junior programmer who has no experience on your project is not likely to gain you much time. But an experienced technical architect who has always kept half an eye on the project and now is available to complete some solution design work alongside your existing resources should speed things up for you dramatically.

7. When another resource needs training

Finally, you may face a situation where you have a resource who is not contributing effectively to the project because they simply don’t have the skills. This hopefully doesn’t happen to you too often – ideally as project managers we would select people for the project team who have the skills we need to get the job done. However, I’m sure you are aware of situations where either ‘the skills we need to get the job done’ were not defined or changed halfway through the project or we couldn’t get a resource with the appropriate experience allocated to the project.

If you have to let someone go on training they obviously won’t be working on the project during that time. If they aren’t working on the project, then their tasks won’t get done. If you don’t have someone else to pick up their work, this will push their overall delivery milestones out.

You may find that crashing the schedule gives you some more slack around their work – either for them to get work done before they go on training (probably not if they don’t have the skills to do their work in the first place) or to speed things up when they get back.

Would you agree with these? What other reasons have you found in the past to crash your schedule? Let us know in the comments.

Posted on: August 19, 2014 11:43 AM | Permalink | Comments (5)

6 ways to manage schedule performance

Categories: scheduling

How do you know if your project is going well? Schedule performance is a reliable way of assessing whether you are on track or not. Here are 6 ways to review your schedule performance and see if you are making the progress you expected.

1. Earned Value

Earned Value management is probably the most reliable way to track and manage schedule performance, but it’s also quite complex to get right, especially if you have no prior experience of working in an EV environment. On a small project you might find that a full EV approach is overkill.

However, it is a good discipline so if you have the time to set it up properly and feel it would be beneficial in your project environment, then you’ll get accurate and useful results with it.

2. RAG/RYG Indicators

Managing through simple colour-coding is pretty basic, but many senior executives like this as it helps them see which projects in a portfolio need their attention. Projects that are coded Red or Amber/Yellow need management attention, and those that are Green don’t.

To add an extra level of data to this simple scheme, you can flag trends with arrows. If the project is green at the moment but at risk of sliding into the Yellow zone, include a downwards arrow in the status information, for example.

You do need to set definitions for what each colour means. This will help avoid the situation where one project manager thinks a project is performing well and another would report the same situation as needing management attention, so set your criteria (or check what your PMO has already set) before your project starts.

3. Progress against milestones

Schedule progress is easy to measure against milestone data. List the milestones that should have been achieved during this reporting period and note whether they were hit or not. This gives a really visual, simple way of showing if the schedule is on track.

If a milestone has not been achieved by the target date you should also include a revised forecast so you have an idea of when it will be completed by.

4. Team morale

This is a measure that was flagged to me by Healthcare Project Management, a book by Kathy Schwalbe and Dan Furlong. I hadn’t considered this before, but team morale does have an impact on schedule performance. They write: “If project team members are always working extra hours, the schedule might not be realistic… On the other hand, if workers are coming in late and leaving early while still producing quality work on time, the schedule might not be challenging enough.”

A happy team may work extra hours because they believe in the project and love what they are doing. Or they might be doing the extra hours because they are swamped with work and couldn’t cope otherwise (in which case you should watch for burn out as they won’t be able to sustain that for long).

5. Tracking Gantt chart

If you use your Gantt chart software to generate baselines and show actual start and finish dates you can generate a tracking Gantt. This will show you progress against your original forecast and is a visual way to display schedule performance. You can generate all sorts of views of this information so you can get a good understanding of which tasks are underperforming. This is easy and useful, so use baselines if you can.

6. Status review meetings

Finally, you have the option of reviewing schedule performance in person (or as part of a virtual team meeting) with the rest of your team as part of a status review session. Trusted team members will give you their impression of how the project is progressing and whether or not they are performing as per the forecasted scheduled work.

Combining this narrative report with data from your project management systems will give you the best overall view of schedule performance. After all, you can’t use data successfully without understanding the context, so it will help to have your team members discuss project status with the figures in front of them.

Understanding schedule performance is critical if you want to bring your project in on time. When you know how your project is performing, you can make changes as appropriate to bring it back on track or enable the continuation of the good work.

Posted on: June 02, 2014 08:48 AM | Permalink | Comments (0)

Book review: Microsoft Project 2013: The Missing Manual

Categories: books, scheduling, software

In this book, Bonnie Biafore aims to share the basics of project management and how to achieve what you want to do in Microsoft Project 2013. That’s quite an ask for one book. Part 1 is a primer on project management and I was surprised that there was so much about this including project selection. It’s written as if it is aimed at a complete beginner – at least, the early bits are; the book gets technical pretty quickly – and there are nice boxes called     ‘reality check’ scattered throughout. They tell it how it really is, like this one (which you probably can’t read) titled ‘When Stakeholders Aren’t Supportive’.

 

Chartering the project

As part of the ‘how to do project management’ stuff, Biafore describes a project charter as a press release. This appeals to me as someone who writes press releases and I'd not thought about it like this before. She writes:

The project manager needs some publicity, too. Your authority comes from your project and its sponsor, not your position in the organisation, so people need to know how far your authority goes. The project charter is like a project's press release – it announces the project itself, as well as your responsibilities and authority as its manager.

There’s lots of practical advice like this, including the handy tip of not getting the most senior manager to send out the charter unless they actually know something about the project. You need authority, but you also need credibility, so choose someone who can give that to you, not any old senior manager in a suit.

"Like the pop-fly ball that drops to the ground as the third baseman and shortstop stare at each other, project work can fall between the cracks," she writes, whatever that means.

Getting technical: MS Project 2013

It's not until Part 2 that the book starts talking about MS Project. The biggest news since the product’s last release is that Project is now part of the Office 365 suite and there are easier to digest reports (which frankly wouldn’t be hard). In fact, there's a lot on reports which leads me to believe that getting them to look how you want could be tricky.

The book only covers the Standard and Professional editions, not Project Server. Some of the 365 suite features are covered but that software is evolving and the book is likely to get out of date quickly (and Biafore acknowledges that).

There are usability tips like collapsing the ribbon so you can see more of your plan on the screen and keyboard shortcuts. Biafore uses an example to create a basic project and then goes on to use another example to create a 'proper' schedule in a lot more detail.

She also includes tips on using other Microsoft products alongside Project, such as how to create a RACI matrix in Excel and importing resource names from your Outlook contacts.

The book is full of tips like how to create a resource and assign it to tasks at the same time, which are all aimed at getting you operational faster. I like the idea of downloadable worksheets for things like capital budget planning from the book's website and also links to MS templates online, which this book provides. They make the book more useful (and give it a longer shelf life) and the added resources will help you get your project on track more quickly. Having said that, I haven't downloaded any to try them out.

Check your schedule

There’s a lot about how calendars control resource and task scheduling with plenty of detail and screenshots about how to set up the correct variations of working time for your project.

As well as detailed walkthroughs and how to information, there is also practical advice for making the best possible schedule. For example, Biafore says you should be on the look out for these 8 things as you refine your schedule:

  1. Task dependencies that shouldn’t be there or should be a different type.
  2. Tasks with inflexible date constraints that they shouldn’t have.
  3. Manually scheduled tasks that should instead be auto-scheduled.
  4. Work or duration values that see too low or too high.
  5. Work packages/tasks without assigned resources.
  6. Summary tasks with assigned resources.
  7. Overallocated resources.
  8. Resource calendars that don’t represent people’s actual availability.

You can do some really advanced stuff, like setting work contours within an individual task to reflect how work is actually done – after all, resources don't work at the same pace for the entire duration of a task, especially if it lasts over several days. You could get really whizzy with your resource management using the advice in this book, but many of the features described will be far too much detail for the average project. While it's good to know what Project can do, it would be useful to have some sort of signpost in the book to say 'you can do without this feature if your project environment is not that mature or is relatively straightforward’. This would help new project managers work out which features they should use (like dependencies and baselines) and which ones they can leave and learn about another day (like creating an Excel form to display task information from Project and use it to get task updates from team members).

At over 800 pages the book covers a lot of ground. Much of that is screenshots, which are good and helpful. What surprised me was the breadth of the book, which covers everything from ‘what is a project’ to crunching some serious project calculations using data cubes. I don’t think you could read this knowing nothing about project management and turn into an expert by page 800, but if you need a detailed knowledge of MS Project 2013 then you certainly will get it from this informative and practical book.

Posted on: December 04, 2013 08:41 AM | Permalink | Comments (4)
ADVERTISEMENTS

"It has become appallingly obvious that our technology has exceeded our humanity. "

- Albert Einstein

ADVERTISEMENT

Sponsors