The Chief Digital Officer had recently got key leaders together to agree on the order of priority for project delivery. They had all signed up. Straightforward really, or at least it should have been.
Project X was a very challenging project for many reasons. These days Louise reflects “fondly” on just how much this project taught her about project sponsorship.
Side note: Delivery Scars
There is a term for the learning done when you work on large, challenging projects: Delivery Scars. I’ve got them, Louise has them, and so have all the successful Technology and Project leaders I know.
The term “scars” reflects damage that leaves an imprint. Yet in spite of the pain and the scars, the project delivers. Those who find a way to deliver through the challenges gain those “delivery scars”, and along the way we are rewarded with an education in delivering complex digital transformation. We know all the places where gremlins are likely to hide on projects, so can zero in pretty quickly.
Now, back to the story.
Project X had just got even tougher.
Louise had been asked to make a priority call between this project and Project Y, an even more challenging project with a higher profile. As tough as it was to do this, she also thought it would be straightforward given she had recently managed to get everyone to agree on the delivery priorities. Sadly, she thought wrong.
The need to make a priority call happens from time to time on projects. It means you need to choose which project gets access to scarce resources and which one misses out. It is always painful, leading to negative consequences (as a minimum, expensive delays) for the project that misses out. There is no happy path: I have written about this too.
Louise made the call and communicated to the team. A couple of days later she heard back from her project leader that resources were not being diverted onto the priority project in line with the decision she had made.
Agreements can seen simple. Until they’re not.
She immediately raised this issue with her Technology executive colleague with responsibility for the key resources. His response was, “I’m sorry Louise. Those resources are not available. They are working on Project Y. If we reallocate resources to Project X then Project Y will be delayed.” Louise said yes, that’s right. We have made a priority call and Project X has been prioritised over Project Y. We agreed to this priority order at our recent meeting.”
Her words were met with silence. Then her IT colleague sighed. He then said “Okay. I understand. Leave it with me.” He then arranged for the reallocation of resources. Project X went on to deliver (not without many other challenges), and after that Project Y became #1 priority.
Sure we agree. Until it is put to the test.
So many times we just assume we are on the same page with priorities, but we have not made sure of this, nor really explored what this means in practical terms. In this example, the Technology teams had Project Y loaded as their top annual delivery priority (even after the agreement Louise facilitated), and shifting this priority was not an easy thing to do. Louise’s team was not able to get progress until she intervened and escalated.
The agreement to prioritise Project X that Louise had facilitated was instrumental in getting this project delivered. Louise suggested to me that a more strategic approach of agreeing the overall priority order at a much earlier stage in the program, would have saved a lot of heartache.
Sometimes we sense that a priority is not really a priority.
Imagine you’re sitting around the Board table hearing that a project is a priority but it’s not making the progress that it should be. It is worth exploring deeper questions beyond “Are you sure this project is a priority?” Examples of potential questions include “What resource constraints is this project experiencing? What are the underlying causes of those restraints? What are the technology priorities of each of the key management team members?”
What do you think? Do you have other questions you have found helpful?
