Project Management

The Money Files

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

About this Blog


Recent Posts

How to keep a business case up to date

More schedule tasks to do before you baseline

Quarterly review time: How was your Q1?

Saving 14 minutes a day with AI

Finished your schedule? Here’s what to do next


accounting, agile, ai, appraisals, Artificial Intelligence, audit, Benchmarking, benefits, Benefits Management, Benefits Realization, books, budget, Business Case, business case, carnival, case study, Change Management, checklist, collaboration tools, communication, competition, complex projects, config management, consultancy, contingency, contracts, corporate finance, Cost, cost, cost management, credit crunch, CRM, data, debate, delegating, digite, earned value, Energy and Utilities, Estimating, events, FAQ, financial management, forecasting, future, GDPR, general, Goals, green, Human Resources PM, insurance, interviews, it, IT Strategy, Leadership, measuring performance, merger, methods, metrics, multiple projects, negotiating, news, Olympics, organization, outsourcing, personal finance, pmi, PMO, portfolio management, presentations, process, procurement, productivity, Program Management, project closure, project data, project delivery, project testing, prototyping, qualifications, quality, Quarterly Review, records, recruitment, reports, requirements, research, resilience, resources, Risk, risk, ROI, salaries, Scheduling, scope, small projects, social media, software, Stakeholder, stakeholders, success factors, supplier management, team, Teams, Time, timesheets, tips, training, transparency, trends, value management, vendors, video, virtual teams, workflow


Finished your schedule? Here’s what to do next

Invalid hotlink: please upload your image instead.

Tasks and dependencies? Check.

Dates? Check.

Owners? Check.

But creating a schedule doesn’t stop when your Gantt chart has those elements in place. Even if it looks like it’s finished enough, you can go further to make your schedule really robust and useful for the project team.

Here are 3 things to consider when you’ve got the bones of your project schedule together.

1. Find the critical path

I’m surprised at the number of project managers I work with who don’t use a critical path, but then, sometimes I don’t work it out either.

The critical path isn’t helpful when there are lots of knowledge-based tasks with unknown durations and plenty of float. If most of your tasks can happen in parallel, or you have no fixed end date to aim for, then you could argue that it’s not super important to mark the critical path on the schedule.

I think that the more experience a project manager has, the easier it is for us to spot the tasks that are critical or potential blockers to progress without having to highlight each one in red on a Gantt chart, but that also depends on the complexity of your plan. It’s easy enough to spot the path on a 3-month software development project, but I couldn’t work it out in my head on a 600-line ERP implementation plan.

If hitting your dates is essential, and staying at the budgeted amount of resource is essential, and your plan is complex, then spend a bit of time working out the critical path. Normally you just have to hit a button to highlight it and then sense check what your software is telling you. Worth doing.

2. Work out the schedule risk

Look at your schedule and risk assess it. Your software tool might have features to do this for you, or make some smart decisions about the kinds of risk your schedule presents and add them to your risk log. Estimate uncertainty and factor that in, especially if you are working with individual dates instead of ranges.

3. Level your resources

A schedule is an academic exercise until you add in some people to do the work. And naming people against the tasks isn’t the same as working out if they have the capacity to actually do the work.

The challenge with a lot of schedules in my experience is that they are not backed by a resource management tool, so it’s very easy to overload someone with activity across multiple projects. You don’t have visibility of what else they are working on, so you assign them to a task. When the time comes, they are fully occupied on a higher priority project, or they have to split their time.

Resource allocation and levelling is tricky without resource management tools and when using duration-based planning. It might take me three weeks to get a new policy clause drafted and approved, but the actual effort involved is someone to write the clause (30 minutes) and then lots of time getting it through the approval cycles which involves small amounts of time from lots of different people.

That scenario is hard to level and factor into a plan – especially when your subject matter experts can’t tell you which half a day they’ve got allocated to doing their work.

