The Writeup
Always start from customer: For a moment forget about all the roles & responsibilities, team structure and your organization. Just put yourself in customer’s shoe and understand what problem we are trying to solve through the proposed solution / product. Identify few key customer pain points which is getting solved and assess if there are any alternate solutions.
Understand the impact: Ask yourself and relevant stakeholders what will happen if this solution will not be ready by need by date? What is the impact? How impact is calculated? Evaluate if any trade off has been done on the short term vs. long term impact and solution. Understand the difference in the user and end customer.
Evaluate the product’s scope against your charter: Try to understand the expectation from your customers/ stakeholders/ product managers and then assess whether : a) Is the overall scope aligned to your team’s charter, b) Does the product requires effort from multiple teams, and c) If the complete scope falls under your team’s charter.
Evaluate the product’s prioritization: Make sure to evaluate the product’s priority through the product prioritization framework which you have. Get a sign off from all the decision making parties on its priority and need by date. If any trade off discussion needs to happen (like – other projects getting dropped, pulling in additional resources from other teams, etc.) then get all the required data and proposal; review with stakeholders and get a sign off.
Disambiguate requirement: Work with product managers/ end customers/ engineering managers to review the requirement and bring clarity on the requirement before handing it over to the team. While evaluating the requirement; work on following: a. Identify non-functional requirements. Sometimes as a TPM you may need to write them. b. If the product is technical in nature (like – data platform, Personalized recommendations, search related platform, etc.) then you may need to write the requirement as well. c. Identify component / system level changes. You can do this alone or you may consult Sr. engineers in your team basis the team structure/ complexities/ your experience and responsibilities. But you should make sure that at least you are involved in this process. d. Identifying dependencies: While reviewing the requirement and identifying component level changes – as a TPM you should identify all kind of dependencies like – Tech dependencies (where one component might require a change which is owned by other teams), any non-tech dependencies (like – getting clarity/ sign off from legal, finance, marketing, etc.). e. Identify impact from compliance standpoint: Assess the requirement and flag off any potential impact on compliance like – data privacy, InfoSec, or any other applicable compliance.
Put a high level program execution plan: You may need to do this in couple of phases:
Phase 1: Putting the first draft of program execution plan with tentative milestones and dates basis high level requirement.
Phase 2: Update it basis requirement disambiguation.
Phase 3: Update it post tech design completion.
There are no good or bad program structures and you may need to tweak it basis the program’s complexity and stakeholder’s need. Basis my experience and the scope of the project, I include following component in the program execution plan:Program objective/ goal.
Need by date.
Impact
Status : Previous week and current week
If the program is not on track then include the reason along with path forward.
High level milestones with projected completion date, owner, status.
Low level milestones (Mostly development and QA related) with projected completion date, owner, and status.
Dependency description, dependent team, alignment status, target completion date and status.
Risk and mitigation plan.
Project timeline chart.
Key accomplishments and any setbacks (from previous update).
Bug tracking snapshot (for the bugs reported from QA & UATs)
Reporting / collaboration mechanism: a. List down the different collaboration mechanism like – weekly report to xxxx stakeholders. b. Weekly status calls with xxx people. c. Bi-weekly call to track progress on dependencies. d. Daily scrum calls etc.
Documents/ references.
Link of sprint dashboards, QA dashboards.
Go/ No-go decision log
Deployment strategy and plan
Roll back strategy and plan
Launch readiness checklist
Post launch monitoring process
Drive the tech strategy and tech design: Depending on the situation/ roles and responsibilities/ team’s bandwidth and complexity of the project, as a TPM you may need to drive the tech strategy and tech design. Here driving means – understanding the problem statement, identifying possible tech changes or working with Sr. engineers to put together the tech design, facilitate discussions, propose your thoughts, challenge the proposal, assess overall ROI, align the respective stakeholders to get timely sign off and enable engineers when they are blocked. In short as a TPM you should be able to evaluate the tech design independently, drive the tech discussions in a constructive manner to ensure all perspectives are covered, bring it’s visibility to the applicable stakeholders and at last be ready to do go deeper into the tech architecture and come up with high level design and remember our key goal is to solve customer problem.
Understand & identify the risks and it’s mitigation plan: One of the key goal of a TPM is to protect the program from any risk and to do that you need to identify risks beforehand. There is no defined way to achieve this and you need to find out your own way to identify the risks. The bottom-line is to think what all can go wrong in all steps/ phases of the program and put a mitigation plan & owner against it. Once it is done, it is your responsibility to drive the mitigation on time.
Identify alternate solution if anything goes wrong post launch or if launch is delayed: Even if everything is going on track ensure to have a plan B and plan C. This will help in reducing the impact if anything goes wrong at last moment or if any unidentified risk gets exploited. Have a plan B as a backup plan if the project is delayed and keep plan C if post launch anything goes wrong (like – you have to roll back the product or huge effort is required to fix any high severity issues).
Keep all the stakeholders informed: Keep all the stakeholders updated about the status, support needed and key blockers. There are no defined ways to achieve this. Basis the scope, complexity, impact, duration of project, number of stakeholder, etc. you need to come up with an approach to decide: a. Frequency of report – daily, weekly, bi weekly, monthly, etc. b. Mode of communication – email, call, call followed by Minutes of meeting etc. c. Audience d. Content of report – basis the audience you may to change the format and granularity of contents. The key objective is to share the update in an un-biased manner.
Drive deployment strategy, go-no/ go decisions: As we get closer to the launch, as a TPM you need to work with engineers to put together the deployment strategy to ensure minimum negative impact on customers. Also, you need to work with product managers, customers, stakeholders, QAs and SDEs to drive go/ no-go decision.
Put together post launch monitoring framework: This includes monitoring key metrics (non functional – latency, API calls, CPU utilization, etc., functional – number of clicks, usage, drop outs, etc.), setting up process for post launch issue handling which includes – reporting issues, SLAs for different severity, prioritization and communication. 13. Setting up retrospectives: Setup retrospectives at regular intervals to know the areas of improvement and put together a plan for that.
||एकायन|| worldly wisdom ||
By looking at the above points it is clear that as a TPM you need to wear different hats at different times. Also, different stakeholders will have different expectation from you and they will reach out to you to know anything related to the program – so, as a TPM you need to be on top of status all the time, be un-biased, transparent, manage risks, understand customer’s pain point and have a good understanding of the tech architecture and come up with own proposal (backed by data/ trade off analysis) at all stages – prioritization, tech design, execution plan, go/ no-go, etc. And at the same time you might be managing multiple programs or having some additional responsibilities, so to do justice with all the above points, you have to come up with own framework.
Basis my experience here are some insights:
Identify right priority for everyday: Though as a TPM you have ample of tasks and many expectations but you need to be flexible on day to day task prioritization and execution. Every day by assessing the situation of the program you need to identify tasks on which you need to focus on that day. Like – if there are any customer reported high priority issues going on then on that day you may need to focus on that and de-prioritize some other task. You need to have your own judgement to identify which is the most important task at that point in time.
You are the owner of “T” in the program: Since you are a Technical program manager, you are expected to contribute in the program by optimizing & improving technical processes, contribute towards technical architectural decisions, identifying short and long term fixes for any ongoing issues. While ultimate goal is to meet the program objective, you should keep an eye open towards these areas.
Don’t try to get involved into each and everything at granular level: Don’t try to over-control the program. For example – don’t try to join each and every meetings setup by product managers or SDEs, don’t try to go into each developer tasks, execution and coding. If time permits and if some of these area interests you then it’s completely fine to go deeper. But remember you are a TPM and the expectation from you is completely different from the expectation from Product Manager, Engineering Manager, Sr. Engineers, etc. So, basis the complexity of the project, maturity of the team, team dynamics, etc. you need to identify some critical tasks for yourself where you are going to go deeper, identify the right owner for rest of the areas and make that person accountable for those actions and get regular update from them. As a TPM your key task is to get timely status, understand it’s impact on overall program, audit the status (if needed) and report it in a transparent manner.
Do not hesitate to say “No” or asking for help: As a TPM you need to learn the art of saying “NO”. You will be overwhelmed with the ask/ requests but as you are driving a program goal you need to assess these requests against that and if the ask is not aligned to the program objective then you need to say “NO”. As a TPM you are dealing in multiple areas, so do not hesitate to seek help when you need it or clarify things if you don’t understand it.
Have an audit mindset: You should have an audit mindset to verify the status which is being reported by different stakeholders/ team members. Also, this mindset helps in challenging the asks/ status-quo and enable data & facts driven decision.
Build trust: You need to verify the facts by maintaining trust, which is very tricky. Because as soon as you will start verifying the facts and reach out to folks for any gaps/ discrepancies people might start losing trust. So, you need to come up with your own approach to build the trust. I do it by keeping focus on end customer, being transparent and adapting to people first approach. g) Plan for unknowns: Actually you cannot plan for unknowns. But mentally you should be strong enough to handle any situations arising from unknowns. So, all your planning should have a room and undisclosed plan to handle unknowns.
Influencing without authority: To drive the program you need to influence lots of stakeholders/ teams (many of them are from different teams, different reporting chain) and get the work done from them. So, you need to identify own way to influence their priorities, roadmap and execution. I do it by: driving alignment as early as possible (i.e. as soon as you know the dependency immediately reach out and initiate conversation), drive alignment at all levels (like - product team talking to another team’s product team, tech POCs talking to each other, etc.), take data driven approach to justify the impact at organization’s level and customer’s level, adhere to the timeline & process proposed by other teams, do not share the status / commitment on their behalf with wider group, setting up the expectation at the time of taking commitment and in worst case scenario do not hesitate in doing informed escalation and asking for a leadership intervention.
Clearly setup the agenda and expected outcome of the discussions: As a TPM since you are the owner of program it is your responsibility to drive the timely decisions. To achieve that setup a clear agenda and expected outcome of the discussions and control the meeting. Make sure that the decision is taken and in case there is a delay then call out the impact of delayed decision to all stakeholders.
Don’t over complicate the project management activities. Remember your key goal is the program goal and all other activities are done to achieve that. So, restrict your processes/ trackers/ reports to only those which help you achieve that.
To summarize, there are 4Ts which is key to success:
- Transparency,
- Trust,
- Technical acumen,
- Tackle risks
