The Telco Churn Management Hand Book By Rob Mattison

I've finished the reading of this book as part of the preparation works for one incoming POC exercise. Not a hefty one, just a near 400 pages traverse of churn related matter in telecommunications industry. It did inspired me about some direction about how to better concoct an arsenal of stuffs to tackle churn. The book is pretty high level in the sense that besides the strategic direction and some tactical means of handling churn, it doesn't really craft down any specific implementation models which directly adaptable. It is inspiring yet you will crack your head yourself to think about the how-to.

Read it here

Time is running out and I got to do more knowledge churning.. literally!

Kid me Not

Airline didn’t pay dividends before as it wanted to build up cash

SEPANG: AirAsia Bhd is now in a much better position to consider paying dividends to its shareholders after solving some issues within the group, said group chief executive officer Datuk Seri Tony Fernandes.

“Shareholders did ask about dividend payment at the meeting just now.

“Having solved the uncertainty issues, we are now at the stage where the board will actively consider dividend payment,” he said yesterday after AirAsia’s AGM.

However, he did not explain further the uncertainty issues.

Fernandes did not say when dividend payment might happen but added that the group had made the right decision of not paying dividends up to this point because it wanted to build up its cash.

“We want to build up our cash as we want to grow the airline to be far bigger than any other competitor,” he said.


AirAsia does not have a dividend policy since it was listed in 2004 and if the payout happened, this would be the first time shareholders are receiving dividends.

He added that the group’s cash balance was approaching RM1bil and its business should grow from strength to strength from now on.

For that, he believed AirAsia’s net gearing would continue to go down from the current 2.26 times.

Fernandes also said the airline would fly to the Maldives in October and planned to build a hotel there.

SOA BIAN SOA BIAN

I've attended a presentation by an architect from a well known banking vendor just now. It was about adoption of SOA thingy into new product development. I gotta admit that I'm not at all convinced how by adopting SOA in application development can entice direct buying interest of BUSINESS decision makers, other than having the nice-to-have SOA enabled logo there and appease the techno-geek never-ending appetite of playing with state-of-the-art toys. Of course, my words might be too strong here but nonetheless my point is made:

SOA makes no value to a business if you can't justify its business values.

Hardcore proponents of SOA will probably start to shout at me, I guess. :p

"It enhances business agility"
"It improves time-to-market for new products"
"It helps to make the IT alignment to business needs"
"It embraces changes"
.... many mores COMMON praises of why you should have SOA in your complex environment.

I'd agreed with all the benefits of SOA, sincerely. Most importantly I strongly seconded that SOA indeed provides a very scalable and agile platform for software product development. As a matter of fact, it shares similar qualities with methodologies such as XP, MDA, Agile, albeit at a level of abstraction higher up.

"Most businesses are not being pressured enough by its environments to move to think about SOA"

"My business generates enough shareholder value that guarantees my big fat bonus and decent dividend payout, why I bother to take this risk?"

"SOA is not for the faint-of-heart!"

Interestingly, after I typed the phrase above, I did a search in Google and found this article that coincided with my opinion. Click here to read

One of the statement made by the architect that I couldn't disagree more was the "fact" that adopting SOA doesn't change the way business is conducted.

The value maximization of SOA approach shall be realized if and only if the business leverages on it to make the business process more agile, to alleviate process bottleneck due to IT inagility and to flexibly infuse process innovation. If you are an avid reader, you realized that I mentioned the word Process three times. :p
I just want to stress how important to view the impacts of SOA from the perspective of how it could change business processes and perhaps the entire business model of the company.

"80/20 should be 80% about BPM, 20% for the rest. Not the other way around."

Here is a hilarious article you should read about. Click here to read

I need to re-emphasize here: For all intents and purposes, SOA development approach is the best option we have for software development now, but it will not be cheap and easy to adopt. Higher setup cost and steeper learning curves are just few of many caveats that warrant a big post sign "BEWARE". High risk high return?

