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.

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.

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.