When speaking with a customer last week, I was hearing the same expression of anguish that I’ve heard so many times before. The anguish of getting an OSS business case approved.
Actually, in this rare case, the business case had already been approved. The budget had been allocated long ago. The exec sponsors were onboard weeks ago too. The business case had been given the green-light. Unfortunately, there were still other layers of approvals pending for the allocation of resources and another to do all the logistics required to commence the project.
I analogise it to jumping through a burning ring of fire. In many cases, including this one last week, it’s actually a series of burning rings, each one with a decrease in size and likelihood of approval.
It reminds me so much of this classic scene from the movie, Madagascar 3, that it makes me laugh (sad that even watching a movie with the kids ends up with me thinking about OSS). Like Vitaly the tiger, we have to oil ourselves up, do cartwheels down the runway and then hurl ourselves through the air, with a fear of impending failure and the rest of the team praying incoherently for our success. All at the mercy of the burning ring. A ring so small that it seems almost physically impossible for us to ever squeeze our way through.
If and when we do find a way through, there’s applause. Celebrations. Bewilderment at actually making it happen…..
And now, it’s time for the fun and even more challenging part. Implementing the project.
But one of the things that has always bewildered me more than project approval is that there seems to be a complete imbalance between the rigours at the start of the project versus the end of the project. Incredible feats up-front, with every number and fact checked infinitum. But at the end of the project, almost nobody does any form of analysis to see whether the project delivered on expectations. Okay. Sometimes there’s a PIR (a Post Implementation Review), but that’s normally straight after handover, not in the months or years after handover once the OSS/BSS is in operation. Does anyone check whether the ROIs aligned? That objectives were met? Has the project caused movement of whatever needle was aspired to be moved? Does the needle even exist anymore?
Does anyone record the track-record of delivery and use it as a feedback mechanism into future business case approvals? This is the part that I’ve always been most curious about. I have the strong suspicion that one of the reasons the rings of fire are so hard to jump through at the start is that all approvers feel the risk and fear of the project failing. It’s their reputation on the line if the project isn’t a success. Decision-makers are looking for the smallest inkling of evidence that the project might fail. They simply don’t have the confidence in their teams, their partners, their methodologies, their delivery track-records, their decision processes, etc to be able to make the leap of faith.
Speaking of partners, it’s often the partners in the crowd (the seal, the lion) that I hear speaking painfully about the OSS project approval process. Sometimes it’s internal team members who know there’s a massive pain to overcome within their business. Sometimes it’s delivery partners like OSS suppliers or integrators who have to wait patiently (and expensively) whilst all the hoops are jumped through. It’s not uncommon for procurement hoops to delay projects for 12, 18, 24+ months before a desperately needed and much anticipated project can commence. I’ve sat on both sides of this fence and know too well the delays, costs and frustrations incurred by all involved.
It was into this morass that I wrote my first book, “Mastering your OSS” a few years ago. I’d sat on the vendor / implementer side of the equation and seen the same fear, uncertainty and doubt (FUD) experienced by our clients time and again. The same fear of the unknown. The same impending mistakes (eg lack of change management, lack of awareness of the data migration and other implementation challenges, lack of work-arounds for infrastructure delays, etc). The same misunderstandings between buyer and seller as to who needs to do what. The same risks and potential mitigations.
I actually wrote this book for sellers to give to their buyers before the start of the project to make them aware of what they faced before the start of the project. To ready the buyers for the massive change that OSS transformation projects thrust upon their organisation. To answer the many questions the buyer and their implementation team has (or doesn’t even know they should be asking… yet).
My original intent was to partner with OSS vendors / integrators, where I’d work with each one and write a custom foreword and even customise the content to make it specific to the challenges that each vendor had experienced on their past implementation projects. I had around a dozen vendors who sounded really keen on this idea. Unfortunately, none actually had the time to work on the customisations with me. I hadn’t read the room expertly enough. That’s okay. Lesson learned.
It meant I was now selling to (inquisitive people on buyers or implementation teams) rather than selling through (the OSS vendors and integrators). The book has been a slow and steady seller since publishing, which has been great.
Funnily enough though, I believe more strongly now than ever before that the “independent third-party” is still a key element for fast-tracking projects. When the approvers are paralysed by FUD or have too many options to consider or just don’t have the confidence to make a leap of faith, it’s the same blocker. The confused (and fearful) mind says no. It’s an independent third-party that’s often needed as a circuit-breaker, to help move the no to the yes that everyone desperately wants. To remove the doubt. To simplify the decisions. To show a viable way forward. To craft the persuasive story of the “promised land” (ie the many benefits awaiting at the end of the transformation).
Sometimes the circuit-breaker comes in the form of consultancy / advisory, sometimes in options analysis, sometimes via new information or stories (eg blogs, white-papers, executive briefing packs, or my book). If you’re currently (or consistently) stuck in the approval stage of projects, we’d be happy to share ideas that might (or might still not) get the project moving again.
If you’re interested in finding out more about the 20+ questions that “Mastering your OSS” answers for the audience of buyers and implementers, click on the image below. If you represent a vendor / integrator and would like to discuss the sell-through strategy with the book, please contact us via the form below.
We recently discussed how the “Ultimate Game,” a study in behavioural psychology, might help to explain why there tends to be less initial animosity between
The great thing about the holiday period is you often get the chance to step away from business as usual (BAU) activities. As customer projects
Last year, we published a series of articles about the chasm that exists between OSS/BSS buyers and sellers. “The chasm” is best exemplified by the
Whilst setting up for another new initiative this week I became aware that the PAOSS blog has just ticked past 1 million words. And that’s
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
