The Money Files

What makes a forecast change

Over-optimistic remaining effort

Late recognition of committed costs

Schedule slippage masking cost impact

Stabilising your forecasts

I have an electronic copy of the PMBOK® 7^th edition, so from time to time I open it up to check on something. Recently, I’ve been looking at different ways to forecast as we’ve got some work on that needs to be planned out.

There are 6 quantitative forecasting options called out in the Guide. These are as follows.

Estimate to complete (ETC)

This is top of the list and the one I personally use the most often. It works even if you are not in a full, compliant, earned value management environment. The risk here is that we assume past performance is indicative of future performance, and honestly, why wouldn’t you? Unless you know something is definitely going to change measurable performance, you would assume that work is going to continue at broadly the same rate. Just jot that down as an assumption so it’s transparent to everyone.

Estimate at completion (EAC)

For me, this goes hand in hand with ETC. It’s calculated by taking the actuals and adding the ETC, so again, while it comes under the umbrella of earned value acronyms, it’s completely accessible to those who don’t work in EV setting.

Variance at completion (VAC)

As forecasting tools go, this gives interesting data. It’s the measure that shows the amount of forecasted budget over or under at the end of the project, and it’s one most project sponsors will be interested in: “Will we have any cash left to do anything else when we’re finished?”

To-complete performance index (TCPI)

I have never had the opportunity (or reason) to use this forecasting metric. Perfect for those of you working with earned value day in, day out, it’s the cost performance required to meet whatever management target you’ve set for the work. It’s a ratio, so I think it is less meaningful to execs who are used to see tangible numbers of days or money.

Regression analysis

Now more and more tools are introducing AI features, it is possible to access regression analysis more easily. Perhaps you’ve got access to an AI-powered tool that will crunch these numbers for your automatically, removing the need for statistical knowledge.

The output allows you to predict performance going forward based on what has happened in the past, so it’s arguably more grounded than other guesstimates!

Throughput analysis

The final forecasting technique mentioned is throughput analysis. This looks at the number of items completed in a fixed time, so it’s useful for teams measuring features completed, velocity and story points. You can compare the output to those of other teams, although I’d be wary about comparing teams unless they work on very similar products or services. It wouldn’t be fair to judge a team on their throughput when dealing with very complex features against the performance of a team that has higher throughput but lower complexity.

However, the team can compare its performance against itself: that would be a worthwhile exercise. Ideally, you’d want to see that the learnings from retros have been fully incorporated and, more importantly, that the changes have actually made a difference.

Which of these are most used for your project forecasting? Let us know in the comments below!

Last month I looked at what you need to consider when setting up programme financial management, drawing on The Standard for Program Management, Fourth Edition (2017).

Today I wanted to write some more about financial planning at programme level (as we would spell it here in the UK), again, using The Standard as the foundations but sharing my experience as well.

The financial management plan for a programme

The Standard talks about having a financial management plan which is made up of:

• Funding schedules and milestones (financial timeline)
• Initial budget
• Contract payment and schedules
• Reporting activities and how reports will be managed
• Metrics for reporting and controlling finances

This all fits into the overall programme management plan, but could be a separate document.

The document is supposed to outline a lot of information about how money will be managed during the work. It should go into detail about:

• How risk reserves will be accessed and used
• How the programme will deal with financial uncertainty e.g. international exchange rate fluctuations, changes in interest rates, inflation, currency devaluation etc
• How the programme will deal with cash flow problems and if any are already identified
• What the local laws and compliance regulations are and how these will be met
• Incentive and penalty clauses in contracts.

In addition, as with all plans, you should include how the budget is going to be approved and what that authorisation process looks like.

In my experience, we did not have all this written out, although we did have a Finance team who were very much on the ball and probably had considered it without making it my job (thank you, wonderful Finance Manager!). In addition, the detailed technical budgets, which represented most of the cost (aside from staff) were put together by the technical architect, and were comprehensive. By the time it was my turn to look after the numbers, the paperwork seemed solid and it was very much a tracking exercise. I can’t take too much credit for the planning effort.

We were using international resources so the currency issue was very much relevant, and so was the risk reserve because we were doing something new to us with a high degree of uncertainty.

To be honest, I’m not sure we had a formal process for risk reserves either. Contingency had been added to the budget, but we did not allocate budget to risk management activities on a per risk basis. Given the scale of the investment, that was probably a mistake! I don’t recall any terrible dramas happening as a result of not having funding assigned in that way, even when the programme timeline was extended.

Contract payment schedules were documented in the contract instead. Our legal team bound up the contract and relevant schedules into little A5 booklets and I had one that sat on my desk and became my go to reference for all things to do with service level agreements, contract expectations and when I had to approve certain milestones to issue payments.

One time, I issued the payment notification and requested the funds be paid, but I had not warned Finance such a large request for cash would be coming so the actual payment was delayed a few days. That taught me I needed to start my process earlier so that Finance had notice that a large payment was due as part of our contract schedules.

Planning at a programme level feels harder because there is generally a bit more uncertainty, the timescales might be longer than your average project, more people are involved, and the numbers are higher. However, it’s never one person’s job. As you come together as a team, experts can provide their input to make sure the final result is something the governance team, finance team and programme management team can be confident with.

How do you track the performance of your project? Here are 5 ways that you can do it.

1. Fixed Formula

This is pretty easy. Assign a fixed percentage when the work starts. Then make it up to 100% by allocating the rest when the task finishes.

The Pareto principle is a good one to use if you don’t know how to split your task percentages. Assign 20% complete to the job when it starts, and the remaining 80% when your team member reports the work complete (because at that point it’s 100% complete).

