A couple of years ago Mark Newman and the content team at TM Forum created a seminal article, “Time to Kill the RFP? Reinventing IT Procurement for the 2020s.” There were so many great ideas within the article. We shared a number of concordant as well as divergent ideas (see references #1, #2, #3, #4, #5, #6, and others).
As Mark’s article described, the traditional OSS/BSS vendor selection process is deeply flawed for both buyer and seller. They’re time-consuming and costly. But worst of all, they tend to set the project on a trajectory towards conflict and disillusionment. That’s the worst possible start for a relationship that will ideally last for a decade or more (OSS and BSS projects are “sticky” because they’re difficult to transform / replace once in-situ).
Partnership is the key word in this discussion – as reiterated in Mark’s report and our articles back then as well.
Clearly this message of long-held partnerships is starting to resonate, as we see via the close and extensive partnerships that some of the big service providers have formed with third-parties for integration and other services.
That’s great…. but…… in many cases it introduces its own problem for the implementation of OSS and BSS projects. A situation that is also deeply flawed.
Many partnerships are based around a time and materials (T&M) model. In other words, the carrier pays the third-party a set amount per day for the number of days each third-party-provided resource works. A third-party supplies solution architects at ($x per day), business analysts at ($y per day), developers at ($z per day), project managers at… you get the picture. That sounds simple for all parties to wrap their head around and come to mutually agreeable terms on. It’s so simple to comprehend that most carriers almost default to asking external contractors for their daily charge-out rates.
This approach is deeply flawed – ethically conflicted even. You may ask why…. Well, Alan Weiss articulates it best as follows:
“When you charge by the hour, you’re in ethical conflict with the client. You only receive larger pay for the longer you’re there, but the client is better served by how quickly you can meet objectives and leave.“
Complex IT projects like OSS and BSS projects are the perfect example of this. If your partners are paid on a day rate, they’re financially incentivised for delays, bureaucracy, endless meetings and general inefficiency to prosper. In big organisations, these things tend to already thrive without any incentivisation!
Assuming a given project continues at a steady-state of resources, if a project goes twice as long as projected, then it also goes 100% over the client’s budget. By direct contrast, the third-party doubles their revenue on the project.
T&M partnership models disincentivise efficiency, yet efficiency is one of the primary reasons for the existence of OSS and BSS. They also disincentivise reusability. Why would a day-rater spend the extra time (in their own time) to systematise what they’ve learnt on a project when they know they will be paid by the hour to re-invent that same wheel on the next project?
Can you see why PAOSS only provides scope of work proposals (ie defined outcomes / deliverables / timelines and, most importantly, defined value) rather than day-rates (other than in exceptional circumstances)??
Let me cite just one example to illustrate the point (albeit a severe example of the point).
I was once assisting an OEM vendor to implement an OSS at a tier-1 carrier. This vendor also provided ongoing professional services support for tasks such as customisation. However, the vendor’s day-rates were slightly higher than the carrier was paying for similar roles (eg architects, developers, etc). The carrier invited a third-party to perform much of the customisation work because their day-rates were lower than the OEM.
Later on, I was tasked with reviewing a customisation written by the third-party because it wasn’t functioning as expected. On closer inspection, it had layers of nested function calls and lookups to custom tables in the OEM’s database (containing fixed values). It comprised around 1,500 lines of code. It must’ve taken weeks of effort to write, test and release into production via the change process that was in place. The sheer entanglement of the code took me hours to decipher. Once I finally grasped why it was failing and then interpreted the intent of what it should do, I took it back to a developer at the OEM. His response?
“Oh, you’ve gotta be F#$%ing kidding me!“
He then proceeded to replace the entire 1,500 lines and spurious lookup tables with half a line of code.
Let’s put that into an equation containing hypothetical numbers:
In the grand scheme of this multi-million dollar project, the additional $4,499.48 was almost meaningless, but it introduced weeks of delays (diagnosis, re-dev, re-test, re-release, etc).
Now, let’s say the new functionality offered by this code was worth $50,000 to the carrier in efficiency gains. Who deserves to be rewarded $5,000 for value delivered?
The hard part about scope of works projects is that someone has to scope them and define the value delivered by them. That’s a whole lot harder and provides less flexibility than just assigning a day rate. But perhaps that in itself provides value. If we need to consider the value of what we’re producing, we might just find that some of the tasks in our agile backlog aren’t really worth doing.
If you’d like to share your thoughts on this, please leave a comment 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.
4 Responses
This is exactly why carriers need the skills in house to grapple these problems. Whether the solution is writing your own drop in replacements or working directly with the project maintainers to resolve it, not only does it reduce friction but it also helps the carrier move faster as there is less paperwork / SoWs and over time the carrier builds a practice to better maintain what they operate.
Brilliant insights Tony. I love the self-sufficiency concept you suggest. Speaking of which, check out the “autonomy” theme within this earlier article:
https://passionateaboutoss.com/theres-an-oss-security-elephant-in-the-room
Conversely, I also feel that telcos need to find a way to better utilise the efficiency of the gig economy (potentially facilitated by smart contracts). There’s so much bureaucracy, politics, etc that happens in all big organisations that there’s always inefficiency. If those big organisations can figure out how to scope up packages of work for offloading and then streamlining the review, approval and payment cycle, then there are huge efficiency gains in the offing.
Its a subtle message you present Ryan. There is no replacing an ability to size and estimate work with an objective in mind, allowing for comparative assesment of cost, quality and reliability. There are many tools available for this but most of all people with requisite experience and skill and a governance framework which enables that.
If one takes a ( perhaps innapropriate ) analogy of an industrial process, engineers know, more or less how much it will cost, there is a reference base and pitch is on delivery completion.
The RFP is not far from that if scoped appropriately, including staged delivery, an agile methodology approach is far from that as there are no clear guidelines to completion with several excuse loopholes including the one of inadequate requirements definition. People need to know where they stand and what is expected and while not a perfect world exceptions may be understood , vague assumptions less so.
So true what you say Peter.
The interesting thing around all this is there’s probably a time and place for each of the approaches, whether it’s RFP, T&M, SoW, agile, etc. And it also depends on how you use them. They can either work out great, or be diabolical, depending on implementation and the stakeholders involved.
As you can tell, I’m not a fan of people taking a default T&M position. That’s partly because it tends to also set the default position of not thinking about the outcomes of what’s being implemented. Sometimes, such as discovery exercises, the outcomes can’t be known in advance, so T&M can work. But like you articulated well, on most projects it is possible to size and estimate the work with an objective in mind.