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 GirlsGuideToPM.com.

About this Blog

RSS

Recent Posts

The Planning Performance Domain & Cost Planning

Mergers and acquisitions: The basics

5 Reasons why your project needs a business case

How to Prepare for a Project Manager Job Interview

4 Ways to Mitigate Risk

The Psychology of Estimating

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:

  • Under pressure?
  • Worried about how the numbers would be used?
  • Unsupported by colleagues
  • Unsure what the estimate was for?

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:

  • Develop the models
  • Turn the work of an individual into the work of a team with reviews
  • Use the past as a guide to future performance
  • Frame everything as a change
  • Refine the estimates.

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.

Posted on: June 21, 2022 04:00 AM | Permalink | Comments (4)

3 Ways To Be More Strategic As a Project Manager

Strategic thinking is one of those skills that gets tossed around as something project managers should have. But how can you be more strategic in a practical way? I’ve been thinking a lot about this recently, and here are 3 things I think you can do as a project manager or leader of a project delivery function to try to bring more of the ‘strategic’ into the way you work.

1. Get involved with business cases and proposals

First, lobby to get involved with business cases and proposals. The more delivery expertise we have involved in the initial stages of a project, the more likely it is that the project will be able to actually hit its goals.

Have you ever been involved with a project where you’ve been handed something to do and the sales people have made promises that you can’t deliver on? Then you’ll know what I mean!

When project people are involved in business cases, in my experience you’re more likely to end up with a timescale that’s achievable and a resource plan that reflects the real amount of resources likely to be consumed by the work.

It’s even better if you can lobby for a seat at the table when the 3-year plans are being drawn up, so your top level project people, like the Head of PMO, get involved in creating the strategy in the first place. That provides a real insight into what initiatives are coming and how the delivery teams can help.

2. Use the project assurance function as a check mechanism

Project assurance is a way of checking that what you think you can do is actually achievable. It’s their job to pick apart your plans and proposals and apply a sense of real-world pragmatism. They can also help identify whether there are any resource gaps, strategic holes or other issues that you haven’t seen.

After all, as a project manager I’m sometimes so close to the information that I can’t see the bigger picture enough to realise that this project will clash with something that someone else is working on – but project assurance has the bigger picture and can point that out.

If you don’t have a project assurance function, ask a colleague for their opinion and talk them through the plans, asking them to basically pull them apart. Ideally, to be able to add some strategic oversight to your plans, this should happen around the time of the business case or PID. By the time you’ve got to creating a schedule you’ll be looking for a different kind of peer review.

3. Share what you know – but only what you know

My third tip is something I learned from Tony Meggs, Chief Executive of the Infrastructure and Projects Authority in quite an old article now that he wrote for Project magazine, but it has stuck with me. He said: Only announce what you know.

We know this in theory, so it’s not news to you, I’m sure. However, many project managers are ‘encouraged’ to share dates before we are ready, or pushed into committing to dates publicly before we have all the information to support the fact we can deliver to them.

So, if you want to be a strategic operator, only share what you know to be achievable. That goes for delivery methodologies as well. Meggs talked in the article about not committing to anything unless you know it to be true, including how the work would be delivered. If you are going to partner with someone and there’s a robust contract in place, by all means announce it. But don’t announce your intentions before they are fixed in stone because if it doesn’t happen you’re then having to walk back on the messaging and that can be damaging.

We can do this as project managers on a small scale, by giving our teams the space to come up with the best methods and timescales before we announce them to sponsors, but also on a strategic level, by ensuring there is a communications plan in place that supports the bigger picture messaging for the project, programme or even the portfolio.

Do you do any of these already? How are they working out for you? Let us know in the comments!

Posted on: May 17, 2022 04:00 AM | Permalink | Comments (4)

The role of the CCB

Do you have a formal Change Control Board (CCB)? If not, this is the perfect time of year to be thinking about levelling up your processes and putting new ways of working in place to formalise the way change management is done across projects, programmes and the portfolio.

A Change Control Board is simply a group of experts that represent different organisational departments and who oversee both the process of change management and the different changes being put forward.

At a project level, your CCB is a group of people who know the project well and who can assess project-related changes, but at some point if your project is making changes to the live environment, like most IT and business change projects do, the change will need to be submitted to the wider, department or organisational CCB.

The role of the CCB is to:

  • Assess the change
  • Approve the change – in my experience, if the project team and project sponsor has already approved the change, there are few reasons why the CCB would then block a change
  • Schedule the change
  • Keep records about changes.

How it works