However, give it a go. Sense check what you’ve got in the plan, look at how many tasks each individual has got allocated to them. Talk to them about their workloads and what else they are working on around the same time as this task is scheduled. As a minimum, factor in annual leave and vacation time!

When you’ve got a rounded out schedule, you can baseline it and start working through the work. What else have I forgotten? Let me know what you do to keep your schedule a useful, working document, leave a comment below!

Posted on: March 04, 2024 08:00 AM | Permalink | Comments (3)

How to Use Alternative Metrics

Last month I looked at a range of alternative metrics for assessing success. One of the comments on that article asked how, on reflection, had I seen these or other alternative metrics implemented effectively. It also asked whether there were challenges that might arise integrating alternative metrics into existing project management frameworks (which I’ll look at in a different article).

So, if you want to implement a more nuanced approach to measuring project success, how do you put this into practice? Below are some ideas. This topic is one that we could probably speak (or write) about at length, but hopefully the examples and ideas I share will give you some starting points for incorporating a range of measures into your project management practice.

metrics for project success

  1. Customer satisfaction

This is an area where I have quite a lot of examples to share. In my book, Customer-Centric Project Management, my co-author and I describe an extensive exercise to set up customer satisfaction tracking on projects, with internal customers.

I’ve written about customer satisfaction measurement on this blog before (start with this article: Lessons about project metrics). Basically, find out what is important to people, then track that regularly and plot your scores as part of regular reviews.

You don’t have to use an ‘official’ CSAT mechanism, or pay for electronic survey tools. Just ask people as a minimum.

  1. Innovation level

I haven’t used an innovation score regularly throughout a project, but it has been included in the way we rate projects and prioritize which ones should be done as the requests come into the pipeline.

Implement an innovation score yourself on a simple Likert scale (1-5 or similar). Ideally, you don’t want the measure to be subjective, so set some criteria e.g.:

  • Number of tools used where the business has less than 1 year of experience using them
  • Years of experience of team implementing (as someone could have gained a lot of relevant experience in a different role)
  • Contractor level of experience rated on a scale of how many implementations they have done.

Or similar – you really only need a couple of measures to make up your innovation score. Use the innovation score as part of the decision criteria for whether a project should be taken forward or not.

  1. Resource utilization

Resource utilization reports are something I’ve only actively used on a couple of projects, because mostly we either haven’t had the tools to extract the data (because we aren’t doing timesheets or detailed estimates), or because staff have been 100% assigned to the project so we don’t have to worry about them splitting their time across projects. We would still have to worry about them being scheduled to do too many tasks in a week and being over booked, or under utilized, but when the team is full time somehow that’s easier to manage as you can see what they are doing and we speak every day.

Use the reports to check exactly that: is the team going to struggle to meet its commitments? And if it is, because staff are over-scheduled, what are you going to do about it?

Even the basic reports from Microsoft Project will give you utilization data, so take a look at what you already have within your tool suite and if you find it useful, use it.

  1. Risk mitigation effectiveness

The final one I’m going to talk about today is tracking risk mitigation effectiveness. I mentioned in the article that you could use AI-powered insights to establish the effectiveness of the risk management activities undertaken, but in reality I imagine that takes quite a lot of effort to set up.

Another way to do this would be at project closure, or during lessons learned conversations, whenever these take place in your project lifecycle.

Look at what the risk was and what was done to mitigate it. Score the risk based on the effectiveness of the action:

  • 1: Risk management activity was 100% successful and risk was closed
  • 2: Risk management activity was successful but residual risk was worth £x
  • 3: and so on.

Using residual risk (and specifically, a financial value of residual risk) is a way to establish how effective your management action was – or at least, it’s one way to create data that allows you to assess that.

Hopefully that gives you some pointers for measuring project success through different routes, with some more concrete examples of how to get started.

Posted on: January 22, 2024 03:46 PM | Permalink | Comments (5)

"I would never die for my beliefs, cause I might be wrong."

- Bertrand Russell