Reality is OK, But Perception is Everything
Sometimes it doesn't matter how the project was delivered.
Hey, fellow Leader 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach me on Substack and share my newsletter if it helps you in any way.
A project is well underway and multiple deliverables are planned and already in production. My colleague, a Project Manager thinks the project is going great despite all the overwhelming challenges and mishaps, and what an achievement is that the project is not significantly behind schedule. However, the Sponsor sentiment and the major stakeholders differ from what my colleague would have guessed. For them, the project is not going well despite the achievements of recent events, because for them the conflicts with the IT team were permanent, and the Software is falling short in terms of end-user satisfaction. There was a clear gap in understanding between the project’s complexity, end goals, and which events were true achievements.
The problem with delivery bias
A Project Manager or an Engineer easily falls under the trap of delivery bias and makes assumptions about how things are progressing. Their focus is on the next thing to deliver and how it was planned initially. However, there is a great difference between what is delivered and “how” and “what” was delivered. The Project team assessed the scope and the work needed to make the product a reality, and despite the challenges the quality and the features were delivered. The stakeholders should be happy, right? Not always.
Agile with its feedback loops
One of the key principles of Agile is to implement feedback loops along the project execution. Whenever the team is using Agile, Scrum, or WhateverSexyFramekwork is in place, getting the feedback of stakeholders and adjusting the planning accordingly is key. But also, share with key stakeholders the same vision that the project team has. Not everything might be aligned, and perception be greatly different from who is executing and who will evaluate the project’s success.
Users will never know what they want until they see it in real life. This is a fact. Users need to play with the product and test ideas as soon as possible. This might become the first moment where miscomprehension starts to happen, and conflicts start to arise depending on the team’s flexibility to change things. But most importantly, at what level of expectation the end product is fulfilling the objectives? It doesn’t matter if the project is being executed flawlessly, it matters how it is perceived by the stakeholders.
The story starts here
In one of my previous projects, we needed to deliver a new and flashy platform for the reconciliation of some types of transactions and accounts. However, the stakeholders thought it was a straightforward job for an in-house IT development team, simply because we did it so many times in the past. Even senior management was not dwelling too much on it, since for them this project was a small part of a bigger picture. They simply didn’t want to waste time with us.
However, it was obvious to the Engineers the work was complex, with too many rules to be changed, and too many impacts for other scopes. To make everything worse, the product teams weren’t sophisticated and interested in having a minimum comprehension of speaking IT. A misalignment of expectations was doomed to happen.
When I reported the level of complexity to senior management, they didn’t want to hear. I was asked to simply “fix it”. In normal circumstances, project managers feel trapped and simply deliver the scope with the resources available. However, my goal shifted immediately to understand the root cause of such little interest in my project.
It helped that I was working for a few years in the company, so I had easy access to some people with influence and a view of the “other side”. After some queries, my project was a small part of a huge undertaking to address a regulatory and marketing gap. The overall goal was to get two rabbits in the same run, and my project was “an inconvenience”, an “unforeseen IT dependency”.
The perception
The senior management didn’t care about the quality or any product strategy for my team’s piece of software. They needed to have this dependency fixed. Luckily we find in the organization an existing solution that would address their needs. We didn’t change the software, we just suggested another source of data.
Let’s imagine we did change the software, it would be an uphill testing battle with low-engaged end-users. Everything dependency coming from us would be a low priority across the board, but despite all efforts, I know we would succeed. The result from the senior management’s perspective would probably be “that software was a problem from start to finish”. It didn’t matter if we would succeed. It only mattered how we were perceived. Luckily the reality has shown that “those IT guys” helped overcome a tricky point smoothly. These are the resemblances of a successful project.
That’s it. If you find this post useful please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest in the comments or send me a message on Substack.
Cheers,
Artur