The Money Files

Thinking about doing some project management training this year? Here are some things to consider to help you choose the right vendor for you.

You know I’m interested in the financial aspects of project management – I’m even thinking of teaching a workshop on project budgeting and accounting later this year. I feel like I’ve got quite a good understanding of the topic, but I’m constantly learning.

Having only done a very small amount of work in a team I would say is using agile practices, I am by no means an expert in the practical ways of making agile approaches work on project teams. However, there is a lot of guidance out there for people like me who want to learn more.

The Agile Practice Guide, in particular, has some interesting information about how to apply information from the PMBOK® Guide Knowledge Areas to agile work processes. From a financial perspective, here’s my interpretation of how this would work.

Project Cost Management in Agile Environments

Typically, on predictive projects you would do a lot of costing and estimating in advance. For projects with a high degree of uncertainty, or those where you don’t have a fully-fleshed out scope (hello, agile projects), then obviously you don’t have the data to do this level of cost analysis.

Instead, the recommendation is to use “lightweight estimation methods” (although no detail is given as to what these might be) to come up with fast, high level cost forecasts for resource costs. I can see this working when you are forecasting the general length of a particular engagement – even if you simply plan out the resource costs for the next financial period as a basic benchmark.

Detailed costs for things that aren’t people costs do still need to be done. You can’t run a successful business if you aren’t aware of what project work is costing you. It is OK, however, to do those detailed analyses on a more just-in-time and rolling basis.

To be honest, on some of the long programmes I’ve been involved with we’ve taken the same approach. The business case costs might have been fixed from the start, but frankly they were only ever our best estimate at the time. I then worked out detailed forecasts for the actual year we were in, so the Finance team could manage cash flow and we could accurately account for the capital outlay in the current financial year.

Where your budget is fixed, but you still need to be agile in other respects, then your choice is simply to flex scope and schedule to stay within the cost constraints.

Project Procurement Management in Agile Environments

Procurement management is another area where we incur costs, and as project managers, we need to be aware of how to manage that – in all environments.

Typically, procurements I have been involved with have had a protracted contract negotiation at the beginning to come up with a Master Services Agreement, and then you define the current engagement with a Statement of Work. As we needed suppliers to do extra things, we created new SoWs detailing that engagement. This is also how change control worked: the change control process generated either a credit note (when something was being changed and the end result was the development cost less) or a purchase order and an addendum to the current SoW.

It turns out that, according to the Agile Practice Guide, this is a pretty agile way of working.

There probably are projects where it is prudent and necessary to sign a massive contract upfront (ERP deployments spring to mind, from experience!) but generally, staying small with the engagement and working in a flexible way will suit both parties on the majority of projects.

Either way, something that is the same regardless of the project management approach you are taking is the need to document contractual arrangements and file them somewhere you can easily find them again. I have had a few moments in my career where I have sheepishly rung a vendor and asked for a copy of the executed contracts because – whisper it – it wasn’t possible to find our version of the same document.

Don’t make that mistake! Be agile. Be tidy!

Pin for later reading:

I thought it was time to look at some more financial concepts. Last time I looked at depreciation, and today it’s the turn of Present Value and Future Value.

I write them with capitals because they also stand as abbreviations: PV and FV.

The basic idea behind them both is that they talk about how much an amount of money is worth at any given time. From a project management perspective (and in life in general), it’s better to receive the money now than get exactly the same amount of money in the future. Because of inflation and cost of living rises, £10 today doesn’t buy you what it did 10 years ago. And when I think of what my parents paid for their house…!

If someone offers you £10 today or £10 next year, you’d take it today. And that’s what underpins the concepts of PV and FV.

Understanding Present Value

Present Value is a way of ‘levelling out’ how much money is worth, so you can compare its earning/spending power today and in the future. This lets your calculations account for inflation (or deflation). You can use the calculation to compare cash flow across the lifespan of a project or the benefit cycle, and you’ll be comparing on a more even basis. And by using a standard formula, everyone can clearly see how the information has been reached.

(Note: PV is not the same as Net Present Value, which in my experience is far more likely to be found on a business case. Net Present Value is useful for working out whether a project is worth doing, so it’s commonly used as a metric for project selection. There’s a worked example I found useful for calculating value in projects here.)

Present Value tells you how much the money of the future is worth today.

Understanding Future Value

Future Value tells you how much the money of today is worth in the future. I found this a lot easier to understand than Present Value – it’s pretty easy to understand that with interest and/or inflation, you need more money in the future to buy the same things. Anyone who has seen the cost of newspapers rise will get that basic idea.

For those of you who are interested in what this means for your exam prep, pop your figures into this formula:

PV = FV / (1+r)ⁿ

