The Money Files

Have you found yourself short of time on a project? It’s happened to me more often than I can count – “If only we had a bit more time,” we say, as we hurtle towards the scheduled go live date.

But can you make more time on a project? Kind of. Here are 7 ways to save time on a project.

1. Add resources

The first, easiest, option is to add resources. Bring in more people or equipment so the job gets done faster.

Another option is to add more money to the project: with a larger budget you will have more choices. Perhaps you could opt for faster shipping or buy in an element of the project instead of having to make it yourself. If you’ve got contingency budget or access to a management reserve, can you make the case that it’s appropriate to use those funds in this particular circumstance? Make sure you can justify your ask.

2. Work in person

This one might be controversial, but I think there are time-savings to be made when you bring people together.

Working in the same room saves time on the back and forth of conversations done virtually. If you have critical deadlines, are deep in bug fixing or are supporting a go live, consider getting the project team together for faster results.

3. Review the scope

Review the scope and see what could be done in a smarter way: do you really need a print booklet of the annual report or could you manage with a PDF only? Could you move any activity to a Phase 2?

Changing the scope to save time usually means doing less, so it’s only an option if you can deliver a decent result for your stakeholders by taking shortcuts. Make sure they are onboard with your recommendations and have the final say about what gets cut.

4. Review the schedule

Review the timeline. Look for discretionary dependencies: the ones you can move without it being a huge deal. Put tasks in parallel instead of in sequence but accept the risk that comes with this. You might end up doing work twice or revisiting things that are technically ‘completed’ because working in parallel might throw up some challenges later.

5. Review assumptions

What assumptions have you made that may not actually be true? This is particularly relevant about people’s availability. For example, if you assumed you could not work on site after 6pm because that’s what has always been the case in the past, it is still worth finding out whether you could extend on-site hours for this project. That could save some time.

6. Review the staffing

Can you switch out the apprentice for a more experienced (and therefore faster) colleague? What could be done before the expert gets their hands on it? Perhaps a colleague could draft the test scripts and have the experts in the test team polish them up. That way they don’t have to start from scratch.

This doesn’t always pay off. I know from editing articles from other writers that sometimes the editing is just as time-consuming as writing the whole thing, but it could work in certain circumstances so it is worth considering.

7. Be your best self

Finally, be someone people want to work with. Make sure you invest the time with stakeholders before the challenge of delivering faster arises (I know, you don’t have a crystal ball) so they are prepared to work with you when times are tougher.

You can’t switch this on as a last minute shift around, but approach your project team and all the work you have to do as a kind, professional leader. And you never know, when you ask other people nicely for help, they might just say yes.

Every project needs a go live project checklist – at least, projects where there is a substantial ‘go live’ moment, like a software launch.

The checklist is helpful because it confirms what is needed to go live: the steps and actions that should have been completed. It’s a reminder of what work is required in the run up to the big launch – or the small launch if you’re doing things in a phased or incremental way.

I’m a big fan of go live checklists because they help take the emotion out of the decision about whether or not we are ready. If we have ticked all the boxes, we’re ready. It makes the go/no go call very straightforward.

Here are some typical things to include on a checklist, although bear in mind that every project is different and you’ll need to make sure the items on your list match what it is you are doing.

• Technical infrastructure in place for the production environment
• Adequate staffing in place and critical staff available, taking into account holidays and sickness etc – too many people off and we might delay the launch until they are back
• Support teams and helpdesk briefed
• Go live plan produced and circulated
• Business acceptance testing complete
• Contact list created and circulated
• Communications about the launch drafted and approved
• Major risks reviewed and a decision taken about whether any of them are substantive enough to affect the plans.

We would also book a go live meeting. I remember one call we had for a big software pilot and going round the (virtual) table and asking each workstream leader to say ‘yes’ or ‘no’ depending on whether they felt the go live criteria had been met. It was a challenging call, because while we had on paper met the criteria, things were still a bit wobbly.

These conversations give you a chance to get all stakeholders on the same page about whether to go or not, and that’s helpful for creating a shared sense of responsibility as soon as you make the decision to get started!

I’ve noticed a trend towards incremental delivery and smaller launches, even on projects using a predictive methodology. There is still a place for a go live checklist, because getting everyone together to make a joint decision about next steps is still valuable. It’s the opportunity to get sign off on the approach and next steps from the business representatives, IT representatives, vendor, sponsor and anyone else who has an interest in what happens next.

When to use a checklist

Timing your go live is really important for maximum impact and availability of support staff. For example, we would never put an IT system live on a Friday as there would not be enough project team members around over the weekend in case of issues. We would put software changes in overnight, and have enough staff around in the morning to monitor the system and deal with any unforeseen issues.

Think about when you are going to have your go/no go call and when your go live is going to happen. The call itself needs to be close to the go live but probably not the same day, for example it would work well to have a call on a Friday for a Monday go live, or a Tuesday for a Thursday go live. But look at your schedule, consider the impact on users and make a decision as a team.

Do you use go live checklists? What other items would you put on a generic checklist? Let me know in the comments below and save this post so you can come back to it when you need it!

I’ve chosen a bad headline for this article: I have an issue with assigning tasks – it doesn’t feel like the collaborative, co-created environment I would like to work in. Ideally, we’d meet as a team to do some planning, have a workshop or two and then tasks would be selected by the right people. If we had Kanban boards, team members would be able to select what they want to work on – because as long as they are working on something, the board would manage the priorities and it would be all good.

However, sometimes on projects you do need to reach out to people and assign them work, even if you ask nicely. Sometimes it happens because it’s obvious who is going to do the work because there is only one person in the organisation who can do it anyway.

Let’s take ‘assigning’ in the broadest possible sense, so it doesn’t mean ‘expecting people to do stuff on a project without engaging them’. Because regardless of whether the work is obviously destined for them, it’s always polite to ask.

Here are 5 considerations to take into account when distributing tasks to team members.

1. Capability

They have to have the right skills. If you are looking for colleagues to contribute to your project, consider the tasks they are going to be doing. The person who ends up with the task has to have the skills to carry it out.

Of course, there are exceptions to that, and we often use people working through an apprenticeship or less experienced staff to complete tasks as part of their on-the-job learning. They will be supported by an experienced colleague, but if you don’t learn, you’ll never get the confidence or skills to do it yourself in the future. Factor in additional time, support or training budget if necessary so you can make sure the people taking on tasks are equipped to do them.

2. Cost

People need to be budgeted for at different rates. Consider the cost impact to your budget if you assign tasks to people who are expensive!

3. Availability

People’s availability is a constraint on your project timeline. If the person allocated to the task is on holiday, they won’t do it, and the task will be late. That might be fine – perhaps you have the flexibility to schedule around the best person for the role and the work can wait until they get back.

Perhaps you have a fixed date to hit and need to find someone else.

4. Location

Does it matter these days? I think it depends on the role. If I want in-person, classroom based train-the-trainer training so I have a team equipped to go out and deliver on site training, then I do need them to be within travelling distance.

If it’s a graphic design job, they could be anywhere.

Think about where the team members are based and whether that matters to the task in hand.

5. Cultural add

I was talking to someone the other day about one of their colleagues who was considered a ‘toxic cultural fit’.

The challenge with cultural fit is that it can be interpreted as simply hiring people who look like you and think the same as you, so they slot neatly into the environment without disruption. That’s not what this is about. Consider ‘cultural add’ instead. We want diversity of opinions. We want new ideas and different interpretations. We want disruption and challenge.

The people on your team should lift you up and make the team, and the solution, better.

What do you consider when working with your team to divide up the responsibility for tasks? Is there anything else you take into account? Let us know in the comments!

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!