Project Management

The Money Files

by
A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts. Written by Elizabeth Harrin from RebelsGuideToPM.com.

About this Blog

RSS

Recent Posts

Professional development 2025: Key Skills

Managing fuzzy dates

How to set project objectives

Career development tips for 2025

Reflecting on project success: How to celebrate wins (big and small)

Categories

accounting, agile, ai, appraisals, Artificial Intelligence, audit, Backlog, Benchmarking, benefits, Benefits Management, Benefits Realization, books, budget, Business Case, business case, Career Development, Career Development, carnival, case study, Change Management, checklist, collaboration tools, Communication, communication, competition, complex projects, Conferences, config management, consultancy, contingency, contracts, corporate finance, Cost, cost, cost management, credit crunch, CRM, data, debate, Decision Making, delegating, digite, earned value, Education, Energy and Utilities, Estimating, events, FAQ, financial management, forecasting, future, GDPR, general, Goals, Governance, green, Human Resources PM, Innovation, insurance, interviews, it, IT Strategy, Knowledge Management, Leadership, Lessons Learned, measuring performance, Mentoring, merger, methods, metrics, multiple projects, negotiating, Networking, news, Olympics, organization, Organizational Culture, outsourcing, personal finance, Planning, pmi, PMO, portfolio management, Portfolios (PPM), presentations, process, procurement, productivity, Program Management, Programs (PMO), project closure, project data, project delivery, Project Success, project testing, prototyping, qualifications, Quality, quality, Quarterly Review, records, recruitment, reports, requirements, research, resilience, resources, Risk, risk, ROI, salaries, Scheduling, Scope, scope, small projects, social media, software, Stakeholder, stakeholders, success factors, supplier management, team, Teams, Time, timesheets, tips, training, transparency, trends, value management, vendors, video, virtual teams, workflow

Date

What’s your project’s bus factor?

There’s a resource risk that should be on your project risk register, regardless of the type of project you are doing. That’s your bus factor. In other words, what risks are you running if a key resource is hit by a bus.

Yes, it’s a bit morbid (use “won the lottery and quit without notice” if you want a discussion point with less dying) but it’s a crucial issue for projects.

The resource doesn’t literally have to be hit by a bus (and let’s hope that they are not). What we’re talking about it is the impact of them not being on the team for a length of time, often with hardly any notice. For example, going off sick, deciding to take another job and HR putting them on gardening leave, needing time to care for a relative or some other absence.

The trouble with project teams is that we don’t normally have a lot of spare resources lying around. People are subject matter experts and you get one of those skilled experts allocated to your team based on need. It’s unlikely that you have a pool of multiskilled people who can step in if someone else is off work for a length of time…sometimes that might be the case, but even if the skills are available, the person who has them might be fully allocated to another project or even – gasp! – doing their day job.

Building resilience into the team is important, but in my experience it’s not often as easy as it sounds. Yes, we cross-skill team members where it makes sense. Yes, I cover for other project managers when they are on holiday for a week. But some tasks need The Person With The Skills and you have to wait for them to come back.

So, now we understand the risk that the bus factor brings to projects, what can you do about it?

First, highlight it in the risk register if you haven’t already. This improves visibility and lets senior managers know it’s a risk you’re carrying.

Next, talk to the team. They can’t predict this kind of ‘bus’ absence but you can get caught out by other types of absence. I once worked on a project where the key functional owner told me that she was on holiday for a fortnight during the project call before she went away. She had tasks scheduled for her to be doing while she was off. Her line manager hadn’t let me know, and to be fair to her, I hadn’t asked her either.

From then on, we regularly asked project team members when their upcoming holidays were, because you can’t always rely on them or their managers to let you know. Especially if the holiday is booked after the project schedule has been put together.

Talking to the team serves another purpose: it can help you identify what you can proactively do to offset the bus risk. For example, workshadowing, setting up a delegate with an account so two people have access to crucial systems, sending two people on training courses instead of one and so on.