Let's ask ourselves. If you are the CTO/CIO in a complex organization with many existing IT assets such as a large bank, how high the ranking will it be for SOA project(s) in your priority list. IMHO, it will be way too low that you might just miss it. Why? IT'S TOO F**KING TECHNICAL and your boss is shouting for corporate capability such as proactive customer acquisition management or straight-through trading thingy.

"Don't be so shortsighted"

In fact, I'm not. I've been through enough tech fads and unplesant reality to draw my conclusion and I think further enough to cover more than just the main success scenario.

The rule of thumb is anything that tries to improve an organization at the scale of enterprise wide requires enterprise wide commitments. To name a few examples:

Enterprise Data Warehouse (EDW)
Enterprise Churn Management
"SOA"!
...

Any of the above is easy target for cruel reality check. I've seen EDW effort that turned out to be a huge isolated data mart used by few departments and eventually serves to be a source system to another EDW effort that subsequently failed too. Given this wonderful history of fad-goes-bust cycle, it could be a premonition for SOA initiatives.

I strongly suggest for any SOA project to deliver quick win results to convince a larger scale of commitments into its' accomplishments.

Think Business Always!
It's all about bottomline, revenue, cost and growth.

Pointed application, semantic stuffs? Emmm... KIV.
BIAN, metamodel, service landscape? Emmm... Still evolving.

Only 1 in 5 SOA Projects Actually Succeed

State of SOA Survey 2010

Only with all the critical success factors met, i.e. top management commitments of enterprise adoption and enforcement, standards-based and tools-based SOA infrastructures and clear-crispy SOA policy, procedures and best practices, we should be able to increase the likelihood of delivering an envious successful SOA project (Enterprise wide!), else it will be just another SILO, a pricey one.

A Smorgasbord of Amorphous Team

There's a series of interesting trials conducted recently pertaining to the idea of utilizing project-based knowledge workers in contributing to the completion of non-project based deliverables. The key motivation to this exercise is to discover whether the quality of these deliverables will improve and to gauge level of cooperations and teamworks in doing so. Chaos Theory actually popped out in my mind when I imagined about how this exercise will turn out. Specifically, take developing tender proposal as our example to shed some lights about this approach.

First, a RFP comes in. A variety of people are gathered to build response to this RFP including project manager, sales manager, functional fella and technical folks. These guys are from different project teams where some in R&D stage and others in project deployment or support phases. Then, assuming the existence of a proposal template and this template serves as the basis for segregating the sections out to different groups of people. Sound pretty straightforward I presumed? Lastly, works from these groups are collected and conciliated into a final proposal. Voila, we manage to submit before the deadline.

So? What's the big deal of meeting the submission date when the whole idea of submission is not about winning the deal. The words are pretty strong here but the truth is not all the participants have the same common objectives.

Let's do a quick analysis in this arrangement of structure. A direct KPI perspective reveals the obvious fact that these people are not working coherently, might even in contradicting interests. A fictional mindset of these people illustrated below:

Sales Manager - More Sales = More $$
Project Manager - More successful tenders = More works = Perhaps more $$
Functional experts - Project Performance is more important. Who's cares about tender?
Technical experts - What? Tender? Let me write some codes please.

The thing is if the person responsible to do some works don't just the sense of "If it failed, I will be screwed" accountability, you can just save your crossing-finger time. You are wasting them.

Of course, factors such as luck/randomness, weak competitions, pre-arranged deals and existence of heroism still might contribute to the chance of winning the tender, but SERIOUSLY, Are you going to let your corporation to solely rely on these?

Ya, you might argue that a truly professional would do whatever they are being assigned to in any best winning ways possible. Well, you might be right that such environments do exist but it might turn out to be a heroism-centric pit due to the frustration of these professionals dealing with "not-so-professional" and "not-professional" and deciding to turn over to others.

Tender is a crucial piece for getting more deals, Truly Qualified Lead per se.

Can you really afford to do such a trial-and-error experiment?
Not for me.

Do participants get motivated?
Yes and No, depends on your KPI.

Does the outcome have a shot in winning the project?
Possible, but hard to recur.

How to improve on this arrangement?
Incentive and Penalty. Carrot-and-Stick.

Do I recommend this arrangement?
No. A Tender Department is more suitable for larger organization.