The Money Files

The Planning performance domain in PMBOK 7 covers all things relevant to making sure the project is adequately planned. We want to address all the work required to deliver whatever the project is delivering, and to do so in an organised, thought-through way.

Planning for the financial aspects of your project is covered by this domain.

Budgeting

Budgeting is the obvious one: as part of putting together the early steps of getting our project off the ground, we need an idea of how much it is going to cost. That means taking info from the task and work estimates and using that to create a cost estimate.

Building out the cost baseline forms part of the project planning activity and then it’s used to track against. Project performance can be measured against the baseline, in the same way you do for tracking schedule activities. In fact, combine cost and time schedules help you phase the spending. Even if you don’t go ‘full EVM’, a phased budget is helpful for the finance team to manage cash flow and for the project team to track whether work is broadly happening at the expected pace.

Financial management

Knowing how you are going to manage the finances is also useful and worth working out at this point. For example, how often are costs going to be reviewed? What contingency reserves are going to be put aside and how will the team access those? What’s the process for getting purchase orders raised and invoices approved for payment? Do you have access to a management reserve and if so, who is going to approve using that funding?

Procurement planning

Most of my projects involve buying things from suppliers. Whether it’s something small or a multi-million pound deal, procurement activities are a big part of what we do.

It’s important to spend time in the project planning phase thinking through how procurements will be managed. Will you have a dedicated procurement professional to manage the contracts and run point with suppliers? Who is going to manage supplier relationships? What’s the process from choosing a supplier and negotiating a price to actually getting the contract signed off and the order raised? I know from personal experience that this process is easier said than done!

If you have someone managing the contracts on your projects, they will need to know what the project needs to buy, when the team needs it for, what the lead times are likely to be and a lot more. Given that at the moment the lead times on all kinds of equipment and building materials seems to be extending – our own build project at home has been delayed – and the price of materials is rising – it’s really important to be all over the numbers, process and plan for this aspect of your project.

There’s more to the Planning domain than simply thinking about the money and contractor relationships, but these aspects are essential if your project involves procurement work. It’s all too easy to get sucked into scope discussions and deadlines and milestones – because executives want to know when the project will get delivered, not who in Finance is going to be processing the requisitions.

So this is just your friendly reminder to make sure you allow adequate time in the planning stages of your project to factor in the finance planning – and that it’s an ongoing activity for each stage, and as your project evolves.

I was contacted recently by a reader who wanted to know how to best prepare for starting work on a merger project. It wasn’t something she had done before, and while she wasn’t 100% responsible for the work, she wanted to feel a bit more confident going into some of the early discussions, especially around how she could shape the project management work to support the integration efforts.

Here are 5 things I thought she would benefit from starting with.

1. Due diligence

The first stage – at least in this case as the deal wasn’t yet done – should include due diligence. It’s important to know what you are letting yourself in for. As project managers, we don’t necessarily get involved in that. In my experience, it’s an exercise led by the Legal team with input from subject matter experts as required. But it should definitely be on the project plan.

2. Stage gates

I manage a lot of projects quite informally, but a merger wouldn’t be one of them. If you are in this situation, see if your PMO has a template for stage gates and work out what the project lifecycle would look like. Think about what criteria are going to be required to move out of one phase and into another. I would define those criteria so everyone is clear about what they look like and there is general understanding about when the project gets to move on.

3. What to merge

What, exactly, gets merged in a merge? There might be brand assets to redo, websites to redirect, but also teams to merge and processes. There might be IT systems or physical equipment.

What about legal contracts that need updating, or intellectual property? There is a lot to consider, so some project management effort should be put into identifying what actually needs to happen and when it should happen. It’s likely that the integration efforts will take some time, so it’s going to be a staged approach. When you know what needs to happen, you can help business leaders organise that into workstreams or phases that best represent the work.

4. Outputs

What does the world look like when the merger has happened? There might be a new vision, different approaches to staffing, new processes. Similar to identifying what needs to change, think about how you will know when you’ve got there. What are the success criteria? How will it feel? How will it work?