Sketchplanations highlights the challenge in the image below. It’s up to you to make sure you’ve put enough measures in place to make sure your project isn’t delayed by unforeseen lack of resource.

sketchplanations bus plan drawing

Posted on: June 17, 2024 09:00 AM | Permalink | Comments (4)

Closing out a Programme

Let’s say you have been through your programme and are ready to close it out. There is obviously quite a lot to do, and the finance elements will be part of that. Here’s what to consider when closing out the financial management of a programme, inspired by the Standard for Programme Management.

Benefits stewardship

The programme will have created benefits, some of which have probably been realised as the work progressed. Towards the end of the programme, you may need to estimate the ongoing costs for making sure those benefits continue to be realised. For example, maybe recruiting an additional person to manage some deliverables once the programme team is stood down. This should last for as long as the benefits are going to be tracked for, or as long as you think is appropriate.

Any ongoing costs that will be passed to the operational teams should be made clear and budgeted in their ongoing profit and loss accounts for the department.

Leftover funding

Will you have any money left at the end of your programme? Probably not – in my experience project and programme teams tend to spend everything allocated to them!

On the off-chance that you do have funds left – let’s say, in the case of closing the programme a little earlier than expected – you should be in a position to hand some funding back. Any contingency funds that have not been used can be returned to the corporate ‘pot’.

Reporting

You’ve been creating financial reports for the duration of the programme, and those will now stop as the programme is wound up. However, stakeholders may be relying on that information. If there is the expectation that some of the financial reporting is still required, perhaps in a slightly different or amended format, you should put in place options to make that happen.

For example, perhaps another department can pick up running the reports, or they can be automated.

Tip: Even if you are automating the reports, please make sure each report has an owner! When we migrated a load of reports from a legacy system into a new one we weren’t sure which reports were used and which were no longer required because there was no data ownership. We didn’t migrate a bunch of them, figuring that if they were missed someone would say! Nobody said anything, so it’s probably those were simply no longer required, even though the system produced them regularly.

Sustainment

Sustainment of a programme is the work required to make sure the outcomes are maintained going forward, once the programme structure itself is no longer there to support them. Beyond benefits, there might be some additional funding required to sustain the programme’s vision, achievements or outcomes. For example, perhaps you implemented new tools and now the business needs to have someone in post to maintain that software.

In my experience, people who enjoy the environment of delivery are not always the same people who enjoy the day job. You may find that programme resources are not interested in staying on in ‘day job’ roles to support the ongoing running of whatever needs to be sustained, so you could end up having to budget for hiring new roles.

Close out checklist

At the end of your programme, check to make sure you have the following aspects covered from a budget perspective:

  • Financial inputs to the programme closure report and any final financial reports or closure statements
  • Updates to the financial management plan if necessary
  • Updates to the lessons learned database or organisational knowledge repository
  • Any related documents that might be useful in the future
  • All invoices and supplier contracts wrapped up and closed
  • Programme budget and cost centre/cost codes shut down so no further work can be allocated to them.

What else would you consider when closing out a programme budget? Let me know in the comments!

Posted on: June 07, 2022 04:00 AM | Permalink | Comments (1)

What Goes Into a Technical Proposal

Writing Proposals by Edoardo Binda ZaneWhen you’re putting together a new project proposal, there are a number of things to consider. Edoardo Binda Zane has a whole book about proposal writing: Writing Proposals: A Handbook of What Makes Your Project Right for Funding. He says that there are three main elements:

  • The technical proposal, where you set out your solution or project objective
  • The administrative proposal, where you prove you are eligible for any funding
  • The budget.

Project proposals of this kind are quite different from in-company project business cases. These relate to projects where you are basically pitching another organisation to give you funding for your project. This happens in research, academia and sometimes other areas like business incubators for start ups.

