I’ve been reading the Project Routemap Procurement Module and it’s got some really interesting things in around setting up a project for success. It’s a UK Government publication, aimed at large-scale public sector initiatives, but there is a lot we can pull out and apply to other, smaller projects.

The procurement module is one of several, and I’ve been reading it in light of it being a good resource for project audits and peer reviews. For example, there’s a short sidebar of different project documents and reports that might be helpful for finding out more about the existing procurement arrangements on an in-flight project. I’ve pulled out some from the list below, along with my own explanation of what these might tell you.

Procurement strategy

This will be the main one. The procurement strategy for your project might be a simple ‘we’re buying this thing’ in the business case or it might be a more detailed, evolved document that lays out a multi-year, multi-vendor approach.

ITT and bid selection docs

Invitation to tender (ITT), the responses and the bid selection criteria help you decide which supplier to go with. We also found them useful to go back to and review why decisions were made and what assumptions were made at the time. The bid selection criteria are so important to get right, so involve the right users and teams in pulling those together!

Regulatory and statutory requirements

Any compliance requirements that affect your project will also affect your ability to procure services from certain suppliers. For example, in UK healthcare, there are many requirements that must be in place to allow organisations to contract with the NHS. If the supplier cannot meet those requirements, that might affect the ability to deliver the service.

Sustainability strategy

Many organisations now have a sustainability strategy or environmental goals. For example, choosing to partner with suppliers who are making the commitment to working in sustainable ways, or only buying energy efficient light solutions, and so on.

There may also be environmental impact assessments for the project that show what the impact will be and how that can be mitigated or approached.

Contracts

Another big one: I remember having a bound copy of a contract on my desk during a long project. Not because we needed to refer to it to hold the supplier to account, but simply because it had useful appendices that documented the payment schedules, milestones, service levels and lots of other things I seemed to need to look up often.

Any framework agreements and other types of third party agreements (like heads of terms or service levels) would also fall into this category. They shape the relationship between the supplier and customer, so they are useful to know in detail.

Funding arrangements

If your project is being funded from grant income, or there is a limited window in which to spend the funding, or you have to apply for funding to be released in stages… all that is good to know as you enter the delivery planning. Funding milestones are typically big ones because you don’t want to miss the deadlines.

There are lots of others, like a contract management plan, supplier relationship management plan, the business case, stakeholder requirements, the benefits realisation plan and more. What else do you use when it comes to managing project procurements?

Have you got too much on your To Do list? What about the backlog – is everything in the ‘must do’ category? What about your project prioritisation process? How many projects are top priority, even when you’ve applied what should be reasonable and weighted criteria designed do rank projects based on importance?

Yes, I’ve been there. Everything is important and stakeholders want it all tomorrow.

We all know that isn’t possible, and in most cases, isn’t even desirable. Some of those ‘tomorrow’ dates will be totally arbitrary, and based on the shadow of a promise instead of fact-based, schedule-driven expectations.

But when a senior person asks you to do something, or your trying to guide the team through a prioritisation exercise, how can you manage all the things to do? Here are 3 tips for reframing your workload and helping stakeholders see what’s possible based on capacity and priority.

1. Go back to the ‘why’

What’s the benefit of doing the task, project or of delivering that feature? What’s the rationale behind it and the user impact? Think about how you can measure the success of the deliverable and what return it will provide. That doesn’t have to be a financial return, it could be a social impact return, customer satisfaction improvements or something else.

Understanding the reason for doing the task and what comes out the end of it will give you greater insight into priority. The project that has the largest return is normally worth doing over the project that has a small return. The automation task that you’ve been putting off setting up is going to free up resource time longer term, and that’s worth more to you than something tactical.

2. Yes, but…

When stakeholders are pushing for their tasks to be at the top of the list, ask for their help in prioritising. Say you can do the work, but at the expense of something else. What stops, or gets delivered later?

“Yes, I can take that on, but it means postponing delivering XYZ that you also asked for, until next week. Are you OK with that?”

“Yes, we can do that, but we’ve got a lot of other changes to work on first, so we won’t get to it until next month.”

The onus is on them to support the prioritisation effort, and it helps make them aware of the impact of juggling priorities – especially when their request impacts another stakeholder’s expectations.

3. Draw the line

One of the techniques we used in my old job was to maintain a list of changes and projects in priority order. We had a prioritisation model that everything was fed into, and the output was a ranked list of work.

Then we applied estimates to the work and reviewed the capacity of the team. That told us how much work we could take on as a department and what was next in line for when there was availability to pick up something else.

It was a spreadsheet, and it literally had a line under the work we could do. Everything under the line didn’t get worked on.

If someone expects their work to take priority, it needs to go through the prioritisation route. Sharing the list (and the line) with stakeholders helps them visualise why you can’t simply do it – even if it’s a small thing.

“Yes, that’s fine, it will take longer than normal to work its way through testing because of the volume of work the team has on at the moment. Oh, you need it sooner? Let me share the higher priority items with you if this takes precedence, so you can see what other stakeholder commitments we’d need to drop to do this more quickly. Perhaps you could talk to those stakeholders to agree the overall priorities? I’ll put a call in.”

