The Money Files

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?

OK, the title of this blog post is a bit misleading. I don’t think I could count how many different ways there are to do estimating, I’m sure there are plenty of tools and techniques I’ve not used in my work as a project manager.

But there are some high level options for thinking about, presenting and sharing estimates with key stakeholders, and that’s what I wanted to dive into today.

I’m drawing on what PMBOK 7 says about different types of estimating, so you can refer back to that for more information. The guide talks about 5 different approaches to estimating, without mandating that any particular approach is used at any particular time – that’s up to you as the project manager to assess and choose the right estimating technique.

Deterministic/Probabilistic

Deterministic estimates are those that represent a single point. For example, 16 months, or $5,250. These are the easiest to understand but (I think) the hardest to come up with unless you have a lot of past project data and simple tasks that repeat.

Probabilistic estimates – why is that so hard to type?? – a those that represent a range. This is what I use most often in the thinking, even though when putting plans together we rarely represent the range in the schedule visually. This type of estimate often includes three factors:

The estimate itself with a range e.g. $5,250 +/- 10% or 16 months +1 month/-1.5 months.

This represents a weighted average based on several possible outcomes (like when you work out a three-point estimate with the most likely, optimistic and pessimistic outcomes), alongside what the range will be for the work. The result is often calculated by scheduling algorithms, but you can work it out manually, or even use professional judgement to make your best guess, as long as people know that’s all it is.

That brings us to the second factor: confidence.

A probabilistic estimate includes a confidence factor that represents how confident you are in the numbers. A 99.9% confidence factor would mean you’re pretty sure this is exactly how it is going to turn out. A 60% confidence factor – not so much.

Thirdly, if you are using computer programs to simulate scenarios and calculate estimates, you will also have a probability distribution, that shows the data and the range.

Absolute/Relative

Absolute estimates give you a specific number that stands alone. A deterministic estimate can be absolute. An example would be that to buy one machine costs £12,000.

Relative estimates are figures that only make sense in the context of other data. For example, buying more than one machine would be cheaper, but we don’t know how much by as the procurement team hasn’t finished the negotiations yet.

A better example, and the one in the PMBOK® Guide, is planning poker for agile estimating. Story points and T-shirt sizing help teams size the work in relation to other pieces of work but alone, “XL” doesn’t mean much to anyone else.

Flow-based

The final flavour of estimating talked about in PMBOK 7 is flow-based estimating. This type of estimating is useful where you know the flow of the work: the throughput and cycle time. If you know how many items of work can be completed in a particular time period (throughput) and how long it takes one item to go through the process (cycle time) then you can estimate how long it will take for a number of items to be completed, assuming other factors like sizing are taking into account in the calculations.

Regardless of how you do estimating, the data is only useful if people are bought into how it has been calculated and what the effort, duration or cost represents for them. Get the team involved in working out estimates and providing the assumptions that they are based on. Remember to adjust for risk, build in contingency where it makes sense to do so, and to keep estimates under review until such time as your confidence levels are sky high… which is usually once the work has been delivered and the task can be marked as complete!

I’ve been reading the Project Routemap Procurement Module and it’s got some really interesting things in around setting up a project for success. It’s a UK Government publication, aimed at large-scale public sector initiatives, but there is a lot we can pull out and apply to other, smaller projects.

The procurement module is one of several, and I’ve been reading it in light of it being a good resource for project audits and peer reviews. For example, there’s a short sidebar of different project documents and reports that might be helpful for finding out more about the existing procurement arrangements on an in-flight project. I’ve pulled out some from the list below, along with my own explanation of what these might tell you.

Procurement strategy

This will be the main one. The procurement strategy for your project might be a simple ‘we’re buying this thing’ in the business case or it might be a more detailed, evolved document that lays out a multi-year, multi-vendor approach.

ITT and bid selection docs

Invitation to tender (ITT), the responses and the bid selection criteria help you decide which supplier to go with. We also found them useful to go back to and review why decisions were made and what assumptions were made at the time. The bid selection criteria are so important to get right, so involve the right users and teams in pulling those together!

Regulatory and statutory requirements