Let’s say you want to put a funding proposal together for a business incubator. You know you are eligible and you’re gathering the paperwork to prove it. You can put your budget together in the format they want. But the technical proposal…. It’s hard to know exactly what goes in that, even if you know your own solution perfectly and have already costed it. This is about communicating the value and approach of your project so it gets chosen over someone else’s.

It helps if the funding-granting body has given you a template to complete. That certainly takes the guesswork out of it. If that doesn’t happen, you’ll be reliant on your own internal templates and they might not be geared up for this kind of application.

Binda Zane has some pointers for what to include. The headings below are what he suggests goes into your technical proposal along with an explanation of how I would interpret those if it was my project.

Introduction

Pop something in here to set the scene. Personally I would write the introduction last so I could make it contextually relevant to the rest of the document. If you don’t normally leave it to the end to write the intro, try it next time – it’s so much easier!

Current context and proposal structure

This should cover the context of the project and any background information that’s useful for the decision makers to have. It could also describe the research you’ve done (not in detail) or other sources from which you’ve drawn information to prepare this proposal.

It’s also a kind of executive summary that outlines what they can expect to read in the proposal and gives them the headlines in an easy to digest format.

Methodology

You’d cover off the project goals and objectives. This would be just like a standard business case.

Binda Zane suggests that you talk about the tools and techniques to be used. This can give the decision makers confidence that you do have some clue about how to manage a project. If you can say that you’re using industry standard best practices and following guidance from PMI (or whatever methodology/standard/processes are applicable to your business) then do.

I’d make sure that governance gets a significant mention here. If you were asking for my money I’d want to know that you had controls in place to spend it sensibly.

Of course, you shouldn’t say that you can follow standards if you actually can’t. That would be a breach of the PMI Code of Ethics and Professional Conduct. Other professional bodies have similar ethics standards.

You’d also want to include a section that outlines your detailed approach, the work packages and the descriptions of each task, at least to a sensible level that tells them what you are all about. If you think this section might go on a bit, move some of the task descriptions or detail to the end and put it in an appendix.

Organisation and Staffing

This section covers what they need to know about the people who will be involved with the project and how the work would be organised.

Binda Zane suggests management of quality control is covered in this section but I think there’s some flexibility to move it elsewhere if that makes better sense to you. I think I’d include this in my methodology section but there could be good reason for keeping it here.

Up until now you’ve only talked about what you will do, and how you will do it, but there hasn’t been any talk of how long that will take. Mention the timescales, major phasing and anything else relevant: key milestones, reporting dates and so on.

You also want to talk about the project team in this section. Describe the make up of the team, the organisation structure for the project and the roles and responsibilities of the key players.

Appendices

Binda Zane recommends two appendices. You can dump information in here that would take up too much space in the main proposal but is still useful for the audience to have. His suggestion is that you include the CVs/resumés of the project team and also a selection of project references. By that I would surmise that you could include references from past clients about similar projects, awards your team has won for their project work and anything else that makes you look like a solid and stable organisation.

That should give you a solid project proposal – for the technical element, at least. What else would you include in a technical proposal? I’m interested to hear your thoughts about what might be missed out of the list here!

Posted on: July 26, 2017 10:00 AM | Permalink | Comments (9)

How much documentation is enough?

Categories: budget, transparency, records

This month, the discussion topic here at Gantthead is stakeholders. Project stakeholders need documents – but how do you know how much documentation is enough? Unfortunately, the answer is always, “It depends.”

The amount of documentation stakeholders need to feel comfortable depends on:

  • The project scope
  • The project size
  • The project’s requirements and how complex they are
  • Any legal requirements
  • Any financial requirements
  • Your company’s documentation standards (although you could flout these if you have good reason)

According to Tom Kendrick in his book, 101 Project Management Problems and How to Solve Them, there are three types of project management document:

Definition documents: these define the project so include things like the project charter, requirements catalogues and organisation charts. Stakeholder management/engagement grids and analyses also fit in here. Definition documents might sound static, but they actually need updating regularly as things will always change.

