How many truck rolls before you know you have a problem?

Apart from an obvious passion for OSS (is the URL a giveaway?), I also have a passion for real estate and property development. You’d think these fields are a long way removed, but today’s story ties them together.

I had one multi-townhouse development that took 3.5 years in the council approval cycle. The council team was constantly complaining because they had a mountainous backlog of developments to review, which caused glacial turnaround times.

It was true, they always did have a lot of proposals in their in-tray, but all the town planners seemed to be missing one point – the reason their in-tray was full was because they’d review a proposal, request alterations, then the updated proposal would land back in their in-tray. That makes sense… unless you repeat the cycle again and again (and again and again). Every review resulted in more suggested changes. Meanwhile new proposals would come into the in-tray, but only a very rare few would get out with an approval stamped on it (Unfortunately I’d chosen to develop in a council area that had the highest rejection rate in my state). The planners’ in-tray mountains just kept getting bigger whilst developers like me just kept getting more frustrated with the often inconsequential and inconsistent recommendations (in some cases the cycle was so long they’d forgotten their previous recommendations). There was no escaping the loop.

In a similar manner, I once had seven truck-rolls before getting a telco service commissioned at my house. Do you think that would’ve been profitable for the telco? It sure was frustrating for me to have to take time off to wait for each new team to come out and tell me that they didn’t have the requisite skills to complete the job. Each team was happy to just continue the incomplete cycle without thinking of the simple measures that could’ve broken the loop of delays and frustration.

The company’s OSS would’ve had all of the data. It managed the workforce and had fields to record all the skills needed. But unlike yesterday’s blog, which spoke of a continually improving cycle of build-measure-learn, there are too many incomplete-repeat deterioration loops in OSS. The OSS we build are brilliant at measuring… but if we’re not learning from data that indicates a 7 truck roll job (or more?) then profitability and customer advocacy will also be caught up in a circular motion… a death spiral.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.