What do you do if your product engineering project has multiple dependencies?

Use workarounds and make solution assumptions to navigate forward. Monitor assumptions and validate frequently. Readjust in case certain assumptions are found to be wrong. Validating assumptions early in the cycle would be key to reduce rework. Communicate clearly and collaborate with key stakeholders and have fair representation from the key role based on RACI Matrix.

Begin by identifying dependencies early in your project during the planning phase. This includes dependencies on external teams, third-party vendors, APIs, libraries, or internal resources. Document these dependencies and prioritize them based on their criticality to project success.

Process mapping is an important part of any product engineering projects that are complex and has multiple stakeholders and therefore, multiple dependencies. The process can be perceived differently by the different stakeholders and not given the same prioritization. By mapping dependencies (of the process) the entire team can level set and come together and collaborate to a greater degree. In my experience, this step is skipped in the corporate organization recently due to the increased scrutiny on cost and by skipping this step, it usually cost the organization more because important interactions or touchpoints are missed. It's time to re-focus on mapping discrepancies.

List down the tasks, prioritize them, and also drive the action items against the identified tasks. Marking the priority can depend on various factors like business or stakeholder expectations.

Task prioritization is very important as higher priority tasks need to be attended to first before lower priority tasks according to Dr. John DeMartini. In the organizational context the opposite is true. Most orgs go after the low hanging fruit versus the high priority tasks. As this starts to be shifted from low priority tasks to high priority tasks, productivity & engagement will increase and alignment to core values will be more clearly seen for all team members. Filtering this philosophy into practice is something that requires change management and can be integrated into the workings of the organization. If your organization does not have this functionality, it can be easily referenced in organizational change forums like ProSci.

Prioritize each dependency based on: Business impact Resource requirement Target delivery Associated dependencies (parallel vs. sequential)

I often quote Frank Lloyd Wright when it comes to requirements and dependencies -- "You can use an eraser on the drafting table or a sledgehammer on the construction site." Each new floor of a skyscraper depends on every floor supporting it below. Similarly with software you need to understand what must be built first, what can be built in parallel and dropped in place, and what cannot begin until other blockers are addressed. A detailed project plan needs to map the sequence, timing, and level of effort across every role for each task.

Establish internal communication channels Establish external communication channels Establish communication schedule Initiate communication Adjust channels, schedule, and content based on impact and feedback

One of the fundamental aspects of quality communication is excellent documentation easily available to all contributors and stakeholders. There are four key areas to evaluate the effectiveness of documentation and this is how I rank them. Good Documentation: (is) Clear, (is) Correct, (provides) Value, and (is) Current. If it’s not clear, you can’t tell if it is correct. ? If it isn’t correct, you can’t tell if it provides value.? If it provides value, it must be kept current. ? If it isn’t current, then why do you have it?

Avoid single points of failure, have a backup plan/resource strategy, and don't assign 100% of anyone's time. For a long running project you may want to allocate resources at 80% capacity so that you can accommodate planned and unplanned PTO, "work overhead" like trainings & team meetings, and the unexpected. You never know if the third party you depend on will complete their API on time and you can't plan for someone to spill coffee on their laptop. If you are working with a fixed budget always notify your stakeholders the instant you think you might have a budget overrun and determine if the project needs to be re-scoped or if existing tasks can be re-priortized to a future phase.

When your product engineering project has multiple dependencies, continuous monitoring of progress is essential. The agile tenet of transparency aligns with The Three Pillars of Empiricism: Transparency, Inspection, and Adaptation. Monitoring progress isn’t about micromanaging; it's about spotting opportunities to adapt and improve. By regularly tracking the completion of tasks and their interdependencies, you can identify blockers and impediments early, preventing a death-by-a-thousand-cuts scenario. In complex projects with many dependencies, consistent monitoring helps you adapt, iterate, and ultimately keep the project moving forward.

A robust project plan should incorporate parallel work streams. Are there areas where team members can surge if you are blocked because a third party didn't complete their API on time? Can you quickly mock out your own version of the API? You will always have blockers, the key is to make everyone on the team feel comfortable raising their hand when they need help so that you minimize thrashing and prevent burn out.

Develop good relationships with the teams with whom there are dependencies. It seems like a no brainer. But, when stakes are high and tense flare up, it helps to have friendly relationships to help each other out and ease the situation, to meet the targets with each other's support.

There's an old quote that says "if you fail to plan, you plan to fail." Any complex engineering project requires a certain amount of upfront discovery, analysis, and task scoping. If you jump ahead of the scoping process and dive right into implementation you are more likely to burn more hours and cause more team stress than if you take the time to plan it out carefully. Carpenters follow the analogy of "measure twice, cut once" but in software there's a tendency to cut, cut again, and then file it down to fit. There's a reason the tortoise beat the hare.