Any compliance requirements that affect your project will also affect your ability to procure services from certain suppliers. For example, in UK healthcare, there are many requirements that must be in place to allow organisations to contract with the NHS. If the supplier cannot meet those requirements, that might affect the ability to deliver the service.

Sustainability strategy

Many organisations now have a sustainability strategy or environmental goals. For example, choosing to partner with suppliers who are making the commitment to working in sustainable ways, or only buying energy efficient light solutions, and so on.

There may also be environmental impact assessments for the project that show what the impact will be and how that can be mitigated or approached.

Contracts

Another big one: I remember having a bound copy of a contract on my desk during a long project. Not because we needed to refer to it to hold the supplier to account, but simply because it had useful appendices that documented the payment schedules, milestones, service levels and lots of other things I seemed to need to look up often.

Any framework agreements and other types of third party agreements (like heads of terms or service levels) would also fall into this category. They shape the relationship between the supplier and customer, so they are useful to know in detail.

Funding arrangements

If your project is being funded from grant income, or there is a limited window in which to spend the funding, or you have to apply for funding to be released in stages… all that is good to know as you enter the delivery planning. Funding milestones are typically big ones because you don’t want to miss the deadlines.

There are lots of others, like a contract management plan, supplier relationship management plan, the business case, stakeholder requirements, the benefits realisation plan and more. What else do you use when it comes to managing project procurements?

Have you got too much on your To Do list? What about the backlog – is everything in the ‘must do’ category? What about your project prioritisation process? How many projects are top priority, even when you’ve applied what should be reasonable and weighted criteria designed do rank projects based on importance?

Yes, I’ve been there. Everything is important and stakeholders want it all tomorrow.

We all know that isn’t possible, and in most cases, isn’t even desirable. Some of those ‘tomorrow’ dates will be totally arbitrary, and based on the shadow of a promise instead of fact-based, schedule-driven expectations.

But when a senior person asks you to do something, or your trying to guide the team through a prioritisation exercise, how can you manage all the things to do? Here are 3 tips for reframing your workload and helping stakeholders see what’s possible based on capacity and priority.

1. Go back to the ‘why’

What’s the benefit of doing the task, project or of delivering that feature? What’s the rationale behind it and the user impact? Think about how you can measure the success of the deliverable and what return it will provide. That doesn’t have to be a financial return, it could be a social impact return, customer satisfaction improvements or something else.

Understanding the reason for doing the task and what comes out the end of it will give you greater insight into priority. The project that has the largest return is normally worth doing over the project that has a small return. The automation task that you’ve been putting off setting up is going to free up resource time longer term, and that’s worth more to you than something tactical.

2. Yes, but…

When stakeholders are pushing for their tasks to be at the top of the list, ask for their help in prioritising. Say you can do the work, but at the expense of something else. What stops, or gets delivered later?

“Yes, I can take that on, but it means postponing delivering XYZ that you also asked for, until next week. Are you OK with that?”

“Yes, we can do that, but we’ve got a lot of other changes to work on first, so we won’t get to it until next month.”

The onus is on them to support the prioritisation effort, and it helps make them aware of the impact of juggling priorities – especially when their request impacts another stakeholder’s expectations.

3. Draw the line

One of the techniques we used in my old job was to maintain a list of changes and projects in priority order. We had a prioritisation model that everything was fed into, and the output was a ranked list of work.

Then we applied estimates to the work and reviewed the capacity of the team. That told us how much work we could take on as a department and what was next in line for when there was availability to pick up something else.

It was a spreadsheet, and it literally had a line under the work we could do. Everything under the line didn’t get worked on.

If someone expects their work to take priority, it needs to go through the prioritisation route. Sharing the list (and the line) with stakeholders helps them visualise why you can’t simply do it – even if it’s a small thing.

“Yes, that’s fine, it will take longer than normal to work its way through testing because of the volume of work the team has on at the moment. Oh, you need it sooner? Let me share the higher priority items with you if this takes precedence, so you can see what other stakeholder commitments we’d need to drop to do this more quickly. Perhaps you could talk to those stakeholders to agree the overall priorities? I’ll put a call in.”

What else do you do to help protect your time and prioritise your work? Let me know in the comments!