Long-term partnerships between carriers and OSS vendors are great, but only if we jettison the traditional day-rate model for such projects. Here’s why.
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 implemented).
Partnership is the keyword 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 incentivized for delays, bureaucracy, endless meetings and general inefficiency to prosper. In big organizations, these things tend to already thrive without any incentivization!
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 disincentivize efficiency, yet efficiency is one of the primary reasons for the existence of OSS and BSS. They also disincentivize reusability. Why would a day-rater spend the extra time (in their own time) to systematize what they’ve learnt on a project when they know they will be paid by the hour to reinvent that same wheel on the next project?
Can you see why PAOSS only provides the scope of work proposals (i.e. 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 customization. However, the vendor’s day rates were slightly higher than the carrier was paying for similar roles (e.g. architects, developers, etc). The carrier invited a third party to perform much of the customization work because their day rates were lower than the OEM.
Later on, I was tasked with reviewing a customization 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:
- For the sake of the process, let’s assume test and release amounts are equivalent
- OEM charges $1,000 per day for a dev
- Third party charges $900 per day for a dev
- OEM developer (who knows how the OEM software works) takes 15 seconds to write the code = $0.52
- Third-party dev takes (conservatively) five days to write the equivalent code (which didn’t work properly) = $4,500
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 OEM who completed the task and got it working in seconds (and was compensated $0.52); or
- The third party who never got it to work despite a week of trying (and was compensated $4,500)
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.