In our CCB, the functional lead or the project manager had to present the change. We had to talk about what it was, why it was useful and what it solved, and then make the case for whether it was a priority fix or not. If the change was considered a priority, it could go in the same day (mostly). If it wasn’t, it could be packaged up with a bunch of other small changes and go in the next release.

That made it easier to communicate changes to the end users.

Discussing the change

First, the change should be analyzed and discussed to see whether it has impacts beyond what the project team can comment on. The Change Control Board is convened to do that. I think the CCB is a really useful group and we relied on it in my last job. Our CCB looked at operational and project changes so the team could see the impact of ‘normal’ changes as well as the project-related ones.

I think it’s important that the CCB is made up of a cross-organisation group. It’s too common for changes (especially IT changes) to go in and for there not be a full understanding of the business impact somewhere else down the line. Complex ERP systems like SAP make that more likely, so a group of functional consultants getting together to discuss changes before they happen is a good thing.

I’ve had some changes rejected by the CCB because they didn’t have enough information to make an informed decision, or because something else was going on and they needed to wait on that, or because there was a change freeze. There might be many reasons why your change doesn’t go through.

Scheduling changes

The CCB can also schedule changes. There are normally scheduled windows to put changes in, especially in the live IT environment. That helps the support teams and the users know what is going to be different and what to look out for when they next log in.

Scheduling as a team also ensures that conflicting changes don’t get put in on top of each other. For example, if my project is updating the list of available categories in one part of the system, and another team is also updating that part of the system but taking away the category feature (that’s a bit extreme, but you see what I mean) then those conflicting changes can be discussed and overseen in an appropriate way.

It might involve putting them live in a particular order, or prioritising the changes so that one piece goes in this time and the additional change is put in next time.

I remember being told a story of a change in a data centre where engineers were working on cabling and flooring on both sides of a server stack. Without the support of flooring on both sides, the server stack toppled over! That’s the importance of making sure that changes are managed in a scheduled and sensible way.

We also had an emergency change procedure for anything that could not wait until the next release. On the SAP projects, for example, mostly things could be scheduled in a batch and changes pushed through on a fortnightly basis. But sometimes it was important to fix an issue straightaway without waiting until the next release. For example:

  • Bug fixes
  • Issues that affected customers
  • Changes that went in and then didn’t work as expected.

All of these are emergency fixes to live systems that wouldn’t be appropriate to delay, and they are all issue-related, not nice-to-have features.

How does your CCB work?

Posted on: February 15, 2022 04:00 AM | Permalink | Comments (2)

Who gets involved in project contracts? [Infographic]

Q1 tends to be a time when new budgets are approved and that means we’re starting to see requests for contracts with suppliers trickle through the PMO. It always takes a few weeks for budgets to get released, even if the intention is to start the work in January. By February, project teams are ready to get started, knowing that any further delay in the admin is going to put pressure on their ability to deliver by the dates from the business case. And that’s why all the supplier agreements seem to be floating around at the moment.

The infographic below talks about the major groups/people involved in putting together and approving supplier contracts for new third parties, but it’s the same people involved in renewing deals and reviewing an existing supplier to see if we want to give them more work.

 As with any internal process, this is probably a bit specific to certain environments and types of contract, and you might not see all of these roles in your business.

Equally, there might be some other key positions that have a part to play – I know that in one set of contract negotiations for a multi-million software project, my project sponsor attended every conversation, along with the technical architect. And just as well they did too: it created a great sense of common purpose and everyone was on the same page from the beginning.

Take the suggestions below as a starting point for opening up the conversation with your colleagues if you are creating new supplier agreements, so you can make sure the right people are involved from the start.

Read more about who gets involved in contracts.

Posted on: February 08, 2022 04:00 AM | Permalink | Comments (2)

3 Barriers to Effective Benefits Management [Video]

Benefits realisation management is one of the hardest things to do in a project setting (in my opinion) and in this video I explain why. I talk about three things that make it harder and give you a few tips on what you can do instead to help get over some of the challenges. The three things are:

  • Low skill levels
  • Poor integration
  • Poor processes.

Watch the video below and then let me know whether you’ve seen any of these challenges in your organisation!

There is more detail in this article: 5 Barriers to Effective Benefit Realisation that draws on information from Carlos Serra’s PMI presentation on the topic.

Posted on: December 07, 2021 04:00 AM | Permalink | Comments (0)
ADVERTISEMENTS

If we do not succeed, then we run the risk of failure.

- Dan Quayle

ADVERTISEMENT

Sponsors