Streamlining Product Processes After a Reorganization

Our company went through a reorganization two years ago. It acquired one local and one European-based startup as a strategic move to grow. We welcomed 150 people to our team. As program manager, it was my job to shepherd the division through this change.

I faced several challenges. First, the newcomers didn't have experience working with a program manager. Program management was foreign to them. Second, there was no collaboration among the teams. They worked in silos, stuck to their own processes, used separate tools, and didn't communicate.

I had three aims:

• Improving reporting methods for project planning, tracking, and execution.
• Bringing cost savings by reducing the number of tools we use.
• Unifying the teams in terms of mindset.
  

Streamlining Processes Among Teams

Defining the Strategy

The first step was unifying the toolset, because checking different platforms for each group is highly inefficient. I looked over the stakeholder business units, examined how they functioned, and identified the technical gaps.

I interviewed each team to find out how they used their tools. I found out how they accessed the other teams' works, which often involved accessibility issues. I gathered all the functionality requirements from each team member. I identified the gaps, problems, and dependency factors. Then, I listed everything we needed to unify the teams.

I wanted to get leadership buy-in before making any decisions, which entailed talking with the product, engineering, and design leaders. I explained the importance of becoming one team, working on one product, and using the same toolset. I detailed why we needed our units to speak the same language and mentioned how the reduced licenses would result in significant cost savings for the company.

Informing the Teams

The company's infrastructure was on-premises. There was a plan to move all of its business units to the cloud, but there wasn't a set timeline. It didn't make sense for the product unit to wait for that change. Also, we still needed to get all of the teams working with the same tools. Therefore, my strategy included getting everyone on-premises temporarily.

With the go-ahead from leadership, I informed the product teams of the upcoming changes. I explained the plan to the managers. I described each tool's functionality, the processes, and the tracking mechanisms. Afterward, I got a pulse from all the stakeholders and determined the level of resistance.

Most people were in agreement because of the accessibility issues that they faced. However, one PM felt that moving to on-premises would be a downgrade. I acknowledged that some cloud functionalities would be temporarily gone and asked if they could spare some features during this transitional period. I spent a lot of time explaining how it was a short-term strategy for a long-term gain.

Executing the Plan

Overall, we migrated almost 15 projects across several teams. The planning took two quarters, while the execution lasted for one quarter. We worked on one project at a time, which enabled us to identify the issues early on and resolve them with minimal impact.

I collaborated with the IT team to identify: What data do we need? What is the plan for data management? What is our schedule? We also devised strategies to minimize the impact on day-to-day work. For example, our IT team is located in the Pacific time zone, while our new colleagues are in Europe. This allowed the IT team to work freely while our European team was out-of-office.

The Results

• We achieved our goal within the target date.
• The migration of the projects was sequential, and we learned a lot along the way. We quickly fixed any minor issues that were encountered.
• We surveyed the teams. Their feedback helped us build dashboards and metrics that would improve processes for future roadmaps.
• We cultivated a culture of knowledge sharing. We had onboarding sessions for the new process, and everyone had access to tutorials and videos.
• People got to know each other, and the teams started to collaborate.
• Upper leadership appreciated our success in this undertaking, as well as the significant cost savings to the unit.
  

Lessons learned

• It takes at least a quarter for people to get used to new things. Therefore, it's crucial to work iteratively and gather feedback throughout the transition process.
• Some people are persistent on the tools and systems they've been working with for a long time. It can be challenging to change their opinions. In these situations, it's important to highlight how a change will benefit them and their team. Meanwhile, some people are very open to adapting. They often become the promoters of the new ways, which is very valuable.