How to realize the full value of 5G with organizational transformation

Complement automation efforts by changing the organization

Many Communication Service Providers (CSPs) have already started organizational transformation. Typically, they are led by IT and focus on automation platforms, tooling, or even cultural aspects. But, ordinarily, they have no mandate to initiate larger organizational changes. While it might seem easier to delegate this task, leaders feel that organizational and cultural change is a matter for them. “Such a responsibility can not be delegated”.

Organizations and the processes within them are built for stability and risk avoidance, on reducing and controlling change as much as possible. There is a strong hierarchy that positions teams within the organization and aligns responsibility for budgets and efficiency. Management tends to be very structured with multiple layers, centralized decision making, and manual reporting to control the organization. Regular contract negotiations are used to control partners and suppliers and this results in friction and distrust, obscuring common purpose and value creation.

Manually driven software delivery, deployment, and acceptance can take up to 6 month or more. It involves a lot of handover between organizations and companies, long feedback loops, and has a tendency to apportion blame instead of looking for solutions. Waiting times for corrections  are long and need multiple cycles of roll-back to keep systems stable. 

But we expect service deployment to be done within days, with full transparency and collaboration between companies to triage problems quickly, deliver correction, and assure the desired quality. To truly exploit the benefits of 5G, and to deliver value to society, CSPs should transform their organizations around value creation, change their management style and culture to support innovation and exploration, and focus on B2B partnering and collaboration.

To become a Digital Service Provider that delivers continuous value there are three areas that need to be changed: organization, management, and process.

The first step is to build a collaborative organizational model by identifying value streams between suppliers and CSPs and reorganizing teams around them. DevOps teams should work across company borders and organizational silos with transparency and a common vision.

The second step is to redesign processes to exploit the possibilities delivered by automation and technology transformation. With collaboration between supplier and CSP, and by breaking down the silos, steps that don’t add value can be eliminated, handovers can be reduced, and feedback cycles shortened to achieve faster time to market.

Thirdly, by anchoring these new ways of working in the organization a new culture shall emerge. Management 3.0, servant leadership, continuous learning culture, and celebration of failure is key to become a truly agile organization.

Using the latest technology, tools, and automation is important, but to become a Digital Service Provider, and to stay competitive, 5G DevOps transformation requires a full blown Mode of Operation transformation.

Building a collaborative organizational model

When building the collaborative organizational model, CSPs and Vendors shall identify the value flows and build a common DevOps team around them with aligned goals, metrics and secure communication channels.

Roles and skills need to be identified for rapid competence development with hands-on training planned and delivered for upskilling and enabling people.

Identifying Operational and Development value streams is key to building teams around value creation. This reduces handovers and brings people together for better, decentralized decision making, shortens feedback cycles, and fosters organizational learning.

A value stream contains the people who do the work, the systems, and the flow of information and materials. Identifying the flow of value from supplier to CSP, and the flow of feedback from end user through CSP to vendor, is the first step in building a collaborative organization.

Information exchange can be fostered by communication tools and platforms that are opened seamlessly between the companies. Support from IT and Security organizations to lay down ethics and communication rules are also important.

Next, a common DevOps team shall be formed to cover the identified value streams and to build a bridge between the companies. Members of this team need to come from both the supplier and from the CSP and should focus on delivering common goals that will be measured through common metrics.

There are certain DevOps topology patterns and antipatterns discussed by Matthew Skelton and Manuel Pais. Due to the fact that Dev and Ops are in different companies (seeing Telecom Vendors as Dev, while CSPs as Ops) we believe the common DevOps team should look like a combination of Type 4 (DevOps as an External Service) and Type 6 (DevOps Advocacy Team) to ensure collaboration.

To reduce the feeling of “us and them” the team shall have common goals irrespective of their company. Measurement of success shall be based on achieving the common goals and continuously improving towards them. This helps to keep the focus on collaboration instead of blame-shifting or finger-pointing. Utilizing an OKR (Objects and Key Results) frame is proven to work well and helps with alignment and engagement.