What else do you do to help protect your time and prioritise your work? Let me know in the comments!

How mature is your organization’s approach to managing data? Today, all projects use a lot of data and generate a lot of data – and how that is looked after is subject to legislation, best practice, policy and ethics.

AI doesn’t make it easier either: AI engines trawl through our data while also creating new data of their own. With all the analytics on offer today, how we manage our data, interact with it and understand it is essential.

Therefore, a data management strategy on your project is important. OK, if ‘strategy’ is too formal a word, perhaps you want a data management approach, or plan. What that looks like is going to depend on your project and the kind of work you do overall. Perhaps you already have an IT team that focuses on data management. Surely you’ll have an Information Governance team or Information Security who will have something to say on the topic.

The risks of not having a joined up approach to managing data on your project are clear to me, and I’m sure you’ll recognise the ones I’ve highlighted below in your own organization.

Data leakage

Or, to put it more bluntly: poor data security makes it easy for people to take your data and use it in ways that you were not expecting.

That doesn’t just mean hackers. If your systems are not locked down internally, you could find members of staff accessing customer records when they shouldn’t have permission to see the data.

Data leakage also encompasses being able to extract the data from one system and use it in another. For example, copy/pasting from a data presentation tool and then manipulating the data in a spreadsheet. When data is at risk of ending up where it shouldn’t be, it can’t be controlled and that can leave the organisation open to financial and legal penalties.

Efficiency losses

Data makes us faster… or at least, being able to find the data we need without spending ages searching for it does.

A project data management plan could lay out where data is being stored, what it is for, how to access it, who has access, what reports are produced and when, and lots more. Hopefully that should offset some of the frustration of trying to access something that isn’t available (to you, at least) and also save time and duplication of effort.

You can schedule meetings around when data is available so the team is looking at hours-old results instead of something that was produce a month ago.

Poor decision-making

If you don’t have the data, you can’t make data-driven decisions. The risk to your project of not having the correct, reliable data, can be huge. On one project, I had to create metrics and report on them regularly, but the underlying assumptions for how those metrics were calculated changed, and then I wasn’t comparing like with like. That messes up your ability to track and report reliably, and also made it look like I didn’t have a clue what I was doing!

Work out what data the project needs to inform decision making at every step and then factor in ways to get it. The more this can be automated, the better, because then it is more likely that the calculations will be based on the same formulae and assumptions each time.

Do you have data risks on your risk log? If not, why not? Or are there more you can think of? Let us know in the comments so we can all benefit from taking a smart approach. Thanks!

Let’s talk about commercial viability for your projects.

Commercial viability is something that is considered at pre-project stage. It’s all about proving that it is worth going ahead with the work because the figures make sense. It’s typically related to working with suppliers: your analysis establishes that the relationship is commercially viable, which means you’ll both get something out of it and it is worth the time and effort involved.

A commercially viable deal will be one where the procurement decisions and contract offer the best value to the organisations involved over a time period that makes sense for the deal.

One of the challenges is that what sounds commercially viable today might not be tomorrow, if the market changes, or a supplier goes bust, so it’s important to take a proactive approach and be as risk-aware as possible.

We’re now in the realms that – in my view – stretch outside of a project manager’s remit. As the project manager, it’s unlikely that you’ll be signing the deals or commenting on the financial viability of the partners you are about to start working with. But you can make sure that the right people are involved on both sites.

Here are some things to consider.

What procurement options are available, and have they all been considered? What are the contract terms and is there a break clause? How long are you locked in for and is that acceptable?

What do both sides need out of the deal and what are the requirements?

Where does the risk sit, and if it is with your organisation, is that acceptable? What does the risk profile look like when aggregated across the programme? Do you feel that the supplier is taking too much risk to the point that it might jeopardise their ability to remain commercially competitive?

How and when will payments be made? That can affect the commercial viability of a project because it impacts cash flow. Large payments need to be pre-organised in my experience, so they can made in a timely fashion. What are the payment terms – you might be surprised at how often payment terms are a sticking point for negotiations! We all want the money in our bank for as long as possible…

How will the money spent or earned show up on the books? The accountancy treatment is something that the Finance team will agree. For example, exceptional spend might appear below the bottom line. Some items might be capitalised; others will not. This is out of your control as a project manager, but it gives you confidence to know that someone has considered it and made a definitive choice as to how these things are going to be handled.

Finally, are there any staffing requirements that affect the business case, or the chances of the deal being commercially viable longer term? For example, with the supplier provide staffing, and then when those individuals leave, you have to pick up the resource requirements internally? Build in any costs of handovers, transition planning, a drop in efficiency while new members of the team get up to speed and so on.

All of these discussions take place at various levels, and the summary ends up in the business case before a project is approved. It’s just worth having them on your radar so you can prompt the right people at the right time and get the best possible start for your project.

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:

1. Review your processes and look for where you can build resilience in to keep things moving and avoid the process stalling
2. Look at your resource plans and consider how you can build in resource redundancy – maybe get a few more people on a training course
3. 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!