Aligning Strategic Business Objectives With Project Management Strategy

Strategic Project in a Product Organization

What happens when your product organization is composed of more than 80 products?

This means hundreds of people working in individual teams with their plans. We were a group of three different companies, whereby each company was using its own platform and we decided to merge and switch to one platform. Moving forward, the plan was to replace the unique platform with something more ‘futureproof’ and that decision was translated to a company strategic objective, to be fulfilled within a year. The problem was that the product teams lacked understanding and alignment towards this objective , followed by no significant progress. As I was in charge of the project’s ownership, among all other issues, here are four significant challenges that I identified:

Communication: It was not communicated to everyone a clear re-platforming plan as a priority, and they should only focus on that for now.

Alignment: Not all the product teams followed the common strategic objective. Instead, they had their individual product roadmaps; conflicting with each other most of the time.

Progress tracking: Instead of tracking the individual product roadmaps and building a synthesis, we wanted to track a single, unique roadmap with no additional effort of consolidation. We had to find a way to get information from many different backlogs and have a consolidated view to track progress.

Keep ownership and autonomy of the product owners: Leading a strategic project and asking all the product owners to follow a specific priority could conflict with their position in the company and autonomy over the products.

Product Management Process: Steps, Roadmap, and Best Practices

Instantiate the project:

To begin with, we defined some project owners — another one of my colleagues and me. Together, we built and shared what we called a ‘story’ for the project. The story had details like:

• Why were we building it?
• What was so important about it?
• What were the key steps we would be following?

We created a documentation point via Confluence, where we had a designated space for the project, followed by subsections and elements of it. We also built a slide deck, which was available company-wide. When someone had a question, we’d redirect them to the slide deck; and if there were no answers to the questions, we’d work on it and then share our solutions.

Adjust organization

At first, we regrouped everyone (more than 100 people) invested in the project in the same physical location back in 2019. However, as time went on, with the current pandemic circumstances it was somewhat tricky, but we managed to organize the project kickoff. Interestingly, I extracted a specific epic scene from the movie “Interstellar” and adapted the subtitles from the film with some key elements from the project story. My goal was to share a feeling of urgency through a catastrophic, yet amusing, scenario and to engage people on the long road to come.

It helped the 14 involved teams to better picture the project. Nonetheless, it was a great success in articulating the ideas to their minds; and it worked wonderfully as nobody was expecting the project to be explained in such a way.

Establish a strong documentation culture:

To face complexity, along with Confluence sections, technical study documents have been created (Google doc) for each node of the process we were redesigning. Driven by architects, these working documents had a specific purpose: gather asynchronously people around a specific problem, write about the possible solutions and validate the decision taken for implementation.

Track the progress:

As this was one of the big rocks, we built a unified high-level backlog. Using Google spreadsheets, I identified some of the critical high-level features for the project. The features were extremely high-level — not the ones that individuals could find in their product backlog. It gave everyone an idea about the cross-product features. Making use of those features and labels in the existing Jira backlogs of the products, and after weeks of explaining myself, I was able to build the first transversal dashboard in Jira.

Assign one PO on each high-level feature:

Making sure that everyone is aware that I’m not the owner of tracking the progress of the overall features, I had some product owners dedicated to that task. Once the product owners were put in place, I met with them every week to update their progress. It helped me update my project view each week and share the brief with the rest of the stakeholders.

Communicate effectively and smoothly:

Since Slack was the official means of communication, we created designated channels. One channel was dedicated to the project, while each channel was per high-level feature. To avoid having too much noise in a single channel, we decided to have sub-channels to eliminate errors and confusion.

Apart from that, we did not leave any stone unturned by having mandatory meetings for everyone to attend and keep an eye on the progress. We had two meetings a week and a monthly follow-up session to share updates to keep the project alive. We stored the recordings in a shared folder for each of those meetings so that none of the information was lost in any of the steps.

Communication Is as Important as Planning and Execution:

• Don’t assume that a transversal project will progress by itself. There may be many products, and you have to align them and make the project exist by significant and repeated efforts.
• Pay attention to the product ownership, direction, and roadmap. Be transparent about their processes, roles, and expectations of them. Take the time to work with them and understand that the responsibilities are well split and comprehended so that nobody feels stepped over.
• Reinforce communication among stakeholders, even when you have to repeat yourself again and again. In big projects, you cannot expect people to understand and memorize everything you tell them.