Program Management

Context: In lots of situations Program Management isn't the problem. A lot of times development practices could be better, product selection could be better, etc. But what if developers are on top of it, and the product is good? How does program management look, and can it be a useful and honest activity, i.e. not just scheduling meetings and not operating in a world of "make pretense" plans that no one believes in.

---

1. TPM - makes it clear how what we are doing comparing to the plan. Forcing conversations about "we were planning for it to take 3 weeks, it's gonna take 3 months, we need to talk". Heavily use data for calling bs.
2. Someone created a plan, they talked to engineers, they did their best. Assume they did their best, and life happens, we are learning the plan is wrong.
3. Important not to have the culture of "you guys made a plan, stick with it", it's important to have a culture of trust and improvement and collective decision.
4. Program management - project manager across projects. Part of their job is calling bs, and making people talk, and make decisions, changing the time or the scope. "What do we do?" - collective decision and ownership.
5. Does TPM ID the problem or is also part of the solution? Depends on the level of a TPM, starts with program management and asking good questions. With experience - more technical and more solutioning.
6. TPM is in some way a bridge between different disciplines that might not be motivated to drive
7. In another company, TPM is facilitating a recurrent Risk meeting. However, there's a fortnightly release meeting, which is way too slow. In a lot of implementations, program planning is coupled with releases, and TPMs represent the engineering team to the larger corporate people, and talking x-functional talk (eg. legal, marketing, etc)
8. Still, the role of the TPM to force the visibility
9. Planning

• If there's a specific deadline - go back from the deadline, that makes it easier to give realistic estimates
• Not granular. 5-10 rows, if you need to scroll - too much detail. What needs to be done before what, what can be done in parallel, what has a long lead.
• Pushing back the rest of the schedule if that's what happens. Eg. We were planning to get this done in 4 weeks. 2 weeks later we are not half way in. Means it's gonna take more than 4 weeks. What do we do now".
• Being a time domain person, helping everyone
• If there's a gahnnt chart, people are gonna manage it. Sometimes it's helpful to hide it
• Starting with a plan - take a roadmap without dates. Or with dates. Eg. CEO told the board we're gonna do something by some date. Good to understand why that date.
• TPM's role is asking questions, and following up with "but my original question wasn't answered"
• During the planning time, find dependencies and interfaces, which is regardless of time and estimates. Sometimes a way to facilitate a conversation is to remove schedule off the table, and learn about dependencies and interfaces and uncertainties/risks and what needs to come before what.
• Unicorn or making x-discipline people talk? Unicorn is helpful, also can see if can enable someone to raise into this role. Otherwise, those two people need to talk, and why would they not?
• Episode 248 from Troubleshooting agile
• SAFe works for some (rare) occasions. But it can work, and it can work well. It shows what's ahead of us, what we need to deliver, what are dependencies. Let's say you have a large 10m project. Break it down into thirds, and see if you can do a third in 3m. That's how you'll get information about whether it's realistic. Prioritize projects using WSJF. Then the team says "we can only do 3 projects, not 5" for example, then you negotiate. WSJF motivates slicing :)