The Money Files

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!

In December I wrote about benefits realisation and management, and how you get started in a simple way. That prompted a fantastic question from Markus:

Reflecting on your thoughts about the growing emphasis on benefits management in project management, it's clear that there's a real shift happening. It's fascinating to see this kind of evolution, where both big and small projects are being scrutinized not just for what they deliver but for the actual benefits they bring. This approach feels much more holistic, doesn't it? … What's your take on this evolving landscape? Do you feel that the focus on benefits management is changing how projects are approached in your organization?

So, let me dive into that a little today and reflect further on the shifting sands of benefits realisation.

Change #1: Stakeholders

I think the first big change in the landscape of benefits management is that stakeholders are far more open to the idea that there are benefits.

In other words, they want to see benefits, they want to come along to workshops to define benefits and they want to get the credit for delivering benefits! People seem to realise that they can’t simply ask to do projects and someone on high say yes. It’s not that easy any longer.

I think part of this change has come about because there is not the funding sloshing around for pet projects any more. Going back a few years, we might have had funding for projects that didn’t really need to be justified beyond ‘sounding like a good idea’. These days, there is far more scrutiny on where the money is going, so it’s important that stakeholders are seen to be engaging with the process of benefits identification.

In real terms, that looks like a lot more commitment to the benefits identification and tracking process.

Change #2: Accountability

Having willing stakeholders prepared to go through the hassle of setting up benefits trackers is really only the start. They have to be held accountable and those tracked benefits need to be reported. And if the benefits aren’t there, that should be challenged. Perhaps there are good reasons why the benefits are delayed, and that can be factored into financial plans going forward.

Change #3: Over-reliance on benefits for funding

I don’t see this often, but there have been cases where some very good project idea has not been funded with ‘real’ money because the plan is that it will self-fund from the benefits. In reality, funding something with money that you save is really hard because you don’t get the savings until after you’ve done the work. So you either have to commit to doing the work and be really sure that the benefits will materialise, or don’t do the work because you can’t pay for it before any benefits are realised… it’s a bit chicken and egg.

I hope this doesn’t become a new benefits trend: yes, do any project you want as long as it’s self-funding! Even a bad idea could get the go ahead if that was the attitude.

Change #4: Identifying benefits

When I first started out as a project manager, we often talked about benefits, but only really listed intangible things like improved customer satisfaction generally (which we could have actually tracked, if we’d bothered enough) or staff morale, or brand reputation avoidance. Things like that.

Benefits are often a bit abstract or not immediately obvious, or you can’t take a baseline because you’re developing something new so there is no current baseline that’s easy to grab to track the difference.

I think part of the evolution is coming up with better ways to track benefits and identify them, and to be honest, I think large data sets, online tools, big data analytics and company’s interests in understanding everything in lots of detail paved the way for us to have the right approach to do this, and the data sources to back it up.

Markus went on to write:

The whole process of setting up models for benefit calculations can be quite a maze. You've got to bring in experts, wrangle with finance teams, and then there's the task of gathering all that baseline data. It's like piecing together a puzzle without having the picture on the box. Getting everyone on the same page, ensuring they understand and agree on the calculations, is a Herculean task in itself.

I certainly agree. It’s not about setting it up once and forgetting about it. It’s an ongoing effort that only starts with identification. However, the signs are there that more and more organisations are caring about benefits – probably because they have to, and that’s not a bad thing.

What does the landscape look like with you?

Back in December I wrote about how to reduce your project’s carbon footprint by taking sustainability into account during the management of the work.

There were some really interesting comments on the article, and one of the questions was:

What challenges might project managers face in integrating sustainability into their project plans, and how can these be overcome?

Let me spend some time today talking about 5 of the challenges I think are top of mind when it comes to managing sustainability in a project environment.

Challenge #1: Stakeholder buy in

The first thing I think you need to overcome is the challenge of stakeholder buy in. Are your project stakeholders as committed as you to putting sustainable working practices at the heart of this project? And what do they mean, really?

I’d tackle this by including a sustainability management plan as part of the project artifacts, making sure that we all agreed what measures we are prepared to take.

Challenge #2: Supplier buy in

Next, suppliers. It’s fine having the support of your internal team, but if you are bound to use certain suppliers who are not aligned to your value, a big part of your sustainability effort could be undone.

It’s great to think you might have the freedom to select the partner who delivers all their supplies in electric vehicles powered by green energy, wrapped in recycled paper packaging, but honestly, not all suppliers are able to meet those, nor may it be practical or desirable for them to do so.

Yes, think about which suppliers you contract with, and talk to them about their sustainability plans and approaches, but sometimes you’ll have to accept that the preferred supplier and the best fit for your project is not the greenest option. Perhaps tackle this by looking at carbon offset schemes?

Challenge #3: Team collaboration

One of the things you can easily to do reduce the carbon footprint is to travel less and reduce the overhead related to driving or flying to work-related meetings. But what is the impact on productivity and collaboration for the team?

We all know of the advantages of collocated teams, and while many of us are reading this article while working from home or not in the same location as our colleagues, it is still lovely to meet up with the team from time to time.

Think about what travel is possible for the team to do, and how you can build informal networking and team events into your remote working schedule.

Challenge #4: Tracking

Let’s say you’ve got agreement to work in green ways or to consider sustainability seriously as part of your project management approach. How are you going to track this?

One of the challenges is identifying meaningful measures. For every car journey avoided, what does that mean? Look for your company’s standard measures for calculating carbon by weight, and think about how that translates from what you are doing.

Alternatively, you might decide that you’re going to be as green as possible without tracking (which might defeat the purpose if part of your goal is to contribute to targets like net zero) but at least that would be something. Deal with this challenge by talking to your sustainability manager or finance team, or the department responsible for looking at energy saving and carbon tracking.

Challenge #5: Consistency

It’s fine starting out thinking you are going to be all green on this project, but it’s often hard to keep the momentum, especially if there is no corporate mandate or wider sustainability plan, and you are up against stakeholders who don’t attribute the same level of importance to this as you do.

Overall, building in sustainable working practices and choosing to manage the project and the deliverables in a sustainable way shouldn’t be hard, but in practice I’m sure you’ll face these challenges.

What else did I forget? Have you tried green ways of working or deliverables and found them easy to build into the way you work? Let us know in the comments below!

We’re all familiar with the standard ways of measuring progress and project success. You might use earned value, or burndown charts or even percent complete.

There are other metrics we can build into our project management practice, and over the last few weeks I’ve been exploring them. One of the questions I got asked in response to my first article on alternative metrics was what challenges might arise from implementation and how could we, as project managers, overcome those?

Let me share some ideas.

Change adoption

The hardest thing with implementing any new way of working is resistance to change. You want me to track something else, in a different way, making more work for me? No thanks.

So when you want to introduce a new metric, like customer satisfaction tracking for internal customers, the goal is to make it as easy as possible.

Try to reduce the barriers to implementing the change, using all the good change management practice you are familiar with, like training and communication and helping people understand the reason for tracking in new ways. Find champions. Remove the old ways of doing things. Give people the tools they need.

Start small

As with all changes, it helps if you have someone leading the charge, and that is likely to be you. Let’s say you want to implement customer satisfaction measures, following the outline of the process in my book, Customer-Centric Project Management. There’s no obligation to start with your biggest program, or even to do it on more than one project.

Use your own project and just do it. Start by asking the sponsor what they value the most from project delivery or what they find important in the process, and then track how satisfied they are with that measure once a month. For example, when I did this, communication was one of the things stakeholders said was important, so each month we tracked how good we were at project communication by asking them to rate us on a scale of 1-10.

Ultimately, we did get the whole department of project managers tracking internal customer satisfaction in this way, but we did start with one project.

Be consistent

Another challenge with changing any way of working is being consistent. One of the things we’ve found with tracking measures monthly is that often (too often, really), we’ve found a flaw in the original assumptions, or some business process changes, or some other thing happens and we realise that the way we are tracking needs to change. Getting more data, more understanding and more accuracy is not a bad thing, but it does rather invalidate your earlier measures if they are now not comparable to your ‘today’ measures.

The way around this is to be consistent, both with tracking in general (in other words, do it regularly and don’t give up on it) and in how the measures are calculated.

Perhaps learn from our situation and give yourself three to six months where you allow for the measurement assumptions and tracking approach to be tested. Make tweaks as you go so you know that after that period you can ‘fix’ the way you are tracking so going forward your numbers are comparable and stable.

Consistency also means following through and completing the tracking regularly, whatever frequency you set, and that might be different for different metrics.

For example, we track some things monthly, but other metrics are only looked at quarterly because that’s how it makes sense.

Build the obligation to report into people’s job descriptions and roles. Set up a mechanism to hold them accountable if they are not completing the tracking. For example, the PMO could ask for all metrics to be added to a central spreadsheet so all portfolio tracking is in one place. Then you could easily see which projects had completed their tracking and which had not.

There are always challenges with doing things differently, but if you really want to make the change, you can. The good news is that often you don’t need PMO or portfolio office support, or even the consent of your line manager. If your sponsor is happy that you track, and you’ve got the energy and enthusiasm to do it, you can.
I recommend starting with customer satisfaction as it’s easy to do with no specific tools required, and it has a huge impact on stakeholder engagement: it’s very much worth it!

Every stakeholder on your project is going to come to the work with a different level of engagement. That level of engagement is going to depend on lots of things, like:

• How busy they are
• What other projects they are working on and the priorities of those projects
• Their level of understanding for the project’s goals and objectives
• What is expected of them (and whether they perceive those tasks to be easy, hard, pointless or worth their time).

Often stakeholders don’t exhibit the levels of engagement that we might feel we need from them to get the best results for the project. Here are some thoughts and simple ideas for how to move people into a place where they are prepared to engage a bit more with the project.

Blocker to indifferent

Projects struggle when the wrong stakeholders are blocking the change. In fact, when any stakeholder is resistant to change, that can cause problems.

Blockers are possibly people who don’t see the problem that the project is trying to fix. They might be keen to defend the status quo, whatever that is.

Talk to them about why they appear to be resistant, or what they are worried might happen as part of this project. Try to share the reasons for the project and the ‘why’ behind the change, even if it doesn’t directly affect their team. They might be more open to engaging with the project if they know the reasons driving the change.

There are various things to try here, but it starts with trying to understand their position and probably ends with escalating to their line manager or your project sponsor.

Indifferent to keen

These are stakeholders who are a bit ‘meh’ about the project and you’d like them to be supportive.

Indifferent stakeholders may think the project isn’t relevant to them. Perhaps they don’t see the point of it. The project just doesn’t seem important. You can see this in their reaction to the work, their slow response in getting back to your messages and calls, and their general attitude to the project.

There is also a chance that you’ve asked them to be involved and haven’t been clear enough with the ask. Talk to them about their priorities and those of their team. Share the successes and if necessary, try to get some of their time ringfenced to complete their project work.

Keen to champion

Supportive stakeholders are keen about the project, but they wouldn’t necessarily be a champion – those super proactive stakeholders who really understand and make progress on the work. Some of your stakeholders probably need to be in the ‘champion’ category.

Think about how you best use their time so they don’t sit in meetings and hear updates that they already know about. Ask for some small commitments and see how they get on completing those before you ask for larger tasks.

Not everyone needs to be a champion

You don’t need everyone to be a champion. Some stakeholders are probably OK to simply be indifferent: as long as they aren’t resisting the change that could be good enough.

The idea of looking at stakeholders in this way and seeing where they are on a scale is to understand better about the kinds of engagement – and specifically the time commitment – required for each stakeholder or group. Those that have the furthest to go on the scale are going to need more time and more focused action to move them into the zone where you want them to be.

Does anyone have an example of a stakeholder who has moved into the ‘more engaged’ category that they’d be prepared to share in the comments? I’d love to hear your stories of successful stakeholder engagement 😊