How to communicate Requirements to Stakeholders

Do you believe the best business analysts are top flight communicators?

But how do you communicate requirements effectively? We are challenged with limited time and access to stakeholders during which we communicate.

Sometimes stakeholders are disengaged, confused or just plain bored. How can we get their attention and get quality feedback to ensure we deliver the highest quality requirements?

This webinar discusses communication of requirements to stakeholders. Major focuses of this webinar are how to produce requirements that satisfy both business and development expectation, how to communicate requirements to stakeholders in an effective way without providing more information than necessary, as well as how to handle remote users and clients.
  • How do you communicate requirements to stakeholders?
  • How do you balance communicating the requirements so they are understood against providing too much information?
  • How to draw the line between enough documentation and too much documentation?
  • Any advice communicating to Field Operations audience -in, say, the Resource Dev Sector?
  • Is there one size fits all? No place for specification?
  • Can you create one document that you can pull sections out depending on audience?
  • How do you balance the apparent chasm created when trying to produce requirements that meet both business and developer expectations?
  • Is there a way that the same Requirements could be structured for Business, Development and QA, without been separated?
  • How do we strike a balance between having concise requirements that are easy to understand vs. spelling out all details?
  • How do I get stakeholders involved or interested?
  • How can get a quick and thorough feedback of my mock-ups from stakeholders, what's the best way to keep them interested?
  • How do we strike a balance between having concise requirements that are easy to understand vs. spelling out all details?
  • What approach should I take to convince stakeholders to look at better ways than what they are used to?
  • How to handle remote users?
  • How to capture requirements and learn to say no to a client? How do you handle conflicting requirements between groups of stakeholders?
  • Stakeholders often do not know what their requirements are or should be. To what extent can the BA lead them with suggestions?
  • How do you get the stakeholders to stop waffling and to decide on what they want in order to nail down requirements?
  • How do you make users own the requirements?
  • How do you prioritize requirements with stakeholders?
  • Using user's language or "reschape" into unambiguous statements and in doing so also define business concepts?
  • When your company CEO is your customer, how to lock business requirement with them?
  • Sign-off. Is there any point. If the users sign off a doc that isn't fit for purpose, does it really protect you?


Penny Pullan

The majority of my work is with people in multinational organisations who are grappling with tricky projects and programmes of change. Tricky usually means a combination of:

  • risky, with uncertain outcomes;
  • working with virtual team members dispersed around the globe;
  • complex and often ambiguous requirements;
  • complex and often culturally diverse mix of stakeholders, who need to be interested, engaged and involved.

With this context, people say I bring order and clarity, providing support and tools to cut through the problems and to emerge successful, delivering benefits at the same time as developing the individuals involved.

I am very interested in leadership in tricky change, especially without much line management authority. My facilitation skills are fundamental to my work. I am a director of Making Projects Work Ltd. I am delighted to co-author ‘A Short Guide to Risk Management’ with Ruth Murray-Webster and co-edit ‘Business Analysis and Leadership’ with James Archer.

I’ve worked with programmes as wide ranging as running virtual summits and professional groups, certification of child labour in West African countries, supporting people who make insulin all over the world to work virtually effectively, the global implementation of SAP, introducing project techniques in the not-for-profit sector as well as ‘Project Management Excellence” training

Andrew Kendall

Andrew is a senior business analyst with over 20 years’ experience of working in the financial services sector. Having worked both in Australia and Europe, his clients include Insurance Australia Group, Marsh & McLennan, Lloyds of London, Barclays and Lloyds TSB.

Andrew’s Volere project experience includes producing specifications for a Pan European Client portal and developing concepts used in financial crime and fraud management tools. He has also worked extensively on eBusiness applications within the sector and brings with him a wealth of knowledge ranging from large internet banking and insurance programmes to smaller localised projects.

Andrew holds an MBA from the Graduate School of Business at the University of Technology, Sydney, (UTS) with a major in strategic information technology. He also holds a Diploma in Marketing Management. He is a member of the UTS Alumni and a member of the Australian Institute of Management and the International Institute of Business Analysts.

Kent J McDonald

Kent J. McDonald helps organizations improve the effectiveness of their projects. His more than 15 years of experience include work in business analysis, strategic planning, project management, and product development in a variety of industries including financial services, health insurance, performance marketing, human services, nonprofit, and automotive. He is co-author of Stand Back and Deliver: Accelerating Business Agility, is currently Agile Practice Lead for B2T Training, and shares his thoughts on project effectiveness at

Get a 60-day free trial of the Professional Functionality
Try every feature, add unlimited users, no credit card required