Invisible progress: how to show value when nothing big has launched yet
Categories:
records
Categories: records
| It’s August, and I don’t know about your projects, but I’m working on some where we have made a lot of progress but haven’t actually ‘done’ anything yet. Do you know what I mean? Project managers can spend a lot of time supporting the team before any deliverables get delivered. Things like business case preparation, or solution design. Choosing suppliers and building out proper detailed requirements following ideation. Systems thinking work and as-is process mapping. All those activities are essential for making sure that when the deliverables happen, they are the right ones and fit for purpose. But it might not look like much is happening to the outside viewer. And summer is traditionally a time when things slow down, so it might feel to stakeholders that progress has stalled. However, we have to show that invisible work has value. ![]() Why progress becomes invisibleFirst, let me explain why I think progress becomes invisible. As you would expect, projects do require some upfront planning, even in agile environments. Someone has to decide what to do, and how it’s going to be done. Some projects need groundwork, prework, integration, whatever you want to call it. For example, I worked on a project where we needed to upgrade another system first so ours would integrate, that’s all important foundations.The other reason why progress becomes invisible is that you aren’t delivering any benefits yet. The outputs of these early, important phases are less tangible – it’s the agreements, the stakeholder alignment, the expectation setting. And the benefits come later. Don’t get seen as stuckYou don’t want your project to be considered slow or stuck, because that can reduce stakeholder confidence and pile on the pressure for premature delivery before the team is ready. It also can lead to increased scrutiny because everyone important will want to know what you are doing and why it’s taking so long! And that just adds even more time to the schedule as you navigate all the requests for information while protecting the team who are doing the work. The foundations are importantWe need stakeholders to see that this foundational work is important. The groundwork means the future outcomes are more assured. We are reducing risk and uncertainty. And I know it’s not easy to talk about this stuff and make it seem like it’s actual progress, but we can try. Reporting the slower bitsWhen you are talking about what you are doing, make sure to avoid hype. There’s no need to make the activities sound more important or bigger than they are. Be honest about when stakeholders will start to see deliverables or value. A roadmap can help them understand the sequencing as well, and you can include that regularly in conversations to reinforce expectations. Visibility is a leadership responsibilityProgress doesn’t have to be dramatic to be real, we know that instinctively, yet it often feels like we have to justify ourselves! Part of your role as a project manager is to translate ‘effort’ into ‘understanding’, and also to make sure that people involved in those early stages get the recognition they deserve for their part in the work. For example, system architects design a solution, but it’s often the deployment or implementation team that are involved in the project celebration at the end, as the architect’s work is long finished. Use these periods that might appear ‘slower’ to external viewers to talk about and celebrate the work that is being done. |
Back ups – are you ready for disaster?
Categories:
data security
Categories: data security
![]() While we all hope that nothing bad will happen to our project data, it is really important to have backups in place. Backups protect against data loss. I know that seems really obvious to say, but regular backup safeguard you and your project data against system failures, human errors, and accidents. Because who hasn't ever worried about reverting to a previous version of a spreadsheet or overwriting a change that you shouldn't? Well, those are small examples of the impact if data is lost. In a more substantive way, having a recent backup means the project can carry on with minimal disruption. It's often not the project manager's responsibility to set backups in place, because these will be managed by your IT team. But it is worth asking what data is backed up and how you would access it if you ever needed to because a long term project that loses all of its schedules and financial spreadsheets... That situation could be very difficult to recover. Another thing to consider is corruption. That is, data corruption or errors, because if there are problems with the data, a recent backup can restore the latest saved version and that will give you a fighting chance at recovering what you need to and keeping your records consistent and accurate. As I said, you probably don't get the opportunity to set the backup frequency, or even to identify whether or not a backup will happen for the particular system that you're using. But some cloud based project management software will give you the choice in the settings. If you have the choice, pick a regular interval that works for you. If it's a tool that you're using all day every day, you'll want a more frequent backup because then you can minimise the risk of data loss between the backup windows. If it's something that you only go into infrequently, you might be able to get away with having a backup once a week or once a month. Putting aside the issue of backing up an entire project management software system for a moment, let's think about the different versions of project documents and artefacts that you use on a regular basis. When you've got version controlled backups, for example in your online document storage, that can give you the chance to roll back to the previous version if you end up with discrepancies. For example, somebody accidentally going in and deleting slides from your steering deck, or wiping all the data from a tab in a spreadsheet. Your IT team may share that there are a few different types of backups that you can do, so let's just look at those for a second. Full backups give you complete copies of all project data, which gives you the confidence that everything is recoverable. These are quite expensive though. Incremental backups only back up the changes made since the last backup. That's faster, and means your storage utilisation is less. But it can be harder to recover if you have to recover everything. I think these days most of us rely on cloud storage, which is storing backups in the cloud linked to the software system or app that we're using. That gives you remote access which is a reassurance against hardware failure, because if you've ever had a laptop die after you spilled coffee on it, then you know that it's important to have off-site backups and remote backups and cloud backups because storing things on your hard drive can cause problems later (Don't ask me how I know). Take this article as a reminder that it is important to manage your project management tools and documents using automated backup solutions that reduce the risk of human error and takeaway the fact that you have to think about doing the backups at all. Mostly your tools will have this built in because it's not an unusual requirement, but if you can't see how a product is backing itself up then it's worth asking the vendor or your IT team. Just to be doubly sure that you have that confidence and security that all of your project-related data is safe. |
Contingency isn’t spare money: How to use it properly
Categories:
contingency
Categories: contingency
![]() Contingency can cause tension in projects. After all, if you’ve got it, why not spend it? Although before you can spend it, you have to work out who can approve the contingency… Common mistakesContingency does exist to manage uncertainty. You can’t know what is going to happen on every project, so it’s worth having some money tucked away for a rainy day fund.Sometimes I see project managers treating contingency as a buffer for poor planning. If a project holds contingency but can’t explain what it is protecting against, the money quickly becomes vulnerable to being reallocated or misused – no sponsor wants money sitting around that could be used for other capex investments or projects, especially when the team can’t justify why they need to hang on to it. The second issue is that if you haven't done your planning correctly, it can sometimes feel easy to just eat into the contingency because it's there. And that’s not correct. If your estimates were off, it’s better to own that, and look at creative scheduling options before you dip into the emergency fund. Another thing that can sometimes be a problem is project managers or their teams spending contingency quietly, because then it avoids having to do an escalation. If you have to escalate a problem, you have to talk about it and share solutions, including what the costs might be. But that can lead to an awkward conversation that you might want to avoid! Using up a bit of contingency to get rid of a problem can seem like a good idea in the moment. However, longer term, it's not a good idea to get into the habit of spending under the radar to avoid conflict or a difficult conversation, not least because it makes it hard to understand the true cost of the project and how good the estimates were at the beginning. A better way to manage contingencyA good way to manage contingency. Is to think about how you can link it to risk events. Consider what activities might cause risks, raise a risk about those things, and then consider how you can create a mitigation plan that means you're identifying things that contingency can be spent on – the items that will help you manage through risk. You also need to track the drawdown transparently in a way that helps you evidence how it has been spent and why it was spent. Spending contingency needs authorization, and at the beginning of the project you should have worked out who can give you the permission to go ahead and use some of that money. Great news if it is you! If not though (and probably it won’t be) you should get clarity as soon as possible so you work out the process for when you need to use it. That forms the first part of your contingency tracker. Make sure that you have separate lines in your budget to account for how and when contingency is spent. So if you ever need to justify what decisions were made you can go back and show people what was done and why. Sponsors feel more secure knowing the money was used in a controlled way, rather than as a sticky plaster. Used well, contingency strengthens trust because it shows you anticipated there would be problems and managed thoughtfully around them in advance. Compare that to spending it in a less controlled way – it can make the project budget feel suspiciously fake and weaken the project’s financial credibility. |
3 Financial signs PMs often miss
Green is good, right? But a project that is on budget can still be in trouble, even if all the signs are pointing to a Green RAG status. Let’s look at some early warning indicators beyond headline budget, which are sometimes financial signals that project managers miss.
|
What’s next for project managers? Emerging roles to watch
Categories:
Career Development
Categories: Career Development
| PM roles are diversifying, don’t you think? I’m friends with technical leads, delivery managers, implementation managers, and people with all kinds of job titles. You might know people with the title of delivery lead, or value manager. Transformation manager or portfolio integrator, systems integrator, things like that. And that’s a good thing, if you’re in the market for a new role but I can imagine that it also creates anxiety – what does it mean for us if we stick with ‘project manager’ as a job title?
|








Hidden financial risks
Why roles are fragmenting