Planning documents: these help the project team plan the work. They include the plan (of course), risk register, the project schedule, and any other project-specific sub-plans like a communications plan.

Status documents: these are the documents that stakeholders are generally most interested in. While they should be interested in the requirements and the risk log, you’ll find that the majority of stakeholders only really want to know how things are going and what they have to do next. Status documents include the things you would expect like regular reports, the issues log and follow up actions, the change log and other regular, non-standard documents that discuss status like meeting minutes.

Where does your project budget fit in all of this? Well, it’s partly a definition document: as part of the project initiation activity you would have defined the budget in the project business case or initiation document. But it’s also a status document: the real-time changes in the budget and tracking how much you are spending is very much related to project status.

You may find that it is easier to have two versions of the project budget: one definitive, signed off, formal version of the budget that never changes and acts as a reference point (your project budget baseline) and another as a living document that you update for quarterly forecasts and use to record actual spend. Personally I spend much more time on my living document than I do going back to the original, but I know that at the end of the project I will be expected to justify any changes to budget in the post-implementation review, so it’s important to still have those figures unchanged, with details about the project assumptions that helped shape them as no doubt by the end of the project I will have forgotten why the budget was set up that way.

Those two documents are ‘enough’ for my project budget. I can pull extracts or summary figures for my status reports, and that satisfies my stakeholders. How do you manage your project documentation, and do you find yourself doing just enough, or producing documents that no one ever looks at again?

Posted on: April 15, 2012 06:01 AM | Permalink | Comments (7)

Finance Filing: get your records in shape

The holidays are over and we’re into the final stretch before the milestone of year end.  This is a great time to get your project financial records in shape and set up systems to help you breeze through the end of year demands from your corporate finance people.   Today I’m looking at filing systems.

A flexible filing system will help you feel more organised and on top of the financial details.  Your files can then easily be archived at the end of the project or handed over to the operational team.

You need:

  • Somewhere to store paper documents:  ring binder with dividers per project or hanging folders.
  • Somewhere to lock away paper documents: filing cabinet, lockable desk drawer etc.
  • A place to store electronic documents, preferably on a networked drive so if your PC or laptop breaks your files are not lost.  This networked drive should not be available to everyone.  Some (if not all) of your financial records will be sensitive, and should not be shared.
  • A method of scanning in paper documents for electronic storage.


Keep these in paper format:

  • Signed copies of contracts including appendices and amendments
  • Any insurance policies you have set up as part of the project
  • Escrow agreements
  • Signed copies of change control notifications to contract terms


Keep these in electronic format:

  • All the above – scanned in and stored electronically with the rest of your project files
  • Service level agreements and other contract appendices – keep paper copies as well.  The electronic records will be good for easy reference
  • Purchase orders
  • Invoices
  • Quotes
  • Contact details for Accounts Receivable, Account Managers and other key financial contacts at your suppliers


Shred these:

  • Paper copies of purchase orders and invoices – your corporate finance team responsible for Accounts Payable will also store copies, so you don’t need these
  • Paper copies of quotes, once you have stored a copy electronically


Be especially careful with these:

  • Financial records relating to project team members.  

If your project team members work for you, you’ll probably already have visibility of their salaries, expenses and bonus arrangements.  Don’t lump all this in with your ‘project’ records.  If the project team works for someone else who has asked for your input to their performance review to award a bonus, or you are responsible for their expenses or timesheets, don’t store this with the project records either.  Create a separate, private, ‘Personnel’ filing system for this type of sensitive record.
 

Posted on: September 08, 2010 04:32 PM | Permalink | Comments (0)
ADVERTISEMENTS

While hunting in Africa, I shot an elephant in my pajamas. How an elephant got into my pajamas I'll never know.

- Groucho Marx

ADVERTISEMENT

Sponsors