In real life you aren’t going to be calculating this by hand. Your Finance team will do it for you, or you’ll have some kind of project assessment spreadsheet with the formulae built in. The benefit of understanding the formula in your day job is to be able to have informed and intelligent conversations with your project sponsor and colleagues about project cost, and to be able to input into the debate about whether the project is worth doing or not.

A note on NPV

The other thing to know is how all this relates to NPV. NPV, as I noted above, is more likely to be the measure your organisation uses to determine whether to move forward with a project.

Here’s what you need to know, at a high level:

• NPV > 0 — the project is going to be profitable
• NPV = 0 — the project will break even
• NPV < 0 — the project will not be profitable.

You want your project to have a high NPV and you should discourage your sponsor from trying to pursue projects where the NPV is less than zero unless there is a really, really strong business reason to lose money on an initiative!

Pin for later reading:

There has been a lot of talk in recent time about the point of aligning projects to strategy to ensure that value is delivered – and that value is the important thing, not outputs. Well, this is hardly rocket science. Projects are the way to deliver strategy. You can have a lovely strategy, but if it stays as a PowerPoint deck, it’s useless. You need to take action on strategy items to make them happen, and that’s where we come in as project managers.

But unfortunately, it seems to me, as I hear from many of the project managers that I mentor and work with, that they are still having conversations with project sponsors, and managers (not so much PMO professionals, who get this stuff) about making sure everything lines up.

In this video I talk about aligning strategy to value. I share 4 easy steps you can take at any level in the company to make sure your project adds a ton of value to the organisation by focusing on things that are really important. Hopefully it will help you have those conversations in your organisation, if you need to.

Pin for later reading:

On this blog I’ve looked at different Knowledge Areas and how they apply to us as project managers, and also taken a budgeting and cost focus on a lot of articles. But what if you are managing an agile project? How do some of the financially-leaning Knowledge Areas work when you are working in agile ways?

Here’s how. Today, I’m looking at how the schedule management Knowledge Area applies to the agile work process.

Project Schedule Management

When you work in an adaptive environment, your project schedules aren’t going to look like big old Gantt charts. You’ve got short cycles to do the work in. With a lot of the people I mentor, we’re talking two week sprints.

The short cycles allow you to do work, review the work and then tweak the results as necessary, including any testing that needs to be done. Ideally, you don’t want all your features dropping on the testing team on the last day of the sprint because that’s not kind!

One team I worked with had this problem a lot so actually set up testing sprints running ‘behind’ the development sprints, just so there was enough time to test everything. Whatever works.

Scheduling is a cost-driven activity because people cost money, and you need people resources to do the work. That’s why it’s important to understand what scheduling options are available to you and how best to get the most out of the time and people that you have.

This could look like pull-based scheduling – which is what I am doing on one Agile team at the moment. There are a lot of tasks. I have the luxury of being able to decide on my next task. They all have to get done, and I can choose. Within reason!

Or it could look like on-demand scheduling. I have used a scheduling approach on a predictive project where we only planned the next three months in detail and let the rest of it unfold as we got closer to the date. It was the only way to stay on top of the work, on that monster project. It wasn’t a project being run with agile principles, but our just-in-time approach to scheduling made our lives easier. As I said, whatever works.

Scaling scheduling

If you work in a big company, there are probably predictive and adaptive methods in use. All of the projects need to fit into some kind of PMO roadmap that allows the business to strategically plan the change effort.

The Agile Practice Guide talks about using predictive, adaptive and hybrid approaches to combine practices to get the best approach for the project or programme being delivered. Consider what scaling you would need to do to your current methods based on:

• How big the team is
• Where the team is based
• What kind of regulatory environment you work in and the compliance requirements
• Organisational complexity
• Technical complexity of the solution.

However, good schedule management skills are universal, and being able to break down the work, estimate, ensure work is given to the right task owners, track progress against tasks being completed – all those are fundamental skills. The tools and techniques you use to do them might be different depending on whether you are taking predictive or adaptive approaches.

Your PMO should be able to support all kinds of ways of working, and if they can’t yet, they are probably thinking about how to make sure they can in the future, because more and more PMOs are needing to adapt the way they work to be able to better support agile project teams.

From a financial perspective, you should be able to track the resource cost (and any other costs directly related to scheduling, if there are any) via timesheets or the equivalent way of reporting actual hours worked. This is especially useful if your team is not 100% dedicated to your project. If they are only doing your project, and you’re running on a timeboxed approach, you should easily be able to work out how many hours it took you to get the output from this timebox.

Schedule Management as a Knowledge Area is applicable to project managers working in agile environments. As with all tailoring, you take what you need and adapt to the project, team and processes you are using.

Pin for later reading: