Features and Analysis

Dream big but be realistic for successful business transformation

A few years back I was working for an IT company and was involved in an implementation project with one of the big telco operators. The project was already delayed, and we as a solution provider were struggling to manage the customer on one side and the third-party product vendor on the other side.

The core challenge the product vendor was facing was the compliance issues with the customer requirements. During this work, I also got to interact quite a lot with an IT guy from the telco side who was responsible for the management and delivery of this project. In one of our one-to-one meetings over a cup of coffee, he shared with me that while preparing the requirement list, he took inputs from the websites of three different companies that were providing similar products, consolidated everything and prepared one single sheet to put it in the RFP (request for proposal).

Now, guess what? No single product vendor would have the capability to satisfy all the requirements alone and engaging two vendors for a single solution was not feasible, desirable or logical. I could not spare much time on the project as after two/three months of me joining that project, I got an offer from a telco operator and I moved there.

Here, I was engaged in an implementation project but my role had changed. I was now in the same position as that previous IT guy was and I was handling a product service integration (PSI) and a third party product vendor. However, this time the project was delivered in record time with Phase 1 going live in under six months.

Get real

So, what was different in these two situations? I guess there could be multiple reasons, but if you ask me the true reason was a ‘realization of the need to be realistic’. I tried to correct this in my next opportunity and I believe that was the sole reason I managed to deliver in an equally complicated environment. The first situation had a ‘wishlist’ which I replaced with a doable/realistic list and yes, we got started.

Almost all the companies start with a wishlist. However, it’s up to the person who is responsible for deliverables to decide how to filter and make it more meaningful before sharing it with other stakeholders. Moreover, it is a collective effort from each contributor and should not be left to a single person to dissimilate the information. Just sticking to a wishlist often shows lack of knowledge and confidence in your own domain. Moreover, it might also give an impression about a confused state of the business.

On the other hand, doable means within one’s powers, feasible. And realistic means having or showing a sensible and practical idea of what can be achieved or expected.

We have bodies like TM Forum who are continuously working on defining new KPIs for all the domains within a telco environment and which are available for reference but still we see people coming up with requirements which are impossible to comply with.

I guess it also gives a sense of satisfaction and achievement when we prepare a list which others find it difficult to comply with. And this feeling takes over our prudence and objectivity. We tend to become more interested in finding gaps than supporting ways to make things happen.

I have seen requirements which the operator themselves are not able to explain. I believe one way to find out whether your list is realistic or not is to classify your requirements into two categories: must have and good to have, and assign two priorities: priority 1 and priority 2. Depending on the total count and items in the first category, you’ll be able to assess if you have created a wishlist or a requirement list.

Do not measure the credibility of the scope by the number of items in the requirement list. Longer lists do not necessarily mean a robust solution.


Remember the objectives of raising a requirement list, which are none other than:

  • The organization wants delivery to start in shortest possible time (ROI); and
  • Your bonus depends on the quality of delivery not on the length of the project

However, most telcos don’t take the second point seriously or they take the opposite approach, which encourages business owners to exaggerate situations and have weird expectations. Be realistic in your approach, and remember – sometimes it is better to keep your passion on the back seat for the benefit of the organization.

Dream big but be realistic for a successful transformation.


    About The Author

    Consulting Partner, digiCaaS Consulting

    Chaitanya Priya has 18 Years of telecom experiences in business consulting, telco operations and solutions. He has core expertise in digital BSS, revenue assurance and fraud management and is fascinated by the future of digital Ttlcos, working on digital enabling solutions and roadmap, digital maturity assessment, and digital RA modelling.


    1. Nabil Ahmed Zia on

      Absolute reality in words. I am always glad to see logical and technically sound people driving the project from the customer. Although it does lead to difficult Technical meetings, it is a lot easier to discuss technical complexities and workable alternates.

    2. I think in todays Project realization to delivery, the stakeholders are more interested in chalking the gaps/ competencies of others be it the vendors or partners. Rather than working cohesively for the project successes, the Stakeholder are more interested in making the equations more complex.

      Chaitanya I see the value of your write up here in keeping the requirements/ dreams simple and having a categorization and completely agree to what you have tried conveying for a successful project realization. Thumps up.

    Leave A Reply

    Back to top