BA 44/52: The Right Tool, Pt. 2 - Planning
One of the most difficult aspects of software development planning, especially for Technical Program Managers, is deciding which project management tools, methods, and frameworks to use. I don’t mean JIRA, Asana, Trello, agile, scrum etc. Let me explain.
There are a variety of tools available, each with its own strengths and weaknesses, dependent on the scope and scale of the project. The best way to choose the right framework for your project is to carefully consider your specific needs and objectives.
‼️ Experience Has Taught Me ‼️
Although industry tools like Jira and Trello are powerful in their own regards, issue management tools are not designed for planning. Why?
They force you to view the world in a structured manner (parent → child relationship).
They are not conducive to divergence → convergence style of thinking.
The overhead for revising large changes in the plan are difficult to do.
Despite having a purpose built tool at Apple for issue management, Radar, all of our planning happened outside in spreadsheets and documents. Radar was the source of truth for what was committed.
Here is a guideline, based on my experience, of when to use specific project management tools to help you get started. Use this as a starting point or reference, whatever helps you get started.
Small Projects
Length: 1 sprint (lets say 2wks) to less than a month.
Teams Involved: 1-2 Teams (Engineering and Design OR Frontend and Backend OR Full Stack Team).
Pitfalls: Testing and Validation is often ignored given the small length of the project timeline.
Best Planning Approach: Simple work breakdown approach is best. Start with the outcome desired then work backwards to how and what needs to be done to achieve the outcome. Primary emphasis and focus must be on the testing plan.
Best Tool For Planning: A simple spreadsheet or 1-pager doc will suffice. Task:Owner:Status - that is all you need. Eventually this spreadsheet will go into your favorite issue management tool as parent → child structure.
Medium Projects
Length: 1 month to 6 months.
Teams Involved: 2+ Teams.
Pitfalls: As the scale of projects go up, so does dependency management. Hand off between teams become critical and the primary point of failure.
Best Planning Approach:
Start with a PERT Chart to map out your critical path.
Often times I see teams immediately go for GANTT charts or simple work breakdown. That is the wrong approach. Those will not help you visual your dependencies as clearly as a PERT chart.
Once you have your critical path marked out, carry that dependency mapping to your issue management tool and ensure the tickets are marked blocking or dependent on other tickets.
Often times, I have seen great planning fall apart in the development phase because of the lack of discipline in carrying the dependency mapping into the tickets.
Best Tool For Planning: Any mind mapping tool will suffice for PERT chart. Leverage a doc or spreadsheet for task breakdown. Honestly, I prefer and recommend Notion and Coda like tools instead of Spreadsheets. Why? Their write once and view/manipulate/reference infinitely is magical for smooth planning.
Large Projects
Length: 6 months+
Teams Involved: 5+ teams (Engineering, Design, Product, Product Marketing, QA)
Pitfalls: Lengthy projects suffer from two malice: rigidity/clinging to the plan and inadequate resource planning.
Best Approach For Planning: For these types of projects, you will need a number of tools and strategies to build a great plan. Lets start from the top:
Begin with a PERT chart to map out your critical path, dependencies, and hand off points between teams. This is especially important for transition of work between engineering and design.
(If timeline and delivery by date is critical) Leverage a GANTT chart to map out your team resources, dependencies and timeline especially when multiple teams are involved of various stripes and types (engineering vs non-engineering).
Risk Matrix: Separate from the tasks and critical path, you should build a lightweight tracker to track and address risks.
Change Control/Replanning strategy: This can be as simple as heartbeats1 or replanning milestones after a certain number of sprints have passed.
Best Tool For Planning: Mind mapping tools and spreadsheets are your best friend. You know my preference - Notion or Coda like tools.
You probably noticed I didn’t mention a PRD, Requirements Doc or anything of that nature. For any great planning, it is paramount that your requirements are already well understood.
Any planning without clear requirements means you are just building a fantasy and you will lose sight of the end result you are trying to achieve. That is why requirements gathering and documentation is such a key component of any great project planning.
So, before you kick off any planning, make sure the requirements are clear and well understood. If they are not, call out what is still a big question mark and have the planning reflect that uncertainty. Don’t fall into the trap that everything must be figured out before planning begins.
Over time, you as a TPM will need to develop your own gut check of what level of uncertainty is acceptable for planning to get started. You will never have 100% certainty in requirements phase and nor should you wait for it to start planning.
One final word, planning is never easy. It is often an exercise in irrationality masquerading as rational objective thinking. Keep your eyes on the known, unknown, and optimism bias, the rest will sort itself out if you’re focused on the final outcome desired.
Until next time 👋!
-Aadil
P.S.
The versatility of modern design tools like Figma is mind blowing. When you pair this modernity with true and tested methods like PERT charts, you can make magic happen (or at least its magic to me).
So, I built a straightforward light-weight PERT Chart template in Figma.
You can check it out here.
How was this week’s newsletter?
"Before you launch V1, your external deadline is always a little wobbly. There are too many unknown unknowns to write it in stone. So the way you keep everyone moving is by creating strong internal deadlines—heartbeats that your team sets their calendar to: 1. Team heartbeats: Each individual team makes its own rhythm and deadlines for delivering their piece of the puzzle. Then all the teams align for . . . 2. Project heartbeats: These are the moments when different teams sync to make sure the product still makes sense and all the pieces are moving at the right pace. Fig. 3.5.1 Each team has its own rhythm, based on its style, the work it performs, and the needs of the project. Different teams will come together at milestones driven by the project heartbeat, which is primarily driven by the external heartbeat. The best external heartbeats aren’t set by the company but by outside forces—like the holidays or a big conference. A steady project heartbeat is required to make sure the team doesn’t miss any of those critical external deadlines. Matteo Vianello" (Tony Fadell, Build: An Unorthodox Guide to Making Things Worth Making)