Best Telecom Product Management Framework



Many telecom organisations, large and small, and in both developing and developed countries are frequently presented with the challenge of finding the most suitable structure and approach to product management and product development.


Only last week we were in several meetings with organisations where the topic of Telecom Product Management Framework was brought up, and followed by a passionate discussion.


Broadly speaking the conversation starts with a division of stakeholders into two camps:

  1. What we will call ‘highly structured’ or as some would say ‘waterfall’ approach, and
  2. What is commonly referred to as agile which its proponents claim speeds up product development and delivery.


Although we are using names of ‘project management approaches’, let us explore both of these scenarios and, in conclusion, try to revert back to, what in our opinion, is the most optimal framework model for telecom new product developments (NPD).


Our suggestion, as with any analysis is to take an informed approach and review both the approached independently.


Waterfall is a structured, sequential approach where each particular task in the project is done in phases. Tasks can be serial or parallel but generally once the phase finishes, the project moves onto the next phase. The number of phases varies depending on the type of a project.


Agile is a framework where phases (requirements/design/build/test) required to complete a project are generally done in parallel and with iteration. There are several Agile approaches but most have the same structure where tasks are broken down into small tranches (planning cycles). Requirements and solutions are continually evolving and based on priority and discipline.


In the first table below is our initial, very high-level analysis around the key advantages and disadvantages of each methodology.


Advantages Disadvantages
Waterfall Easy complete project planning, Measurable progress in phases, Target dates and deliverables, Independent stakeholders can focus on delivery of their own tasks Change in scope can impact the whole project, Errors in early stages of the project can impact later tasks, Dependencies and delays can jeopardise the whole project
Agile Easy to change requirements given short planning cycles ,Daily team communication via ‘stand-up routine’, Easy improvements from one task to next No clear overall project planning, Heavy engagement of product manager required at all stages, All team members must be skilled on the Agile approach, Easy to miss documentation deliverable after ‘product’ has been delivered


While the above is not an all-exhaustive list of characteristics of the approaches, it should be sufficient to provide us with some high-level understanding and guidance.


The second step is to apply the above to a range of the most common telecom product development projects of different types and shapes, to determine which approach makes the best sence for each type of development, as per the table below.


Telecom Project Example Requirements Characteristics Impact
Complex Product (eg. New fibre IP VPN network required) High CAPEX spend, lots of planning & design required, strong product management, vendor and engineering engagement required. Suggest use of traditional waterfall framework and workflows with stages and approval gates and dedicated project management resource.
Simple Product (eg. Change of CPE model on ADSL service) Low CAPEX, small amount of planning and design, some vendor and engineering engagement required. Use waterfall framework for the overall project while applying agile for specific project tasks or sub-tasks such as development of new CPE test plan, CPE testing, and documentation.
Product Feature (eg. New online product reporting portal functions) Low CAPEX, some amount of planning and mainly IT design, some vendor and IT engagement required. Use agile based workflow given software product component and IT systems impact. Overlay with gating stages to ensure quality and consistent documentation of deliverables.
Product Pricing Papers (eg. change to Broadband Internet price plans) No CAPEX, no planning & design and no engineering or external vendor engagement.  Finance approval may be required. Due to relative simplicity of the task and non-iterative nature of tasks, a simple waterfall workflow would be sufficient to cover all the tasks and gate approvals.
Product Exit (eg. exit legacy ATM product) No CAPEX, some planning & and low amount of engineering or external vendor engagement. Very significant impact on existing customers. Simple tasks but requiring precision around execution due to customer impact. Waterfall workflow would work best lead by an experienced project manager to ensure minimal customer impact.
Product Lifecycle (eg. ongoing management of a living product) Some lifecycle CAPEX, limited engagement of engineering, IT & vendors. Senior management high visibility. Considering repetitive nature of lifecycle tasks such as monthly reporting, forecasting, market reviews etc… a simple agile workflow can be used.



From this table, it is clear that a one-size fits all approach does not apply in terms of how to deliver Telecom New Product Development (NPD) and Management projects. So where to from here?


At this point the framework selection, assuming this is even put up to a consideration, usually gets decided by the management power of wills, sometimes arbitrarily or simply by each individual product manager who simply follows whatever steps he/she deems most suitable, based on their experience or background.


But this will simply not do.  Our view is that a ‘structured flexible’ approach is most suitable. While we recognise this may sound like somewhat of a contradiction, let’s explain it a little further.


Due to the nature of telecom products,  a considerable amount of structure is required even around ‘pure agile’ project such as software feature changes given the complexity of corporate IT systems, OSS/BSS interdependencies and the significant possibility of negative customer impacts caused by insufficient product quality and pre-release testing.


Thus the starting premise of the framework is that it needs to be ‘structured’. On this basis our steps are:

  1. Identify the most common types of product management projects and activities, similar to the list in table 2. Try to limit this list to 10 types of projects.
  2. As a second step, your organisation needs to develop workflows which would apply to each of the different project types. Each of the workflows needs to be reasonably detailed to capture all the activities and tasks required for particular project type. This activity will require a great amount of cross-business-unit collaboration.
  3. To each workflow you should add required documents, tools and templates. For example for the business case task, add a business case template, and document the deliverables required of project participants.
  4. Once the workflows designs are finalised, it is critical that the department’s heads provide agreement that such steps will be followed.


But structure isn’t enough. In competitive markets like telecommunications, players also need agility and flexibility.


Before your jump to step 4 and seek approvals, review the workflows carefully. Seeking input from colleagues with different opinions to your own in reviewing is important as it helps improve, not to simply endorse the workflow.


For example, if your background is structured project execution, insist on gathering feedback from colleagues with different backgrounds in Agile and software development. Ask them to review each workflow and to identify which tasks or ‘sub-components’ of the overall flow can be structured into small agile tranches. From there you should be able to end with a selection of ‘structured flexible’ workflows which have been custom developed for your own business.  And this would be a starting foundation of your own telecom product management framework.


In closing let me also clarify that many operators may wonder if such structure is really beneficial or will only add to the complexity of product development. In our experience the positives are overwhelmingly greater than any negatives.


Every time your company has created a product and the launch was late, such a framework would have helped. Every time you created a product with quality that was not acceptable, customer support processes not finalised, or operational staff not trained properly, the framework would have help. And any time you developed a product and your ROI was insufficient, the framework would have helped.


Finally, a word of caution: The framework is only the first step. It is up to you and your organisation to adhere to agreed steps, tasks and flows as in the long run this will be the true test of success. So changing culture is equality important through effective change management and organisational communication.


Share this: