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!
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?
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:
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.