Achieving the goals will be measured against agreed metrics and automated to provide transparency on the current status. As in big LEAN factories, these metrics shall be visible to everyone.

Working efficiently in the common DevOps team requires new skills and knowledge and a clear description of each job role. Some roles will be concerned with keeping the agreed flow in place by connecting actions to processes.

DevOps teams are actually cross-functional agile teams where we expect to see “comb shape” members i.e. people with a wide breadth of general knowledge combined with in-depth knowledge in specific areas. 

By identifying the skills needed for each role we can uncover competency gaps and focus on filling them with dedicated education packages.

Use Value Stream Redesign to achieve ten fold process lead time

Once the organization is designed and we have a plan to enable the team, it is time to improve the process lead time. Value Stream Mapping is typically used to optimize processes, but a promise to improve lead time by roughly 20% is not enough. We need a stronger approach to redesign the process. Value Stream Design takes more effort than VSM, and needs good facilitation, but it can result in a ten fold improvement.

Value stream redesign starts with capturing the current state to get a full understanding of our process.

The first step is to create “swimlanes” to capture every role involved in the process. These can be extended later on as new roles are identified.

The next step is to capture all the activities in the process, the decision making, and the loops that appear when tasks need to be repeated due to faults or inadequate quality.

The last step in capturing the current process is to work out the minimum, average, and maximum times needed for each action, with transitions added, to show the cost of the action or transaction in time, as well as the variation. According to LEAN, waiting and variation are both waste, so they should be avoided.

Now that all the current processes are captured we can start digging to identify inefficiencies and suggest improvements. Identifying value added and non value added activities within the current process helps us to see what we need to keep in the redesigned process, and what we should change or omit.

Using LEAN techniques to identify waste, variation, and number of loops in the current process also shows us where to focus, and what to change.

Running a systematic root cause analysis for all inefficiencies helps us to understand the exact causes of the problems, and gives us the opportunity to achieve long term gain instead of quick fixes. Ishikawa and the five why techniques can be used very effectively for this.

By knowing the current process, its inefficiencies and their root causes, the future state process can be designed with the aim of achieving cycle times that are ten times faster. 

It’s important to have a commonly agreed set of criteria when starting the new process design. This shall be aligned with the goal defined for the common DevOps team.

The new process shall be designed around the identified roles, omitting the non-value added process steps, and changing the way of working to avoid inefficiencies targeted beforehand. Where possible, roles can be combined for further simplifying the new process, reducing the number of handovers.

After the new process is re-designed, a full blown process risk assessment shall be run to understand any associated risks. These risks shall be closely monitored and in some cases further process changes will be needed to avoid or mitigate them.

For the new process to achieve its full potential a lot of improvement needs to be implemented. It is important to list these improvements, prioritize them, assign owners, and follow up on implementation. The majority of transformations fail due to not adequately implementing all of the necessary changes.

The new, redesigned process might avoid some of the inefficiencies straight away, while for the remaining ones the root causes have already been identified. During this step improvements shall be systematically identified to be done on top of reorganization and competence development. Filling a control-impact matrix as suggested by Six Sigma DMAIC Process - Analyze Phase helps to prioritize actions based on what the newly formed team can change and how much it will cost to change it.

Every improvement needs an owner, an estimation on its implementation cost, and follow-ups on each action to drive them until competition. Without this step, the true transformation won't happen.

Aim for long-lasting change in culture and behavior

Once the new organization is in place, and with it more efficient processes, it might feel like a case of “job done”.

John Kotter stated in his book (The Heart of Change: Real-Life Stories of How People Change Their Organizations), “In a change effort, culture comes last, not first.”

The new way of working cannot be anchored into the organization, and its benefit can not be harvested, without long lasting change in the culture and behavior. It is management who shall lead transformation and change, and they shall also empower a culture of continuous learning and innovation. For example, they should treat failure as an opportunity to learn, rather than as an act to be punished.

