Collaborating with developers

Bring the decision, not the entire archive

Identify the project stage and the choice that is blocking progress. Describe who owns that choice, what has already been tested and which constraints are fixed. A short summary of the current business case is more useful initially than a large collection of drawings with no explanation of what the team needs.

Separate assumptions from dependencies

Consider a hypothetical project whose schedule assumes infrastructure will be ready before construction begins. The business question is not simply whether the schedule looks reasonable. It is who can verify that dependency, when confirmation is needed and what happens to carrying costs if it slips. That distinction helps direct specialist work without pretending to replace it.

• List assumptions that would change the decision.
• Identify the professional or authority needed to verify each dependency.

Define a complementary work product

A proposed collaboration could produce an options memo, a responsibility matrix or a decision agenda for the existing team. The agreement should identify whose analysis will be used and how disagreements will be recorded. A business review should not silently expand into construction management, design coordination or authority to direct contractors.

Protect existing roles

Explain sponsor responsibilities, adviser relationships and any limits on sharing information before exchanging detailed files. No partnership interest, financing access or project outcome is implied by a conversation. Commercial terms and responsibilities require mutual agreement. If a bounded second perspective would help, describe the decision and the intended recipient of the work product in your inquiry.