James Lea, founder of Project Science, spoke at EVA 26 earlier this year. He talked about the psychology of estimating. “People,” he said, “are just as important as the techniques and data.”
He went on: “Plans and estimates are built by and used by people. Psychology matters.”
The talk was very interesting, and here’s what I took from it.
He started by asking us our experiences of estimating and the emotional responses we had at the time. Think about your own experience of estimating. Did you feel:
That’s all (unfortunately) normal, and we all nodded along as he talked.
Challenge how will estimates be used
James talked about how we should challenge how estimates should be used. “Uncertainty drives variable reactions in our teams,” he said. “It drives emotions and responses.” If you are open about how estimates are going to be used and how they should be used, that can help people feel more comfortable with the process.
Make estimating positive
How can we enable our teams to experience planning and estimating as a positive, creative experience? Instead of the stressful, “I suppose I can give you a number,” experience that it is mostly?
It’s hard for an organisation to accept that it doesn’t know the answer, and that can sometimes lead to a poor experience of the estimating process for the people involved.
Here are some ways he suggested we could turn the experience into a positive one:
Creating a route to predict the future
James talked about asking the question about whether we have a route to predict whether the estimate is a robust one or not. We need to understand what is in and out of our control. Where things are out of our control, accept that and track it.
Estimates are only a guess without a map of how you got there and a set of viable routes.
We often hear that people can’t estimate where there is no historical data. Well, data science should make it easier now to estimate from past performance and the vast tracts of data we store about projects. If leaders can give teams the data, in a way that helps with estimating, that should make our estimates better.
Building defensible plans
James talked about showing your workings and documenting the bases of estimates. Steve Wake, the conference chair, shared his thoughts too, namely that the audit office regularly says people don’t know the basis of estimate and therefore the best ‘proof’ that your estimates are good is that you can justify them.
He talked about bounding your plans carefully, describing the world around the estimate as well as the estimate itself to provide rigour.
He suggested we quantify and compare with data science, applying risk appetite to the delivery methodology to round out what we know.
That, and the other points discussed, are ways to shape the emotional response and create a safe space for people to estimate their work.
What do you think? Let me know in the comments below.
At the EVA conference in London in March, I had the pleasure of listening to Gary Hill, Co-chair of PsACE, the Public Sector Advisory Community for Estimating. He was talking about the importance of estimating and how the community helps shape the professional estimating done on public sector projects in the UK.
The purpose of the group is to simplify, standardise, systemise and professional project estimating process and capability across the public sector. He shared their vision, which is to bring together experts across government and client organisations to promote leading practice in estimating, underpinned by an ethos of trust and collaboration. I like how he talked about leading practice instead of ‘best practice’ because as we all know, there isn’t one definitive best practice for pretty much anything in project management.
He talked about how the community started in April 2019 when someone reached out to him and asked for help with something. “It started over coffee and turned into a beer,” he joked. The community sets out to address the problem that many project managers have in all aspects of our work: where do you go for advice, how do you know if that advice is any good and who says it’s good anyway?
To find out where good practice was in the public sector the community carried out a benchmark of 7 government departments where they measured good practice. Surprise, surprise, no department was good at everything.
Today, the community is sponsored by IPA, the Infrastructure and Projects Authority, which Gary said gives the community’s work more weight and more chance of making things stick. They really started to gain traction when they were mentioned in a government select community discussion, and membership started to grow.
It’s a volunteer-led community and Gary shared the common problem that many volunteer-led communities have: everyone wants to get involved because it’s a good idea, but everyone has a day job to do so it’s hard to get people to take on jobs.
Next up on the agenda for PsACE is to write to each permanent secretary in the UK government and ask them to support the community’s work, so that’s a large piece of stakeholder engagement to do.
In terms of what they actually do, Gary explained that PsACE was involved in providing input to the IPA estimating guide, and was represented on the committee preparing British Standard 202002 for Project Controls.
There are current workstreams covering:
Last month we looked at what goes into a programme financial management plan. One of the components of that document is, of course, the initial budget. You can’t track what you haven’t baselined, so there is an effort involved in making sure that the programme budget is put together in a robust way.
Creating a programme budget that is appropriate, timely, relevant, accurate, detailed enough to get through the scrutiny of the CFO, defendable, transparent and more is a huge, time-consuming task.
So where do you start?
Creating the programme budget
The initial programme budget is put together in the same way that a project budget would be: you bring together all the financial information you have from the business case, estimates, quotes, contractual arrangements and more to plan out what money is available and when it will be spent.
With a programme, you might also need to work out where the funding is coming from and on what schedule. For example, if it’s a grant-based programme of work, perhaps funding is issued in tranches, or made available on the completion or publication of particular milestones. If it’s a multi-year programme, perhaps funding is only available for this financial cycle and the expectation is that more funding will be available from next year’s pot.
Agree financial metrics
Next, work out how you are going to track and monitor the budget and what metrics will be used for benefits tracking. Again, this is no different from project budgets, although the figures might be larger and you may also have opex costs to consider – many projects are able to capitalise their costs so as a project manager I rarely had to worry about opex tracking.
The financial indicators are important because these feed into the health of the programme and will be reported regularly. But on a programme that spans many years and perhaps has difficult-to-quantify benefits, how will you check that work is proceeding as it should? Earned value management is one way, but if your company isn’t set up for that you’ll need an alternative.
The metrics you choose for indicating the financial health of the programme and also the benefits realisation measures will very much depend on what the programme is delivering. Sellafield, which is a multi-year nuclear decommissioning initiative, has a 20-year corporate plan. However, they have set out very clear milestones for each project as part of the transformation timeline.
A digital transformation programme spread over 2 years would have very different financial constraints and would be tracked with different metrics.
You may find that validating the metrics as you go is a suitable approach, if all the stakeholders buy into that. It’s important, however, to get the metrics as ‘right’ as you can because future decisions will depend on them. As you report progress, produce updates or even make decisions to move into different stages, you’ll be presenting the financial numbers using the measures for performance tracking that were agreed when the programme began. So it’s worth spending some time making sure they are the right ones and that people understand them.
Part of the budget planning is also being aware of the financial risk. In Sellafield’s case, for example, the timescale spans 4 government spending reviews which may impact the funding available to the team.
There will surely be budget-related risks that should be added to your programme risk log. They are likely to include similar risks that you’d see at project level, but with a programme focus, such as:
There will also be risks that are more programme-focused, specific to your particular programme.
The more risk analysis you do, the easier it will be to calculate an appropriate risk budget. Be careful not to count the risk budget twice, once at project level and then again at programme level, if it’s for an escalated risk.
All this goes into the mix for working out contingency appropriate for the programme, and at what level you wish it to be attributed to the work. At project level? At the overall programme level? Some mix of several methods for assigning contingency?
Ultimately you end up with a programme budget that will no doubt change and flex as time goes on, but should give you a reasonable baseline from which to start.
How do you know when you’re ready?
The outputs of getting ready to track your programme budget will tell you if you’re ready to go ahead. You should have the following:
When all those things are in place, I’d say you were in a pretty good position for the programme’s financial management. What would you say?
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:
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:
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.
Project costs feels like a topic I’ve revisited many times over the course of writing this blog (can you believe I started it in May 2010?) and today I want to use my monthly video to go into the differences between direct and indirect costs and fixed and variable costs. They are terms new project managers might get confused about and we hear them thrown around in discussions. What do they mean for projects?
In this video I share a few examples of each so you can get a feel for how these might play out for your work. If you want a text-based post to refer back to, then this article on 5 types of project cost also includes some information on the topic.
Do you have different definitions or examples to share? Leave a comment under the video as this community is better for all the different voices in it!