The Money Files

Let’s not kid ourselves: optimism bias creeps into most things we do. I’m certainly guilty of it: “Yes, of course I can finish that slide deck for the board today, even though I’ve done nothing on it yet.”

Project teams at all levels of experience and in all sectors tend to approach their work optimistically; it’s human nature. In UK government projects, they even have a process for addressing optimism bias. Estimates are expected to explicitly adjust for bias when stating the costs and benefits. I think this is fantastic. It forces people to think about what is realistic and what bias they might be bringing to the table. It helps highlight risk too.

The published Guide to Developing the Project Business Case also talks about adjusting the adjustments down again when there is some performance-based evidence to show that the project is progressing to plan. So we don’t have to worry about padding the estimates forever – they can be readjusted as and when you have more specific, data-driven information to include in the forecasts.

The guidance even includes what percentage increase to use on your estimates to counteract the effects of bias. Of course, you can choose to use whatever you feel is the best adjusted value, but the numbers given for time and cost are based on a study by Mott MacDonald and are a good starting point if you don’t have internal data to draw from.

(As an aside, if you don’t have internal data to draw from, what are you doing to start building up that repository of information? Given the amount of data we capture in our project management tools these days, and the prevalence of AI tools to help us interpret and interrogate it, we really should be setting ourselves up to rely on our own data sources instead of industry-aggregated ones. But in the absence of your data source being substantive enough on its own at this time, do tap into published data sources as a starting point.)

For example, the suggestion is that for a software development project, you should add 54% on to the schedule! I’m not sure my stakeholders would agree with that as it seems an awful lot of padding. However, past experience tells me that this is probably not far from the mark realistically. 54% is the top bracket – you could opt to add the lower bracket of 10% or anywhere in between.

It also suggests adding between 10 and 200% to the project budget to bring you more in line with something you can realistically achieve. Again, I’m not sure my sponsor would go for doubling my budget ‘just because’ but I think these numbers open up the conversation to allow us to talk about risk and the validity of estimates.

The guidance suggests that you start with the upper limit and then work back from that based on whether you feel the optimism bias can be or has been reduced. For example, have risks been managed, have estimates been fully throught through in a robust way and benchmarked across industry actual results and so on.

If you do take this approach, make sure that everything is documented and you can explain your rationale for adding an adjusted figure – including why you haven’t been able to mitigate against optimism bias (yet). Stay transparent and keep talking about what it means for the project.

What do you think of this approach? Let us know in the comments!

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!