The Money Files

Fuzzy dates are dates that have a bit of wiggle room. They are approximate dates, placeholders, flexible time periods rather than a fixed date. For example, “week commencing 27 January” is a non-precise date, that offers some flexibility, and so is “Quarter 1”.

Why would you plan with fuzzy dates rather than precise dates? Precise dates can be better as they give more certainty, but sometimes you just don’t know. For example, if you are doing rolling wave planning, or any type of iterative planning, you might not have the right level of detail to commit to a fixed date at this point.

Managing risk

You might be dealing with a lot of risk, and fuzzy dates allow you to build risk into the schedule by giving yourself a relatively large window in which to complete the work, driven by unknown factors such as what the weather will be like and whether that will enable you to complete the work or not.

Using fuzzy dates can help reduce the risk of unrealistic scheduling by acknowledging potential unknowns early. You aren’t just guessing at what the risk will be or what impact it will have on the schedule, or hoping that you can hit the specific milestone. You’re building contingency into the schedule which helps keep the project timeline realistic when you can’t (yet) commit to specifics.

Probabilistic ranges and conditional dependencies

Sometimes, fuzzy dates are expressed as ranges (“2-4 weeks from now”) or probabilities (“likely to happen by the end of March”). That gives you an indicative time frame without a hard commitment, and I find it’s quite a good way to set expectations with stakeholders. You can always explain why you are presenting ranges instead of fixed dates.

One of the reasons that drives ranges is external dependencies (“The materials will arrive some time in the first half of February but the supplier doesn’t know exactly when…”). Another example is when you are waiting on feedback from either internal reviewers or external clients, and they haven’t committed to providing an exact date by which they will get back to you. A task might be due “two weeks after client approval,” where the actual start time depends on an external party.

Moving on from fuzzy dates

Of course, you can’t have everything as a fuzzy date, and there comes a time when you can switch out your ranges and vague commitments for something more concrete. Incrementally refine your project schedule and replace the fuzzy dates with specific dates as more information is known and your confidence levels improve.

Communicating fuzzy dates

In essence, fuzzy dates provide a way to communicate tentative timelines while keeping the schedule flexible and adaptable, making them valuable in early-stage planning or for projects with high uncertainty.

However, they are a pain to show on a schedule unless your scheduling tool allows for the presentation of earliest/latest completion dates. In one of my mentoring sessions recently we talked about using earliest/most realistic/latest date markers on a PowerPoint timeline or using a bar with gradient colours fading out at each end to show the ‘fuzzy’ part of the timeline.

Some software tools will display start and end dates with a range if you have these parameters set; others will only work with a specific date as the end date, which is why in the main the project managers I have spoken to tend to create another timeline (often on a slide) to show the concept. Or you just create a task that stretches out to the latest possible target date and use that, making the fuzziness opaque and avoiding talking about it at all.

How would you do it?

Are you thinking about year-end project audits? Perhaps your PMO is thinking about how to learn from the past year. Perhaps you want to set a good foundation for projects next year. Perhaps you just had a rubbish past few months and want a second opinion to see if there was anything you could have done differently to avoid the outcomes you got.

Whatever your reason, many project leaders’ thoughts will be turning to audits at this time of year, so let’s talk about how to make the most of this exercise – it’s not as awful as you might be thinking!

Planning the audit

First up, make sure the audit is planned in. Schedule it in advance to ensure key team members are available.

Look out the documentation that is required, which is normally things like financial reports, scope changes, and risk logs. You’ll also want to make sure that the business case, project plan, and schedule are available, as well as any change requests that changed those, so the auditor can compare the original planned baselines to the current baselines.

Key areas to audit

So what is your audit going to look at? Whether you have been asked to audit someone else’s project, or you want projects in your PMO to be audited, here are some things you’ll probably want to put on your checklist.

• Budget vs. actuals: Compare planned spend to actual spend and do the same for resource utilisation if you have the data.
• Scope management: Look at how many change requests the project had and whether that resulted in managed change or scope creep. Personally, I don’t think it is important to assess whether the project stayed within its original scope – what you are looking for is whether changes were assessed and approved rather than being done in an ad hoc manner.
• Risk management: You’ll want to go through the risk log to see how well risks were managed, mitigated, or exploited.
• Quality of deliverables: If anything has been delivered so far, check to see that the quality is comparable to the targets set. In other words, are there post-go live bugs still to sort out, and does the product meet quality expectations?