That’s a good exercise to identify what the outputs are likely to be, and therefore what work needs to go into making sure those outputs are delivered.

5. Ways of working

Finally, as with all projects, it’s worth thinking about how the project will run. How do you want it to run, and how can you influence how it is run?

Think about stakeholder engagement, what communications are required, how progress and performance will be tracked, what governance is required, what project controls look like… all the normal things. With so many moving parts on a project like this, it’s even more important to make sure everyone knows what is required of them and how they can contribute.

This type of project can be very complex, with a lot of risk attached, especially to do with losing key staff and market reputation. If the project feels big, it might be worth getting in some specialist help from project leaders or consultants who have done similar work before.

What else would you suggest for someone managing a merger or acquisition project? Let me know in the comments!

How many of your projects got started just because someone said they should? When times are tough – and in the UK there is certainly a tightening of belts happening – we need to make sure we are working on the right projects.

The pipeline is so important, and that’s why your business case needs to stand out – so you can secure the funding to get the work going.

Don’t think business cases are necessary? Let me change your mind. Here are 5 reasons why your project needs a business case.

1. A business case shows your project aligns with strategy

We do projects to make a difference and deliver change within the organisation. That change should be aligned to the strategy because then we can be sure it delivers to the overall plan for the business.

Your project is more likely to get funding if you can demonstrate it supports the organisation’s objectives.

2. A business case shows the work is commercially viable

Do the numbers stack up? This is what we ask ourselves in our project office – all the time. However good the idea, the project has to be viable. You need to be able to secure the supplies, equipment or resources at a rate that makes it financially attractive.

Use the business case to show the rationale for make-or-buy decisions, or explain why you have selected a particular supplier.

3. A business case shows the project will be a long-term financial success

Part of the work involved in putting together a business case is the thinking. It means you’ve secured support from various parts of the organisation. It means you’ve done the maths. There is a justification for delivery and you can evidence the thought process that sits behind that.

Generally that means that there is a commercial reason for doing it: for example updating old equipment that supports bringing in new business, or launching something that will sell. You should show consideration for costs along the whole product lifecycle, including decommissioning anything that is no longer required and the cost of managing the asset once it is created.

4. A business case shows you’ve selected the right response to a challenge

Business cases typically make a least a nod to other options that have been considered and rejected. There should be an options appraisal section that looks at a range of solutions and summarises pros and cons.

The document focus on the solution you are recommending, outlining why that’s the best choice. It should be clear why that route forward is the best fit for the organisation’s goals and capacity to deliver.

5. A business case shows the project management structure is in place to support the work

It’s no good securing funding for an idea but not having the first clue about how to implement it. The business case will have a section on implementation plans, covering what resources are needed (and how much they cost) and how long it will take. There should be an outline, high level plan with milestones. There will probably be some high-level risks, assumptions and constraints – the bones of a project initiation document or charter.

Help decision makers understand what they are signing up to and what is required to deliver the change, should they go ahead and approve it.

That’s why you should have a business case. What other reasons can you think of? Let me know in the comments!

The market seems pretty buoyant at the moment for project management jobs: if you remember back, PMI predicted a while ago that the world would need many new project management roles filled to meet demand, and while I don’t have hard facts to back it up, anecdotally there seems to be a fair number of roles around at the moment.

The good news is that many roles maintain an element of remote working, with some vacancies being advertised as fully remote, so location is no longer a constraint when looking for work.

If you are in the market for a new role, and are getting ready to hit the interviews, then here are some tips that might help you impress recruiters and land that premium position.

Read the job advert carefully

I know this seems obvious, but if you go back to the job advert before your interview, you can pick out keywords and skills that they are likely to want you to evidence. The time between application and interview can seem like ages, so keep a copy of the job ad to remind yourself of what you applied for.

Read the person spec and any other info