It’s simple to work out but it’s not terribly accurate. It’s only good for small pieces of work and short tasks where it would be too difficult or not worth it to work out percent complete across a couple of days. It can also be used where the task is no longer than a week long. If you are updating your project plan once a week, and the task is no longer than a week long, the task is either started or finished so the 20/80 split (or 50/50 or whatever you think is appropriate) works out pretty well.

2. Weighted Milestones

When you’ve got plenty of milestones along the way, you can work out project performance by tracking how many you’ve hit.

In other words, you can pre-assign progress (percent complete) to certain milestones or parts of tasks. When you hit Milestone 1 you can say the project is 15% complete, at Milestone 2 it goes up to 20%, at Milestone 3 you’re 65% complete and so on. Until your final milestone at project completion where your project (or task) gets updated to be 100% complete.

This is also a way to split payments to vendors – many contracts have a schedule of payments linked to the achievement of key milestones. Your budget could be weighted in the same way as how you track performance.

3. Percentage Complete

We’ve talked about % complete already, but this version of it is just based on the project manager’s guess best professional judgement. They update the schedule or tracker weekly (or whenever it’s appropriate) with their take on project performance by assigning a percent complete.

This isn’t hugely accurate either – although it depends on the project manager. It takes experience to be able to pick a percentage out of the air and have it reflect reality. Generally, project management tools can help with this by playing back to you the % complete of your project schedule, so at least in that case you should have something underpinning the number you give.

4. Percentage Complete with Gates

This is similar to weighted milestones but instead of waiting to hit the ‘gate’ point, you can report any percentage complete up to the approved limit for that milestone.

For example, when you hit Milestone 1 you can say the project is 15% complete, as we saw above. With weighted milestones, until that point the project would be 0% complete. With gates, you can set a % complete every day if you like, working up to 15% at the point of hitting the gate (the target milestone date or achievement).

It’s like a blend of using your professional judgement but being constrained to not say you are too far ahead because you can only ever hit a certain percent complete through the nature of where you are on the project.

It sounds complicated to explain but this is my favourite approach for measuring project performance.

5. Level of Effort

Finally, you can track effort against the elapsed time. Alternatively, you can track against some other task or work package on the plan. For example, ‘Complete Testing Documentation’ might be linked to ‘Complete Testing’ and the two activities progress in parallel.

You’d track performance for ‘Complete Testing’ and then, as you know that testing documents are being updated as you go, apply the same % complete to ‘Complete Testing Documentation.’

Which one(s) of these do you use? And which do you avoid? Do you use these as standalone techniques or do they link to your Earned Value Management activities? Let us know in the comments below!

It’s the time of year when project managers (and everyone else) are looking to make resolutions. You know, the kind of promises you make to yourself in the dark days of winter and then have completely forgotten by Easter.

On the off chance that you’ll be making resolutions this year, here are some you could consider. They all have a money-related theme, so if you want to brush up your budgeting or polish your financial management skills in 2013, these could be great resolutions for you to adopt. So here we go: 5 promises for better money management over the next 12 months.

1. I will look at historical data for forecasts

When you are managing projects that are repetitive in nature and that the team has a lot of experience of, it’s very tempting to simply let them estimate the length of tasks and assume that they know what they are doing. Most of the time, they probably will. But it is worth validating their estimates against historical data from timesheets and previous project schedules. Use your online project management software to pull up reports of how long things took the last time you did them.

This could be at the level of an individual task, like completing a particular piece of coding, or a project phase, like testing. Or both. The purpose of checking is to make sure that your estimates really are sound and that the people who are estimating are not making the same mistakes about task duration on every project.

2. I will do my timesheets in a timely fashion

This is a personal resolution for you, although you could extend it to all your project team members. The risk of not doing your timesheets on time is that you forget exactly what it was that you were doing. As a result, you block out 8 hours per day for a task called ‘project management’ which doesn’t give you any breakdown of how you actually spent the time. Worse, you could be booking time to one project when in reality you got pulled off that project to spend half a day on some other project. These things happen in real life, to you and your team members.

By aiming to complete your timesheets at least weekly you’ll not have long enough to forget what you were working on!

3. I will understand Earned Value Analysis (or teach someone else how to do it)

If you don’t understand EVA, make 2013 the year when you get your books out and study how it works. If you do understand EVA, make a resolution to share your knowledge with someone else this year. Even if you don’t use EVA on your projects, it is a very useful skill to have.

4. I will do my expenses on time

Most project managers will incur expenses in the course of their job, such as travel to meetings. Not doing your expenses on time means that you are out of pocket. Many companies only pay expenses once a month in the monthly pay run, so don’t let your expense bill mount up – that’s effectively a loan to your company.

Get your personal paperwork in order by keeping receipts together, noting down your mileage after every trip and understanding the schedule for submitting expenses so that you don’t miss the deadlines.

If your expenses are being cross-charged to your project it is even more important to get your expenses in on time. If you don’t, your project budget will reflect that you have more ‘in the bank’ than you actually do.

5. I will review my budget quarterly

You do this already, don’t you? If not, make 2013 the year when you review your project budget forecasts regularly. If your project runs over two quarters you’ll probably be asked to do this by your finance team anyway, but even if you are not, it is still good practice to get out your spreadsheets and just check that you are still on track to stick within your budget tolerance limits.

Have you chosen any of these as your resolutions for 2013? If not, what are you having as your resolutions instead?

Elizabeth Harrin is Director of The Otobos Group, a project management communications consultancy. Find her on Google+ and Facebook.