The Money Files

When I first started out managing projects, I had never heard of psychological safety. It’s a concept I’ve only come across in recent years, and it’s fascinating.

Psychological safety is part of what I would have called a blame-free team culture in the past: the idea that you can talk about hard things without worrying that there would be career consequences for raising challenges.

A report came out from the UK Ministry of Defence at the end of last year on psychological safety in projects, and the report defines it like this:

Psychological safety is the idea that we can be candid and raise issues without fear of reprisal.

The MOD manages plenty of high profile, high stakes projects, so they know a thing or two about how to create empowered teams – and also the consequences of what happens when projects don’t go to plan.

Here are 5 tips from the report that resonated the most with me.

1. Be present

Unsurprisingly, leadership behaviours were found to significantly psychological safety in teams, and if you’ve ever worked with a leader who made you feel like you never wanted to open your mouth to say anything in a meeting, you’ll know why.

The role we have as project leaders is key to shaping the environment and creating a safe space. From the 240+ surveys carried out to inform the report, a key takeaway was to be present in the project environment.

Being visible means there is a route for people to get in touch with points to escalate, progress updates or issues.

2. Reaffirm the direction and goals

The research found that clarity of direction was the second most important factor in creating psychological safety, after the behaviour of leaders, and it’s not hard to understand why.

We feel more comfortable raising concerns if we understand the mission and have a clear direction to follow. Plus, it’s easier to challenge behaviours and tasks that don’t support the mission, because everyone knows that’s what should be pulling focus.

The report concludes that project leaders should continually have conversations about the direction, especially when the context changes, for example economic or political changes.

3. Ask for (and give) help

Over 80% of people who responded to the MOD survey disagreed that it was difficult to ask others for help. However, it also identified that it was harder to ask for help outside of an individual’s specific team.

The lesson for us is that we should build working relationships across silos and up and down the hierarchy to be able to establish trust and respect across the organisation.

4. Create a learning culture

A culture of learning “mediate[s] the relationship between psychological safety and team performance”.

Project professionals can create a learning culture by being open to finding out more from their peers and colleagues, and also through sharing information and lessons learned freely.

5. Recognise individual excellence

I’ve written a lot in the past about how to celebrate team success and making sure to mark project-related milestones. But recognising individual contributions is just as important. Ideally, we should be rewarding contributions as well, so if your company has a staff recognition scheme, it’s time to dust off the submission guidance and think about who you could put forward for an award.

The report says that project leaders should ‘unlock purpose and empowerment to drive value’ which I interpret to mean helping the team see that their work is making a difference.

The research report has lots of other interesting takeaways, but those were the key headlines for me. I’d be interested to hear your tips for maintaining psychological safety on projects – let me know in the comments!

You know all those baselines you save in Microsoft Project? All the snapshots of your plan you keep just in case? Well, they are hugely useful for looking at to compare actual performance against forecast, so dust them off and let’s start using them.

BCF stands for Baseline-Current-Future and it’s a way of looking at comparative schedules. As a schedule control tool, it’s easy to use, easy to understand, and it’s a useful way of discussing project progress and performance with the team without having to go full earned value.

Plus, it’s not much work for you as the project manager, as you probably already have the details available.

Here’s how to do it.

The process

First, take the baseline Gantt chart. This will be the latest saved version of your Gantt chart that is an approved baseline. I know software tools can keep baselines saved in the software, but I do tend to keep a separate version of the whole file saved with the date in the filename, just so I have a back up of exactly how the plan looked at the point of the last official review.

You’ll also need an up-to-date position for what is happening right now, so if you don’t have team members entering data in real-time, you might have to give them some notice to get their data into the tool.

Then, you’ll need the future scheduled dates; what you anticipate the rest of the schedule will look like. This is your forecast, and will be the information in your schedule for the dates that haven’t yet happened. Just give them a quick review to make sure they are still accurate and reasonable before you take them as finalised for this exercise.

Compare the baseline against the current and future positions. You can do this with a table that shows the milestones, or a Gantt chart that shows the various different bars on the same chart so people can see slippages and changes.

Talk to the team

When you have prepared your analysis of the baseline and current/future position, circulate the comparison for discussion.

Ask:

• Does the future schedule look OK?
• Do we understand why the dates have changed since we baselined the project?
• What assumptions have we made and do these need to change now?
• What future changes do we anticipate based on what we see about past performance?
• Who else needs to be involved in this discussion?
• What steps should we take next?

And anything else you think is helpful to ensure that the discussion is productive and you get what you want out of it – which should be increased confidence in your future scheduled dates.

You’ll probably find that there have been some changes that have not yet been reflected in the schedule. There might also be some interesting takeaways about why things changed. Feed these into the lessons learned documents – in fact, it might be valuable to have this discussion on scheduling as part of your pattern of retrospectives.

Schedule analysis is a useful tool to understand what happened and take from that some actions or learning that would help you do things differently in the future. In addition, it helps with being able to set expectations for stakeholders so they have the confidence that the schedule is deliverable and the team are onboard with what they need to do when.

What other tips do you have for using project baselines? Let us know in the comments!

I’m lucky in that the projects I am working on at the moment have a requirement for resource time, but we can manage the work in-house so we don’t need to invest in anything else. However, in the past I have managed projects with substantial budgets – and also those with small budgets.

Personally, I think that managing smaller budgets is harder because there is less wiggle room to lose a small amount in the rounding, but we have to work with what we have.

When something on your project changes and your budget is reduced, you might have to look at creative ways to make the money go further. Here are some suggestions.

Find angel investors/donors

OK, let’s get this one out the way first! I got this example for the Project Management For Musicians book by Jonathan Feist, and it’s clear that it won’t work for all kinds of projects. I couldn’t run an SAP deployment by finding a lovely benefactor who just happened to want to sponsor an ERP implementation from the goodness of their heart.

But if your project is to run an event, stage a show, or something similar, perhaps this is an option for you. For example, if a benefactor donated a certain amount, they could get a free ticket to the gig.

I’m sure much of the world of PR and event management taps into this option all the time. If you do go down this route, just be sure to make sure whatever you do falls within the ethics guidelines of your organisation as you don’t want to be seen as taking or giving bribes or hospitality gifts that could get you and your company into trouble.

I’m including this one really as a prompt to ask you to think creatively about the situation you are in and what might address it.

Do less: reduce the scope

The classic way to save money on a project is to do less. Look for chunks of the project that could be pushed into a Phase 2 or subsequent initiative.

Typically, if you remove scope, you are also removing cost because the work takes less resource to get done. Analyse what could be removed to save money but would have minimal impact on the end result. There probably isn’t much that falls into this category, but there might be something.

Do different: change the scope

Another common way to reduce spend on a project is to look at changing the scope to deliver the goals in a different way. What about these switches:

• Skip an expensive live in-person launch for a virtual tour
• Replace classroom training with video walkthroughs and online help
• Use a train-the-trainer model instead of asking the software vendor to train all employees.

What else could you switch? Let me know in the comments.

Change vendors

If your project involves buying in goods or services, you could also consider changing those providers. Perhaps another vendor would be cheaper, especially if you looked further afield.

Depending on the work, changing vendors could be more expensive, especially in the short-term. Pulling experienced contractors who know your business off a project and replacing them with remote contractors will have a learning curve, even if the skillsets of the two consulting firms are identical. Factor that in before you make any proposals.

Alternatively, consider the cost of bringing the work in-house. Would it be cheaper to hire someone on a fixed term contract than it would to get a supplier to do the work?

Bring benefits forward

Another option would be to look at how the project could be reordered to bring in some benefits earlier. For example, with a product launch, could you get a beta version out early to start bringing in some income that could be offset against future improvements.

If the deliverables can start bringing in some cash, that could change the financing of the work and improve the budget situation on paper, which might free up resources or investment for the next wave of development.

These are just ideas, and I hope you don’t have to use them!

Project documents (and there are some good templates here on ProjectManagement.com) are important to keeping projects moving, and many times, a project will start with a business case.

You might accept the need to do a business case as part of the organisational process – just something you have to do to tick a box. Maybe your organisation doesn’t use them in a formal sense, but each project has to be justified in some way – whether that’s a slide deck or even an email. There is some ‘reason to work’ that kicks off a project.

But have you ever really stopped to think about what role a business case really plays? If you do them, I think we shouldn’t take them for granted. If you don’t do them, it’s time to start.

Here are a few reasons why it is advantageous to have a business case before the work begins.

Understand the scope

The process of putting together a business case helps everyone involved understand what the scope is going to be. And if they don’t like what that looks like, they have the opportunity to influence it early so the scope better aligns with the direction they want to take.

Understand the issues

Perhaps there are concerns, issues, risks or challenges that decision makers need to be aware of – there always are. The discussions that feed into the business case help make sure that everyone is aware of what those are and what implications they might have for the work.

Fact-based decision making will give the project a better chance of success. The leadership team can weed out the ideas that won’t work before any time and effort is spent on them.

We can frame this conversation by thinking about project viability. Having a thorough discussion of the issues makes people aware of whether a project is viable and will continue to be viable throughout the delivery phases, despite any challenges that may arise.

Understand progress

Finally, a good business case lays out information that is useful for managing the work, monitoring and controlling progress. For example, a schedule of stage payments or key milestones, scope elements or deliverables.

The business case isn’t the project schedule and you will need more than simply the business case, but if it is a well-thought through, well-prepared document, there will be enough in there to help set up adequate project tracking.

The document should also set out success criteria and/or benefits which give you the framework for evaluating success as the project progresses.

As a project manager, you might be thinking that putting together the business case is not really your job, and you’d be right. However, on the projects I have worked on, it’s always been easier to get up to speed and start work when I’ve been involved from the business case stage or earlier.

That doesn’t mean doing loads of work – just being interested and talked to and maybe asked an opinion about the resource information or timeline that should go into the document.

Then when I come to lead the work (assuming it gets approved), I have a better understanding of the ‘why’ behind the project and the decisions that have already been taken.

Do you have a business case template that you are happy with? If not, check out some of the templates on this site as a starting point, and adapt one to give you the information you need to start your projects from a good place.

I don’t think of myself as someone good at delegating. I tend to want things done when I want them done, and it’s easier to do them myself rather than waiting for someone else to do them on their time (thinking about household chores here…).

But as I have got on in my career, it has become more important to learn how to delegate, and to do it well.

Here are 5 risks that present when you delegate something and what you can do about them.

1. The job is done badly

There is a risk that the job is not done to the standard you require. This could happen if the person is not capable of doing the work correctly, perhaps because you’ve delegated to the wrong person – someone who has not been trained, for example. There might have been a hiring error: someone looked great on paper and performed well at interview but they aren’t really right for the role.

2. The wrong job is done

There is a risk that the wrong task is done completely. This hasn’t happened to me often, but on one project we did have a team member edit the wrong version of a document, and that work had to be done again. Miscommunication was the reason that happened, so again, this risk should be totally within your control as the project manager to mitigate.

3. The job goes overbudget

There is a risk that the work costs more than if you had done it yourself, for various reasons including it taking longer. I had this with copywriting I outsourced. The person who took on the job did an excellent job, but in the end it required more rework than I had anticipated, so it cost more.

4. The job takes longer

There is a risk that the work takes longer than planned. This could happen because the person you delegate to is busier than they thought they would (or that you thought they would be) or their priorities are changed by their manager. Or they simply work slower than you would do, and you estimated the task based on the speed that you would do it yourself.

This can happen when work is delegated to less experienced colleague as well: typically, experienced staff take less time to do the same job as they don’t need to do so much research or checking.

5. The job is not done at all

There is a risk that the work is not done at all. This could happen as a result of you thinking you delegated but you actually didn’t: manager error, for example, the email got stuck in your outbox. Or perhaps you communicated so gently that they didn’t pick up on the fact you were actually asking them to do the work at all.

It could also be an error on their side. Perhaps they dropped the ball and haven’t got round to it yet, or they have deliberately chosen not to do it and are ghosting you. I think this scenario is rare, but I suppose it could happen.

What risks have you found from delegating? Any to add to the list? Or have you been in any situations where you’ve delegated and it hasn’t turned out exactly as planned?