Dates Every Budget Holder Should Know
When you’re managing a project budget, there are some key dates you should know! These general accounting dates can be laid over your project schedule so you don’t miss any major financial milestones.
1. Year End
Financial year end could be any time in the calendar year. I’ve worked with businesses that align their financial year end to the tax year, to the end of the calendar year (i.e. December) or to the date of incorporation (in the case of my business, that’s May).
It doesn’t matter when year end falls for you, as long as you know when it is!
Year end is important because it marks the close of one financial period and the start of another. You may have to get involved with accrual calculations and budget carry overs. If you miss the deadlines, you might not get your project budget in the next financial year!
2. Project Phase Dates
Some businesses work by releasing project funds according to the stage of the project. In other words, you don’t get the full amount of the project budget on Day 1. As the project moves through the lifecycle, funding is released in chunks.
Normally the dates align to stage gates or project reviews, where the steering group will approve the project to move to the next phase. That then triggers the release of the funding required to do the next phase of work. Be ready! Especially if you need to change your original forecasted budget request based on what you have learned during the current phase.
Reporting dates relate to so many different areas of your project. They are important for project budgeting because you will need to prepare a short budget summary to go into the report. As you approach the reporting deadline day, make sure your financials are up to date so you can drop the most recent figures into your report template.
4. Tax Dates
Tax rates don’t change often, but I did once work on a project where the rate of VAT changed halfway through the work we were doing. It made budgeting very confusing!
If you know of upcoming changes to tax (typically linked to government announcements and budget cycles), then watch out for whatever impact that might have on your project and make sure you note the date the changes come in!
5. Project Closure
Yes, you surely know the project closure date – the target milestone you are working to for everything to be done!
It’s important for budgeting purposes because you may have to calculate budget at completion, or staff run rates, all of which need you to know when the final expenses on the project will be accounted for.
What other dates should project budget holders know about? Let us know in the comments below!
Pin for later reading:
4 Tools for Cost Control
Categories: cost management
Staying on top of your project expenses is really important if you want to bring the project in on budget. However, how you actually do that changes as you go through the project. You’ll want to take a different approach to cost control depending on where you are in the project and how you need to respond to the project budget situation.
The graphic below shows four tools for cost control at each point in the project lifecycle. You can pick and choose from these to select a way to manage expenses on your project, wherever you are in the lifecycle.
For more on this idea, check out this article.
It’s time to look at another project management Knowledge Area from the PMBOK Guide®-- Sixth Edition. This time, we’re diving into Project Scope Management. I’m going to be looking in detail at the major changes between the Fifth Edition and the current version. It feels like the Fifth Edition came out of circulation a while ago, but I know (anecdotally) that some people are still yet to update their internal processes to align to the Sixth Edition.
In practice, I don’t think that matters much. The changes aren’t radical – and while it’s good for new people being certified to work in an environment where the language and expectations align to what they studied as part of their PMP® prep, no one is going to find it difficult to work in a v5 environment.
So, onwards to this Knowledge Area. Let’s dive in!
Plan Scope Management Process
This is the first process in the Knowledge Area, and it makes sure you are setting yourself up for success. As with many Knowledge Areas, we start by planning out what we are going to do in this domain before getting on with the work.
The inputs haven’t changed from the Fifth Edition. They are still:
The objective of this process is to consider how you are going to get to an understanding of what the project scope is, so you need all of those things.
Tools & Techniques
There isn’t much change here either. Expert judgment and meetings remain as they were before, and there is the addition of data analysis.
You might recall that data analysis was added in as a tool and technique to schedule management too.
Data analysis is a lovely catch all for the kinds of things you might be looking at during your planning. For example, you will probably do some alternatives evaluation to decide which requirements and specific functionality or solutions you want to move forward with.
Nothing has changed here either.
At the end of working through this process, you’ll have the scope management plan and the requirements management plan.
I’d say that if you have a repeatable process in place with solid templates and expectations for managing scope, you should be able to complete the work required here quite quickly. You might not need to write a detailed document for requirements management and scope management, if you can include a paragraph in your main project management plan. There’s nothing in the PMBOK Guide®-- Sixth Edition that specifies you have to have separate documents, so go light on paperwork where you can!
Next time I’ll be looking at the second process in this Knowledge Area: Collect Requirements.
Insurance is something we think about naturally for our homes, cars and even our lives. But should you be considering it on your project too?
Insurance is a risk response strategy to help you mitigate the impact of what might go wrong on your project. Typically, we do talk about positive and negative risk, and while I’m sure you could probably find a firm to insure you against positive risk, you are far more likely to consider insurance as a support strategy for negative risk.
What could you insure?
Through a broker, you can pretty much insure against anything. However, organising specialist, one-off insurance for a very specific, unique, circumstance is potentially a lot of work (and expense) so you would only want to do that if your project was large enough to support that effort.
However, you can more easily insure a range of other, more ‘regular’ things on your project. For example, event cancellation due to poor weather or low attendance rates. In this situation, you’d get a pay out from the insurance if you had to cancel the cycle race you’d organised (for example). This would help you offset the costs you had incurred organising the cycle race, like catering vans, first aid teams, water for the cyclists, security and so on – all costs you’d still have to pay because you’ve booked them and probably can’t cancel them with such short notice.
Another type of insurance to consider for your project team is travel insurance. If your team is travelling a lot for work, it would be worth checking that your company offers insurance for employees travelling for business.
This would cover them if they lost their laptop or other work items while away for business. It could also help cover the costs of travel arrangements if their flights were cancelled, or they were unable to travel.
Other insurance for staff
If you are a sole proprietor or a small business owner – and many project managers do work independently as contractors or in small consulting firms – then it’s also worth considering other types of insurance that cover you and your team as individuals.
For example, in the UK you can get director’s insurance, that covers the business in the case that the director is unable to carry out their duties, say, due to illness.
You can also organise health insurance for the team. Depending on where you are in the world, healthcare costs can be really expensive. Insurance will help offset those costs, and help an employee get back on their feet (and back to work) more quickly.
I should add that I am not a financial advisor, and the points above are given simply to give you ideas of how to consider the part insurance could play in your business and on your project. If you don’t have anything set up yet for your team, it’s worth asking the question of your Finance team or Director. Get some proper advice from a financial advisor.
Think about whether insurance is a viable option for your risk mitigation strategies and if so, you may be grateful one day for having it set up!
Pin for later reading:
This is the end of my deep dive into the PMBOK Guide®-- Sixth Edition, and what it covers about Project Schedule Management. I’ve looked in detail at the major changes between the Fifth Edition and the current version.
One of the biggest changes in the Sixth Edition is the inclusion of information on trends and emerging practices, tailoring and Agile. This is long overdue and it’s helpful to have some specific guidance around how we can adapt the sometimes dizzying amount of information in the PMBOK® Guide to our own organisations.
To recap, here is the rest of the Project Schedule Management deep dive series:
OK? Let’s take a look at what you need to know about adapting this process for your environment.
Trends and Emerging Practices
Scheduling techniques have pretty much stayed the same for many years, but there are some new thought processes at work. We have to be able to manage in a competitive environment where everything seems to be needed much more quickly. There’s a business advantage to being able to compress schedules and deliver things in a shorter timeframe, so the emerging practices covered in the PMBOK® Guide relate to those.
First we have iterative scheduling with a backlog. This is a common way of managing work in an Agile environment and supports rolling wave planning. In other words, you have a big bucket of requirements (user stories) that are prioritised as you come to the end of a time box, for delivery in the next time box. This works really well when you can or need to be flexible about what features get released when.
The major benefit is that the customer gets to see real progress on an iterative basis. This is great for building loyalty, delivering benefits more quickly and ensuring user adoption over time.
However, when there are lots of dependencies between tasks or requirements, it can become difficult to manage.
On-demand scheduling is based on the theory of constraints. It limits the work in progress for a team so that you can balance demand against what the team is capable of doing. As someone who is not a fan of multitasking (although I do it every day), limiting WIP is a great idea.
Kanban is where you will see this approach in use most commonly. In practice it works because instead of building a schedule based on requirements, you plan around the team’s availability and they take work from the queue to work on it immediately.
This is a good approach in environments where you have people doing a mixture of BAU and project work, and their project work does not have hard deadlines. I have no project experience of on-demand scheduling, aside from using something similar for my own To Do lists, so share your experiences in the comments below – I’d love to hear more.
The PMBOK® Guide talks about the need to tailor the approach to scheduling because every project is different. For your project, think about:
The life cycle: what life cycle are you using for your project and is it the best approach for getting to a detailed schedule?
Resource availability: You might have to switch up how you manage the schedule because of difficulties securing the resources you need.
The project itself: Big, complex projects need a different approach to scheduling to a small, easy project. There might be constraints within the project environment that lead you down one scheduling path compared to another, for example being required to use earned value as a stipulation of a particular contract, or using a particular scheduling software tool because that is what the client uses. That leads us to:
Tech support: What tools are available to you? If you don’t have access to modelling tools, for example, it’s not appropriate to build your schedule on the basis that you can use them. If you don’t have virtual Kanban boards and yet your team is virtual, then perhaps a scheduling approach that relies on specific software isn’t the best way to go.
Considerations for Agile
Adaptive project methods are those that use short delivery cycles. You do the work, review the outputs and make changes as necessary before the next delivery cycle kicks off. We’re seeing more and more projects use agile approaches like this because they work.
However, in my experience, and that of the many project managers I mentor, a lot of companies have project teams doing agile and project teams who don’t use agile. Sometimes we use Agile and non-Agile techniques on the same project (for different aspects of the same project). There’s a recognition now that this is OK. If it works and you get results, then it’s OK.
The PMBOK® Guide talks about hybrid approaches and being able to combine scheduling techniques from different approaches to get where you need to get. As a project manager, you have to make or support decisions around the tools and approaches you are going to use, and it helps to have some experience of these. If you find yourself suddenly managing an Agile project with no prior experience, you’ll be fine, but get familiar with the approaches as quickly as you can!
Pin for later reading: