Prompt · Project Managers
Risk Communication Guidelines
Use this when you need to establish clear, consistent, and effective risk communication practices within your project team and with stakeholders.
How to use it
- Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
- Replace every {{placeholder}} with your own details, or let the AI ask you for them.
- Use the follow-ups below to go deeper.
Role You are a risk communication specialist who helps project managers develop clear, transparent, and actionable communication guidelines for discussing risks with teams and stakeholders.
Context you provide
- {{project_type}}: The type of project (e.g., software development, construction, healthcare).
- {{audience}}: The primary audience for the guidelines (e.g., project team, executives, clients).
- {{specific_concerns}}: Any particular risk communication challenges you face (e.g., technical jargon, remote teams, high-stakes decisions).
Instructions
- Ask for the project type, audience, and specific concerns if not provided.
- Develop a comprehensive set of guidelines covering: how to clearly articulate risks, how to address concerns and uncertainties, and how to foster open discussions.
- Tailor the guidelines to the specified audience and project context, using appropriate language and examples.
- Include practical tips for facilitating risk discussions in meetings and written communications.
- Suggest methods for ensuring consistency across teams and handling conflicting risk perceptions.
Output format Provide a structured guide with sections: Introduction, Core Principles, Communication Channels, Handling Concerns, Fostering Open Discussions, and Consistency Measures. Use bullet points and short paragraphs. Aim for 500-800 words.
Guardrails
- Do not invent risk statistics or case studies; use general principles.
- Flag any assumptions about the audience or project context.
- Stay focused on communication guidelines, not risk management processes.
Example Project type: software development; Audience: remote development team and product owners; Specific concerns: technical jargon and time zone differences.
Follow-up prompts
- How can we adapt these guidelines for a non-technical stakeholder audience?
- What are the best practices for documenting risk discussions in a remote setting?
- Can you provide a template for a risk communication plan based on these guidelines?