I’ve just finished reading Business Resilience by David Roberts etc al. It’s a book that sets out a whole framework for delivering progress at a sustained pace and not being left behind in VUCA times. It’s aimed at senior leadership at the top levels as that is where the culture change is likely to need to start from, if you are rethinking strategy delivery.
It did get me thinking about what it means for projects and project managers. Thinking about what resilience meant in an IT world, back in the days when I worked in the IT team, I could draw a few parallels with resilience from a tech perspective and what it translates to for project professionals. (These are my thoughts, they aren’t from the book, which is far more strategic and articulate!)
Process
Process resilience to me means having steps in place to get things done, even when things change. For example, when I moved from a fixed term to a permanent contract, my records were updated. Unfortunately, that meant that I could no longer see any purchase orders that were approved by the ‘old’ me.
That wasn’t a huge problem but as process steps go, it would have been nice to have the continuity without having to ask for it.
Another example of building in process resilience is making sure workflows can be delegated when you are out of the business. For example, handing over order approvals, estimates or change management approvals to a colleague during your holidays, instead of them all being stuck in your queue to approve when you get back.
Redundancy
In IT, we used to build solutions that had adequate redundancy. For example, the servers would fail over to another server if the first server had problems. We had back up generators to keep critical systems operational if (when) the power went down.
In project terms, that would look like having two people trained to carry out a project role so that if one resource is off sick, someone else can step in and do the work.
That’s quite an overhead for a project team, as normally we wouldn’t want to carry additional cost, but on business critical projects, or where your resource is truly specialised, it might be worth it.
Data availability
How long do you spend looking for project documentation? Probably quite a long time, especially if its on a collaboration tool that shall remain nameless! Thank goodness for being able to search.
In a technical environment, we’d create backups so the data was available even if the main system went down (although of course with the redundancy, the goal is that the main system stays up…).
Project documentation and data availability in a resilient team would mean you could find what you are looking for easily, in the right place, and access the data.
I think as the world gets more complex, projects get busier and teams have more to handle, being resilient is more and more important if we want to get things done and avoid burnout. These are just 3 ideas of things you can do with your project team this week to be a little bit more resilient and prepared for what next week might throw at you:
- Review your processes and look for where you can build resilience in to keep things moving and avoid the process stalling
- Look at your resource plans and consider how you can build in resource redundancy – maybe get a few more people on a training course
- Consider where you store your project data and how easy it is for people to access when they need it.
What do you think of these ideas? Share any other resilience-building tips you have in the comments below!