As W. Edwards Deming states “It is not enough that management commit themselves to quality and productivity, they must know what it is they must do. Such a responsibility cannot be delegated.”

Management needs to lead the change, but they must also live the change themselves. This requires a growth mindset of lean and management skills. Leading by example is a very important skill that managers and executives should display by building on authenticity and emotional intelligence. Commitment to life-long learning is also important for those looking to lead the change. 

We have seen that culture hacking is a great tool to initiate small, incremental behavior changes when the management is living a new practice week-by-week. Examples can include running shorter meetings with preparation and expected outcomes added to every new invitation. All meetings that don't follow this format are rejected.

Decentralized decision making is also an important tool of management and absolutely necessary for our collaborative organization to work successfully. For most decisions it moves the authority to where the information is, and keeps centralized only the ones that are long lasting, infrequent, and on significant economies of scale.

As suggested for the collaborative team setup, using OKRs to connect actions with strategy is very helpful. You can set goals for the upcoming period and measure the achievement based on outcomes. However, we should remember that achieving 100% of the goals is not the target, and the aim should be around 70%. OKRs shall not be used for calculating incentives either. Instead they should be for discussing previous episodes and how to learn from them

Exploration and innovation requires risk taking and a try-and-fail approach. If the feeling of safety is missing, if failure brings punishment, out of the box thinking and exploration will be avoided. Management has a key role to play in creating the atmosphere for innovation.

As Bill Gates said, “It's fine to celebrate success but it is more important to heed the lessons of failure.”

An organization that celebrates only success while punishing failure will end up taking only calculated, low risk decisions. While this might look optimal in the telecom domain due to the need for service reliability and availability, it erodes the possibilities for innovation.

An atmosphere of psychological safety shall be built by fostering innovation and looking at every failure as an opportunity for learning. Retrospectives focusing on the root cause of the problem, instead of finding and blaming the person responsible, helps to build an open minded, solution oriented organization. Gene Kim has captured this as the Fourth Ideal in his book, The Unicorn Project.

On top of life-long learning for management, it is important to build continuous learning into the culture of the organization and enable it by supporting the growth of others with dedicated resources and events. Innovation also requires dedicated time.

Time for self and team education shall be reserved. Agile organizations set learning goals that are prioritized over every-day tasks to make sure they are taken seriously, and not pushed to the backlog. Dedicated time for innovation and resource allocation for exploring new ideas is also an important aspect. Making these visible in the calendar helps to embed innovation in the culture of the organization.

It is also important to gather hands-on experiences. As an example, exploratory testing sessions can be about more than finding bugs -  we can also learn new things about our systems. Bug hunting sessions foster not only team learning, but also team spirit. Mob programming and dojos are also part of agile practices for education.

Reflecting on milestones also helps the learning culture. Retrospectives at team level after each iteration combined with organization-wide retrospectives after each important milestone provide an opportunity to reflect on achievements, behaviors, and failures. Management should take part in these, own the improvement ideas, and drive them towards completion to improve the capabilities of the whole organization.

Becoming a Digital Service Provider 

The organization and processes of CSPs are built for stability and risk avoidance, focusing on reducing and controlling change as much as possible. To have service deployment done within days, with full transparency and collaboration between companies, to truly exploit the benefits of 5G, CSPs must transform their organizations. They should center themselves around value creation, change their management style and working culture to support innovation and exploration, and redesign their processes for a continuous flow of value. If they don’t do this they will fail to monetize the full potential of 5G and repeat the mistake of 4G by confining themselves to a bit part role instead of realizing full business potential.

Eficode has helped clients to define collaborative organization models, enable the teams with tooling and skills, and achieve 10 fold process cycle time improvements by redesigning complex processes. Our scaled DevOps transformation services and first-hand experience from the telecommunication industry helps CSPs on their digital transformation to monetize 5G. Contact us at 5G.Sales@eficode.com to take the first step on your DSP transformation.