Identify lessons learned

The main purpose of an audit is to review what worked, what didn’t and what needs to change (or be continued). So you can think of the output of the audit as a sort of lessons learned report. If you already have scheduled lessons learned activities, you can feed those in to the audit report. If not, it never hurts to have a lessons learned conversation with the team.

Set the stage for next year

If your project is running into next year, discuss how the results of the audit can be used to improve processes, define new standards or ways of working, and inform the next year’s project strategy. There might be some easy things you can do to change up how things work to make them more effective.

Whether the outcome is a lot of things to change or the reassurance that you are doing everything right, it’s a good time of year to be reflecting on project management practice. Take stock of where you are and how far the project has come, and if an audit is offered, say yes! It really is a good learning experience.

As a project manager, there are two types of self-management I have to do.

Proactive management is looking ahead, making sure I know what is coming up.

Reactive management is addressing the challenges of the day, fire-fighting and being asked to do something on top of my existing workload.

Proactive management

I think proactive management is where most of us should be spending most of our time. We should be looking forward, using risk management, horizon scanning or whatever you want to call it to get a good idea about what’s coming.

For example:

• Future projects that your manager is going to assign to you.
• Upcoming milestones that you need to check in on and make sure are on track.
• Risks that have a close proximity that need active management.
• Engaging stakeholders so they know what is coming (with the goal of reducing ad hoc queries or report requests).
• Big meetings or meetings where you have to prepare documentation or submit proposals/presentations/papers in advance.

These are all things that we should know are happening or about to happen and then we can plan our time appropriately around that.

We find out about these things by staying curious, asking management, putting time aside to review the project schedule alone and with the team, and listening out for things that might be a problem. The more you spot coming, the more you can work around it, or into it so it can be handled at a time that suits you – not at the last minute creating a fire you have to run around and put out.

Reactive management

It’s much harder to manage time when you have to spend it reactively responding to whatever is dumped on your desk that day. It could be a project task that someone else was supposed to do but hasn’t, and just needs to be done, it could be new work to do with your project (like setting up a meeting with 10 attendees that has to be at a particular time but no one has calendar availability at that time… don’t ask me how I know!).

Other examples would be things like:

• A supplier letting you down and not delivering goods on the specified day.
• Someone being off sick and not being available to complete a task that’s on the critical path.
• A senior executive asks for an ad hoc report on project progress for a committee meeting that is tomorrow.

Building resilience in yourself and the team is a good way to manage the short-notice requests and feel more capable of responding in the moment.

In my experience, the better I am at proactively managing upcoming situations on my projects, the less reactive management I have to do – but I know it does not always work that way. Generally, though, the more you can anticipate senior leaders’ needs, complete your risk management actions, identify problems before they become a ‘real’ problem and so on, the less reactive fire-fighting you have to do.

Admittedly, you can’t necessarily foresee that the weather is going to cause problems, or that a supplier might have difficulties fulfilling orders, but if you have identified these are risks, you will at least have (hopefully) spent some time thinking about how they might be mitigated or addressed if they do happen.

Do you spend your time between proactive and reactive management – and is this distinction a helpful way to frame your work? It really works for me, but I don’t know if it’s a common way of thinking for other project managers. Let me know in the comments!

As much as we’d love to have everything working to plan, sometimes we can take some aspects of project management for granted. I wonder how many of these project challenges you have but you haven’t openly recognised within the team?

I don’t want you to have your head in the sand, so below I share 10 things that you might be missing on your project.

(I didn’t want to bury my actual head in the sand, so you got a photo of my feet buried instead! Not quite the same, I know.)

1. Stakeholders are reading your communications

We might believe that stakeholders are reading our project comms, but are they really?

It’s hard to tell, but if you aren’t seeing any action, or people are asking questions you have already answered in your comms, then they probably aren’t.

2. The training you’ve scheduled is enough

I expect it isn’t, even if it feels like it should be. People won’t turn up or won’t use the online training to teach themselves. Plan to have post-launch training support because your users will need it.

3. Your change management plans are adequate

Hopefully they are, but as above, there will always be someone who says they didn’t get the memo, or couldn’t access the materials. Make sure you’ve got post-launch training in the diary as well, and do more change management activity and engagement than you think you should have to.

