V2 infrastructure project

Multi year infrastructure overhaul ( V2 ) projects are complex and the engineering leader needs to champion the project from inception to delivery. The project requires a clear business driver and customer facing value. The engineering leader needs to work closely with the business leaders with the value proposition and ensure there is consensus on making this long term investment. There are several reason for starting a V2 infrastructure projects e.g. 

• Systemic quality issues with your current offering. The team is unable to solve them per component level and many components need to be redesigned to meet the quality goal.

• The system was built many years ago and the tech stack needs to be upgraded with the newer and more mature technology choices.

• The Need to merge multiple technology stack and re architecture is required to meet requirements from all different stacks.

Once you have clarity on the drivers for the V2 project, you need to go through a minimum prototyping phase with 2-4 engineer that will help identify the followings

• Components that needs refactoring/re-architecting and complexity associated with it
• Risks associated with the proposed architecture
• Intermediate and long term business values for the V2
• Rough estimate of the resources/time required to deliver on V2 project

The above plan needs to be shared with the stakeholders for their review and feedback. The stakeholders unanimous support is required for starting a V2 project. The engineering leader needs to spend enough time with each and every stakeholder to ensure there is no reservation and they are supportive of the project. The stakeholders also like to see the breakdown of the project with intermediate milestones.

Once you have the stakeholder support, then the next big challenge is how to organize the team for success. There are multiple ways

1. V2 team members are embedded inside the V1 team 

2. Spin up a new V2 team and its only focus is building/delivering on V2 infrastructure projects.

V2 team members embedded in V1 team

Pros:

• V1 is always evolving and the knowledge will be shared with V2 team
• The engineers in the V1 project will be supportive of V2 project as they see themselves working on V2 in the future
• It is relatively easy to move resources from V1->V2 at the right time

Cons:

• The V2 team may be forced to consider all requirements from V1

• When there is a resource shortage in V1, V2 projects may be deprioritized. This is a morale issues for the V2 team

Spin up new V2 team

Pros:

• Focused team for V2 project
• Clear project priority for the V2 team
• V2 team analyzes requirement carefully and removing obsolete requirements

Cons:

• The V2 team may miss or ignore V1 requirements

• V1 teams concerns about their future

The choice of organizational structure will depend very much on the current team you have and the complexity of the project you will be undertaking.

Once you decide on the team structure, the next important thing is to figure out how to manage this large project effectively. Some of the key considerations are

• Creating intermediate milestones with measurable business value: 
• Defining milestones is critical to keep the team focused on ensuring the team is making measurable forward progress. My experience is that the initially defined milestones change as the team develops the project and keeping these milestones updated helps with rallying the team. The millstones also help stakeholders understand expected progress for the project.
• Create Project plan - Deliverables, Budget, Resource, Time: 
• Creating a project plan for such a complex project needs special skills, where the project manager needs to dive deep into the project and also clearly articulate to the stakeholders on the progress. Project manager is a critical role for running such a large project and identifying an experienced project manager will increase the chance of success significantly.
• Identify risks early and have mitigation plans: 
• The components that have the most amount of risk need to be worked on as early as possible to gain confidence on the project. This project team needs to prioritize the work items with the most amount of risk early and identify the next set of items with high risk continuously. 
• Set KPIs and OKRs and keep measuring them: 
• OKRs help teams define the success criteria for each delivery and also align dependencies between multiple teams. It is important to ensure the success criteria are monitored closely. In some cases the defined success criteria may not be achieved at the projected time because of dependencies on other teams and needs to be addressed at a later time. Typically we should not see more than 10-15% discrepancies for a well planned project.
• Defining the KPI’s that should be measured throughout the project helps with addressing performance, quality, scalability and reliability during the design and development phases. If you do not have KPIs defined early, you may have to spend a significant amount of time after the functional delivery of the project to meet non-functional requirements. 
• Ensure testing, deployment, documentation, and security is part of the OKRs and KPIs
• Be prepared for unknown unknowns:
• A Project of this size will be faced with unforeseen issues and it is expected. It is important to always be on the lookout for such scenarios and communicate to the team/stakeholders in a timely manner. The best thing you can do is coach your team on how to bring problems to you early. Prioritize addressing the new problems quickly to ensure timely delivery of the project.
• Celebrating small victories and demos to stakeholders:
• It is important for the team and the stakeholders to understand the progress and celebrate victories at a regular interval. Setup regular meetings to showcase new business values you are creating incrementally to the team and stakeholders. This will help with their confidence on the project and also with stakeholders continuing support.