Several years ago, I led a digital transformation project for a prominent university while working at a renowned tech firm. The game plan? Develop a unique tech solution on an enterprise SaaS platform to streamline revenue for a crucial business sector. It was poised to be a showcase of success not just for the university, but for my firm and the SaaS provider alike.
Our strategy began with a quick proof-of-concept (PoC) to ensure the solution’s feasibility, followed by securing executive approval for full deployment. The subsequent step would be a staged launch across the university’s departments.
At kick-off, the Dean of the effected Faculty had reservations about our approach. She was leaning towards an incremental, agile method post-PoC. Despite our domain expertise, It was apparent that we weren’t going to sway her. We suggested trailing agile during the PoC and reporting our findings.
Fast forward to our PoC demonstration. Although the solution was promising, our attempt at an exclusively agile methodology during the PoC stage presented significant challenges. Lack of direct communication with academic staff, our primary users, and limited decision-making authority within the university transformation team had threatened the timeline and budget.
We suggested a phased implementation would be the best way forward for this project. But, in an unexpected twist, the Dean insisted on a wholly agile
approach using the Scrum framework.
Frustrated and perplexed, we once again revisited our plan. Together with our senior technology lead, our project manager we debated the feasibly of a Scrum in the university’s heavily bureaucratic environment. Listening in on the conversation, one of our firm’s partners interjected into a lull of the conversation “Does the name of our approach really matter?” Stunned, we all looked at him. He raised an eyebrow and said, with a wry smile “I reckon if the Dean can label this as the university’s first agile initiative, she’d be content.”
His point was that not every objective stated in a transformation project is genuine.
It seemed the term “agile” was a feather in the Dean’s cap, a way to garner internal recognition, independent of the actual revenue outcomes of the project. Recognising this underlying motive and navigating it effectively was instrumental in our project’s overall success.
I remember this each time I read surveys and studies that report that “70% of digital transformation program fail.” Such alarming numbers often pave the way for discussions on the common culprits for failed transformation projects: lacklustre leadership, ambiguous communication, a paralysing fear of failure, misaligned executive priorities, and weak team empowerment.
Yes, these are legitimate concerns, but there’s an under-discussed factor: the authenticity of stated objectives behind an initiative. From my vantage point, the sincerity of a transformation’s intent can significantly sway its fate towards success or failure.
This was a profound learning for me: not every stated goal in a transformation initiative reflects its genuine intent. Being able to “read the room” in this regard has been a critical success factor in my career — not just for transformation program delivery, but also in determining what projects to pass up.