The Money Files

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!

The Standard for Program Management, Fourth Edition (2017) defines Program Financial Management like this:

Activities related to identifying the program’s financial sources and resources, integrating the budgets of the program components, developing the overall budget for the program, and controlling costs during the program.

As you can see, there’s a lot more to crunching the numbers for program finances than simply having a single budget spreadsheet!

Let’s look into that definition a bit more and I’ll give some examples from my work as a programme manager (as we would spell programme in the UK).

Identifying financial sources

This means finding out where the money is coming from. In a large program, you might have a single source of funding, or several. Research projects, for example, might have grant income, so within the program you might have several funding sources.

On the large healthcare program I led, the Finance team created a brand new cost centre for the work so everything could be tracked in one place. Funding was centrally agreed and moved into that cost centre.

Identifying resources

This sounds easy, but in practice a large part of my role as a program manager was finding the right people to do the work and then helping them find the time to actually do their tasks! Admittedly, it’s a lot easier if your program has dedicated resources.

For some of my work, we’ve been able to budget for backfilled resources so we could bring people out of their day job and second them to projects. Then the project could pay for someone to cover their job while they dedicated their expertise to the work.

Integrating budgets of program components

Programs are made up of several (sometimes many) different projects and often a BAU component too. As a result, the program manager has to juggle the budgets and create a master, summary budget.

There’s work to be done here in making sure the whole thing is put together holistically and with the least repetition possible. For example, if you are securing a legal expert to support on one project, it makes sense that they are also kept on to help with another project as they will have gained some awareness of the program overall and the company. If the timelines can be made to work, or you can pitch a larger engagement for the legal consultant, you may be able to secure their time to get consistent resource (and maybe even a cheaper price for a longer engagement).

Developing the overall budget

When all the program components are effectively budgeted and you can bring the whole thing together, the program manager can create an overall budget and a way of tracking against that.

Controlling costs

Controlling costs is part of project, program and portfolio management, so it’s definitely up there as an important activity for program managers!

Luckily for me, my program costs were so large that I had the support of the Finance team – I think the company wanted the extra governance and accountability for having accountants pour over the details. Project budgets and costs were centrally managed and controlled in our cost centre. Tracking became a job of getting the data and consolidating it. Controlling costs became an issue of making sure change requests were done in an appropriate way and ensuring there was enough oversight of where we were spending the money.

We did not use EVM to track and monitor costs, but this might be part of your program management environment. If that is the case, you’ll probably have software to help you track and monitor costs and also to support with the reporting.

Summary

Program financial management might seem a daunting task but it’s very similar to managing your project budget. The numbers can be a lot bigger, but the maths is the same principles. What’s your experience of program financial management? I imagine it looks very different for every program as there are plenty of ways of setting up programs, and many variations on what financial management is necessary and appropriate.