4. The UAT plans are long enough

UAT is the one thing that gets squeezed in my experience. Add in an extra cycle if you can. It’s easy to take it out – not so easy to squash it back in if you do need more testing time.

This obviously depends on your project – if you are doing something you’ve done a lot before you should have a high degree of confidence in your deliverables, but you might need more if you are working on something new.

5. Risk identification has spotted everything

It hasn’t!

Make sure risks are constantly mentioned in all meetings, and that you are always listening out for what might be a new risk.

6. Team morale is OK

Team morale is something to keep an eye on. The team can get demoralised for the smallest of reasons, from a change not being approved to a reschedule for whatever reason. That negativity can spiral.

Even if things are going well on your project, events outside the project can influence morale, such as a change in leadership, redundancies, an increase in BAU work or pretty much anything else.

7. Benefits are understood

We’d like to think the financial and tangible benefits are understood, but how well have those assumptions been documented? I’ve worked on a couple of projects where we think we understand what we are tracking, only to find that we can’t replicate the exact formula the finance person (who has now left) used, or some other difficulty.

You should be able to answer straightforward benefits-related questions like ‘is this incremental revenue or total revenue’? So make sure you can.

8. There is no conflict in the team

There probably is, but people are too polite to mention it. You should dig for it! Some conflict is healthy so don’t worry about bringing it up.

9. Quality is being managed OK

Are you finding bugs in your deliverables? And more importantly, are you squashing bugs? What are your criteria for exiting testing and how does quality play into that? Ideally, you should have great quality measures, and be performing in line with those, but sometimes project teams get swept up in the desire to deliver and that means some lower-risk bugs are left in for now.

10. There is no technical debt

Are your project deliverables introducing technical debt? Are you breaking things elsewhere or for other teams, or introducing workarounds or degrading the solution for someone else? Sometimes your part of the world might be fine, but a process you’ve implemented ends up in many additional steps or a new report being needed for someone else.

Check that you aren’t creating technical debt by accident – if you know about it, document it and have created it ‘on purpose’ as part of a stepping stone to a different solution, then that’s probably fine.

Which of these might your project be at risk from? Let me know in the comments!

Are you starting a new project? As we get closer to year end, we seem to be starting more projects that will (somehow) finish in-year! If you are kicking off a new piece of work, whether you’re delivering by year end or have a longer timeframe, here are some tips to consider to ensure you are starting off in the best possible way.

Get the right people

First, you need to understand the capabilities required to deliver the project. Then you have to make sure you have people with those skills (or people with the aptitude and time to learn them).

It’s not just about the do-ers. You’ll also need a project leadership team (a project manager, sponsor, maybe exec sponsor and programme manager) who have the skills to lead and are empowered to do so.

Create your Charter

Whether you call it a project initiation document, charter or kick off document, you’ll want something in writing to document what you are doing and how. But the real value of this is in the discussion that you have while pulling together the content. The right conversations are essential to make sure the right stakeholders are involved, everyone is aligned on the objectives and the scope is clear.

Set the tone for the team

We talk a lot about culture and I’ve written about psychological safety before. Start as you mean to go on, so set your ground rules, working practices, terms of engagement up front. Make sure that anything that affects the delivery team involves them (so no setting project delivery dates without the people doing the work in the room).

Set up your document repositories and communication schedules so everyone knows what to expect and where to find the latest information.

Consider risk

As part of your project initiation work, you should be creating an initial risk log. But considering the impact of uncertainty on your project goes beyond that. Make sure you’ve got enough contingency in the plan, especially in the early days until estimates can be firmed up with more data. Make sure stakeholders know about confidence levels and be transparent about what you think can be achieved, so their expectations are managed.

Sort out your governance

Exec confidence comes from knowing the project is in safe hands. Governance might feel burdensome at times, but it ensures the right work is being done by the right people at the right time.

Make sure you know how the project will be held to account, and what the success criteria are. Set up your peer reviews and stage gates. Book steering group meetings and regular check ins. Dig out your reporting templates. These processes will ensure that there is trust in the process and that leaders feel confident that the project can (and will) deliver.

Setting your project up for success is crucial because those early days set the tone for how the work will be done. Spend a bit of time – and I know, you’ll have to negotiate for that as I expect everyone wants the work to have started yesterday – and you’ll have a greater chance of delivering successfully. Good luck!