The Money Files

I’m loving PMBOK7. It’s far more pragmatic and helpful than previous versions, although speaking to other project management professionals (and trainers) they are reporting that students feel like they need the process stuff too, so they can actually get the work done.

I think I’m lucky in that I’ve got my personal ways of working kind of figured out, and over the years have built the confidence to tailor what I do to fit the project, and also the amount of time I have to spend on it.

I’m working on a lot of capex initiatives at the moment, so estimating projects for proposals is always top of mind. I turned to PMBOK7 to see what it had to say about estimating.

The book says there are 4 different aspects of estimating, each affected by where we are in the project lifecycle.

Range

Range refers to how close you can get to what might be the final estimate figure. For example, in the early stages of the project lifecycle you probably don’t have a lot of detail about the tasks and therefore you might not be able to get close to some of your estimates.

Using ranges is useful because it helps present information when you still don’t have all the details. You can state a range like “between £80k and £120k”. As you get more information, you should be able to narrow the range, such as, “between £95k and £110k”.  Eventually, you might be able to pinpoint an exact price.

To be honest, the exact price is often where we start from in capex, procurement-led projects, as the supplier provides a quote early on.

Accuracy

Accuracy is how correct the estimate is; how close to being “true” it is. A supplier quote – provided you have given the correct scope – should be pretty accurate. An estimate from the IT team about how long it is going to take to connect the asset might not be very accurate at all if they’ve never worked with this technology before. If it’s something they do regularly, they can give you an accurate estimate.

Precision

Precision is about how precise (obviously) an estimate is, or needs to be. Delivery dates for kit are often not precise at the beginning of a project, but as the stock comes in and suppliers can be more precise about when it will be shipped, the date estimates become more precise.

Confidence

Confidence levels are useful to include in your estimates, and are especially useful for influencing culture. In my experience, they are helpful when you are working with experts who are reluctant to commit to timescales and dates. You can ask, “How confident are you that you can complete the work within a week?”

The more experience they have at doing that kind of work, the more confident they should be in their numbers. The more robust the estimating, the more confident they should be. Guesstimates have a low level of confidence.

Explicitly mentioning the confidence levels when communicating to senior stakeholders can make uncertainly more obvious to them. I’m sure we’ve all worked with stakeholders who, when you say, “some time during the month” expect it to be delivered on working day 1.

Not all projects will need all of these factors built into their estimates, and as your project progresses through the lifecycle, the way you create estimates will change. It’s worth bearing these factors into consideration so you can adjust and communicate about your estimates as you go.

Getting projects off the ground at the moment is hard: it seems to me that there is a lot more scrutiny on business cases because everything is more expensive. At least, in the UK, prices of everyday things are going up and that is hitting businesses as well as household budgets.

So what can you do? When you want to prove your project is worth the investment, your business case if your first line of defence. Let’s look at how to present your project in the best possible way so you can convince everyone that it’s worth progressing.

Show it aligns to strategy

We know that not all projects have to have strategic alignment: some are just tactical or must-do obligations. But if your project does align to strategy, you should find it easier to secure the commitment to progress.

Provide the evidence and show that the proposal fits with the current strategic aims. Show that it is complementary within the portfolio and (ideally) fills a needed gap. If there are organisational KPIs or targets that your project could/would support, make sure those are called out.

Show the change is required

Most projects are ultimately discretionary. If you want your project to secure funding, you’ll have to show that it’s necessary to do the change – or at least highly beneficial.

Evidence that you understand the business problem and that your project is the solution. Point out any current business risks or issues and explain how your project will address these. If you can talk here about the future goals for the organisation, the future business needs and link your project into those, that would be beneficial too.

Be realistic: talk about the constraints and assumptions you are making, and any risks and issues to the project known at this point.

Show how you get from here to there

Set SMART objectives – specific, measurable, achievable, relevant and timely – for the project and spell them out in the business case. Make it obvious that you can evaluate success and that there are clear goals.

Document the project management and governance approach you plan to take to deliver the work, to show that it’s achievable. Spell out any additional resources required and show that there is capacity to deliver – or that you can source and secure the resources needed and that these are included in the proposal. Be really clear about what’s included in scope.

List the outputs and provide some narrative about what the world will look like post-project. For example, talk about the new capabilities the organisation will have, and how these can be sustained over the longer term.

The business case needs to be honest, but it also needs to be a well-written story that sets out the problem, the case for change, and what that change would be. There are more elements to a good business case than simply linking it to strategy, but this should be the very foundation of your documentation. If the project isn’t a good idea, or one that helps the organisation move closer to where it wants to be, the best financial analysis section in the world won’t get it through the PMO.

Are you winding down for the end of year festivities? Whatever that looks like for you, here are 10 things to consider when heading into the holidays.

1. Thank your team

I’m sure you do this all the time anyway, but as a gentle reminder, this is a great time of year to be thanking people for the work they have done over the past 12 months.

You don’t have to spend a lot of money (or any money). A digital card, a message on your corporate internal social network, a thank you in person or on email: it all makes a difference.

2. Thank your suppliers

Suppliers have had a tough year, just like the rest of us. Rising costs and clients who have had to scale back their plans as a result of belt-tightening have made it a difficult economic climate for many, especially small businesses.

3. Organise a celebration

Whether it’s a Christmas jumper day, a lunch out to mark the end of another year and still being together as a team, or simply the option of meeting in person, try to find some time to celebrate what you have achieved this year.

Look back at the projects that the team delivered, or the successes that have happened on your journey in your current project. Find something that everyone can do, so your celebration is inclusive.

4. Remember that payment runs are early

Back to business: payment runs are early in December. Your Finance team might be processing everything a week or so before the normal cutoffs to account for people being out of the office or bank deadlines due to the holiday season.

Make sure you get any invoices or expense claims in on time so you don’t miss out.

5. Be prepared for the change freeze

Your IT department probably has a change freeze planned for the holiday period. This is a time when they won’t make changes to production systems, normally because they are running with a reduced staff due to people taking time off. It might also be because it’s a busy time of year for your business and they don’t want to do anything that would mess stuff up.

If your project needs IT changes, talk to them about the dates for the freeze and get your change requests to the CAB (Change Advisory Board) as soon as you can.

6. Do your accruals

If the end of the calendar year coincides with the end of your financial year, you might have to do accruals. This is where you financially account for items that have not yet been delivered but have been ordered, or have been delivered but haven’t yet been invoiced.

Talk to your finance team about what they need from you. In my old job, we used to get a form to complete from Finance that detailed all the info they needed about open purchase orders so they could close the books for the year.

7. Send feedback to line managers

If you have benefited from having subject matter experts on your team, take a moment to send some feedback to them and their line manager about their contribution to your project. That can be included in their performance appraisal.

8. Prep for your end of year review

On the topic of appraisals, if you have an end of year review coming up (ours are often in January), take half an hour or so to document what you have achieved this year so you can reference it in your meeting.

9. Be mindful of other people’s leave

Even if you aren’t taking much (or any) time away from the office, your colleagues may well be. Try to bear in mind their leave dates so you aren’t bothering them with emails during their break.

10. Set your out of office

It’s time to take a break from the office, so update your out of office message and let people know who to contact while you are away.

Now all that is done, you can rest up and enjoy the holidays! I hope you have something lovely planned to mark the end of another year.

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!