Go through the person specification or further information about the role like the job description. Again, you probably did this on application to see if you were a good fit for the role. This time, you’re reading for the main skills that are likely to get asked about at interview.

If there are any buzzwords, power skills, notes about past experience, make sure you put some time aside to come up with examples you can talk about during the interview that show you have those skills.

Read up on the company

What can you find out about the company and team you are applying to join? Check sites like Glassdoor, see if any of your connections on LinkedIn work there, check customer reviews for a sense of what is important to them.

Read the annual report, check out their social media presence and watch any videos from the senior executives if any exist in the public domain.

This research is a useful source of information about values, culture and whether the company is a good fit for your future ambition. It’s also helps you come up with questions to ask at the end of the interview, when the interviewer inevitably asks you if you have anything else you’d like to know.

Speaking of which…

Make a list of questions to ask

Come up with three or four questions to ask at the end of the interview. You want a few to choose from in case some of them are answered within the interview discussion itself – if that happens, you might be left with nothing left to ask, and I think it always looks good to have something to say at that point.

Remember, you don’t have to wait until the end to ask. If the conversation drifts on to a topic relevant to your question, ask it then. After all, the interview should be a conversation rather than an interrogation.

Finally, remember that this is your chance to find out if the company is a good fit for you. Taking a job that is not right for your values, work/life balance, skill level or anything else that makes it a bad choice is only going to be something you regret in the future. Possibly in the very near future.

Use the interview as a way of checking that what you have learned about the role and the company holds true, and that you would like to build the next phase of your career there. Then go in and knock their socks off!

Once you’ve ticked ‘mitigate’ as your risk management approach, you then have to think up ways to actually do that. What could you do to make the impact or likelihood of the risk less? Here are 4 options for reducing the risk – they won’t work on every risk, but they are general directions to consider when you’re wondering what to do to lighten the load for the project. And they are pretty easy to implement too, so that’s a bonus.

1. Start small

One of the easiest risk mitigation strategies is to start small. Consider prototypes, models, pilots. Think about how you can avoid a big bang launch and deliver results incrementally instead.

This works well as an approach if your project is using new technology, a new supplier, or is changing something sensitive, like a business critical process.

It doesn’t always work: on one large project I worked on we planned to deliver site by site, rolling out the new software and processes to groups at a time. But it didn’t work: for accounting reasons we had to maintain the integrity of the financial records and go big bang.

However, as a starting point, doing test runs and phased delivery is a good approach to mitigating all kinds of risk.

2. Schedule testing time

How many projects have you worked on where you’ve had enough time for testing? I’m embarrassed to say that plenty of my projects have ended up with testing time being squeezed.

As a project manager, you can control the schedule and double the amount of testing time planned (or whatever allocation of testing you feel appropriate, given input from the people involved in the work). That should give you long enough to wheedle out the bugs, which is another way of mitigating go live risks.

3. Add contingency to the schedule and budget

Explicit contingency is ‘extra’ time that is designed to offset risk: the risk of not knowing what you are doing, or whether it will work!

Manage uncertainty by adding a buffer to the duration of scheduled activities (or at phase level) and also to the budget.

I prefer contingency to be explicitly called out as an additional 10% of the budget and appropriate length for schedule contingency. Document what your approach will be in your schedule management plan and financial management plan.

4. Understand the guardrails for the project

Guardrails are like boundaries; tolerances for what freedom of action you have on the project. When you know where you have wiggle room and where you do not, you can make better decisions. Ultimately, your course of action to mitigate a risk should become easier because you know where you can save time and effort and where you cannot, because doing so will push you outside the guardrails.

When you’re working out what is the best course of action for a risk, think about where those boundaries lie and what options you have to work within them. That can help you decide whether your course of action requires an escalation or whether the team can manage without input from other layers of governance.

The right approach for risk mitigation depends on what the risk is, the risk appetite of your project and organisation, and what resources you have available to you. However, the above ideas are a starting point. What other common approaches do you use to mitigate project risks? Let us know in the comments!