The Money Files

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.

Financial risk

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:

• Changes to exchange rates
• Changes to the price of goods or services
• Strategic changes that alter the course of the programme

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:

• The programme financial management plan including the metrics you will use to track performance
• The initial programme budget, made up of the elements above
• Programme funding schedules showing where the income is coming from
• Payment schedules for each project, component or workstream, at least as far as you know them right now
• Operational costs for the programme e.g. resourcing that cannot be capitalised
• Risks for the risk register.

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?

I have lost count of the number of times my project testing phase has been squeezed. When you are up against a deadline, your carefully planned 3-rounds of testing with time for bug fixes and validation suddenly slide out the door.

And yet, no one wants to put out a product that hasn’t been robustly tested. That’s just asking for trouble from the customer. I know iterative methods allow for rounds of improvements, but they should be functional, incremental improvements, not fixing bugs you let slip through because the testing wasn’t good, or long, enough. That’s my view, anyway.

It is tricky to schedule time for testing, because you don’t know what you’ll find. Perhaps the solution is so brilliantly coded that nothing buggy will be found. (Ha!) I think this is where some of the pressure comes from: sometimes managers disconnected from the process of creating something new feel that as each component of the software works fine, together the whole will work just perfectly. “If the build has been good enough, there won’t be much to fix.” If only.

Testing goes beyond simply making sure the code is good enough. We test the processes, integration, training materials, communication approach and more. Here are 5 quick tips that I’ve picked up over the years for testing. Perhaps they will be helpful to you too.

1. Keep notes

I know, keeping a note of exactly what you pressed and what happened is boring. Users don’t always understand the rationale of following the script and noting down what happened. Detailed notes help other people replicate the error so they can see it, understand it and fix it.

Get into the habit of documenting everything. You’ll be grateful later.

2. Try to break it

This is the part of testing I enjoy the most! And it kind of contradicts with following the script – except you should have test scripts for trying to break the product too.

Encourage testers to do things in the wrong order, use the product incorrectly and see what happens. You need to make sure it is adequately developed to deal with those use cases ‘in the wild’ as well as for the users who have read the instruction manual!

3. Test with real users

Talking of users reading the instruction manual, ideally testing should be done with the involvement of users. I have been on projects where testing has been done by a professional test team, in our test lab. That was great. The level of detail and accuracy and information provided was awesome and elevated our confidence in the product. Testers are brilliant.

But you should also involve some end users. They may find the test process regimented and a bit difficult to get on with, but a little training should help with that. That community will provide a different insight into how the product works and can give you feedback on usability and process that a testing professional might not know, not being an expert in their job function with the wider business context around that.

4. Test what you can’t see

A lot of testing in my experience has been around what buttons do on the screen, functionality, do you get the data you expect. But when working with professional testers (as opposed to subject matter experts and team members we’ve drafted in to help check the software meets their requirements) they have always focused on what you can’t see as well.

Those are the non-functional requirements. Does it meet the company security guidelines? Is it fast? Can we back it up and do those back ups work? You should have non-functional requirements in the product spec or as use cases, so make sure the testing doesn’t overlook those.

5. Plan the testing

Finally, and I know it sounds obvious, but all of those things above should be in a test plan. Sometimes the test team has written this on my projects, sometimes I’ve had to write it (and probably didn’t do that great a job). But whatever you do, to whatever level of quality, the important thing is that a test plan exists so you have some idea of what is expected, who is going to do it, what you are looking for and how the test results will be fed back to the people who can make the improvements.

Make sure a test plan is included in your overall project plan, and if you aren’t sure how to put one together, get some support from people who have done it before.

I’m not a tester, so I’m sure there is more to it than what I’ve written above from the point of view of a project manager. What would you add? Leave a comment below to tell me!

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.

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!

You hear it all the time: “We want our project managers to add value.” “How are you adding value to the organisation?” “I want to spend more time on valued-added activities.”

But what does adding value actually mean?

I’m not a great fan of buzzwords that I can’t explain and turn into practical actions, so I’ve given this topic quite a lot of thought over the years. Here are 5 things I think you can do to add value (in a meaningful way) as a project manager.

1. Team building

Projects are done by people. People make up teams. Groups of people don’t have the same impact as a well-functioning team. Therefore, spending time on team building is worthwhile and will create value for the organisation because you’ll be better at delivering whatever it is you are delivering.

Focus on creating a positive work environment. Think about what people need to get their tasks done. Look for roadblocks you can remove, processes you can streamline. Talk about the blockers and why they are a problem.

And get some fun in there too.

2. Tenacity

Being committed to the team and the job, and the project, is a sure way to add value because it increases the chance the project will actually get done. How many projects do you know of that started but didn’t have the momentum to get across the line? That’s what tenacity will help you avoid.

Assuming you are working on the right projects, the ability to follow through and get the work done is important for making sure your time pays off for the company.

3. Relationship-building

This is such a large topic, which includes resolving conflict, smoothing over awkwardness, being diplomatic while speaking truth to power, respectful challenge and knowing who to connect and when. There’s a whole bunch of soft skills (or power skills, as it is trendy to call them now) that fall into this bucket.

They are important because this is what helps you get work done even when the environment is tricky. The more you listen, the more you understand and the easier it is to get your projects done. You’ll understand more of the business context that lets you make the right decisions that – you guessed it – lead to delivering a higher-value result.

4. Control the process

Governance might not seem like a particularly value-added thing to do, but when you understand and use the processes of project management, you can structure, standardise, save time, automate, compare and improve so much more easily.

If you have a standard approach, however informal, everyone knows what to do and what to expect and that takes some of the uncertainty out of what is normally a pretty uncertain time for people – projects deliver change and that comes with an overhead of having to live with not knowing exactly what the future will look like. That can be an added source of anxiety and stress for the team and wider stakeholder community.

5. Change management

Projects start to feel out of control when change is not managed appropriately, and that’s when stakeholders start to get nervous. You can help your projects be more successful and ‘land’ better with the receiving organisation, if you manage change properly.

That goes for both the process-led effort of receiving and handling change requests as part of your project management work, and also integrating what you are delivering into the business in a way that makes it possible for the benefits to be received as soon as possible, with the least disruption. Benefits = value.

How do you interpret ‘adding value’ as a project manager? I think it could go much further than what I’ve written here. I’m sure there are many other ways of looking at our role and how we can serve our stakeholder communities in the most value-adding way. Let me know by leaving a comment below!