In the past, my presentation of business level requirements has involved walking the business through the 80 pages of UML use cases and watching them glaze over after 10 minutes. I wanted them to understand what they were signing off on but this was not the right way to present the material to my audience. I was finishing up a project recently and was asked to present our teams' findings, requirements specification and design to the director group.
My project was to develop a consolidated reporting tool that would bring together six different program data sets. So I took a user centered design approach to developing the business requirements and incorporated a lot of the information architecture tools and techniques I had learned on projects over the least three years.
I started with face-to-face consultations and workshopped the needs and wants of the service users who were required to supply reports. I also talked to internal users who would analyze and summarize the reports for the branch's policy decision makers. We decided to use user stories and personas, want maps and process maps to present our findings about what the users really wanted and then used the site map and a prototype to show how the system would look and feel.
The presentation went extremely well as the directors were taken through the process and had the visual clues to show them what the user experience would be. So why was this presentation approach successful? I think it was because my BA documentation tends to be very visual, as I find that my audience likes to see how the design and the system will work, and need to be brought along the journey. In a recent presentation I told the story through the eyes of the users and found this was a very effective way to present my deliverables.
Here are my top five tips for presenting requirements and deliverables:
1. Establish and Communicate the Purpose. On my project, the service users clearly wanted a system that would help them manage and plan their day-to-day service business, not just a tool to use for reporting back to the funding branch. I presented our findings from the stakeholder consultations and then presented the six personas to demonstrate our understanding of these six key user groups. I told their story by presenting user scenarios and explained why they wanted what they wanted from the system. My key message was that the system users wanted a management tool, not a reporting tool. By clearly presenting this purpose and demonstrating through personas and user stories, the directors understood that this change would mean a win/win at implementation time as the burden of data entry for services would be lessened if there was something in it for them - namely useful management reports.
2. Use Visual Artifacts to Display Requirements and Design. The personas were a very powerful tool to show what the archetypal users of the system wanted and how the groups differed in what they required. We displayed the primary, secondary and tertiary user needs in a want map and this helped to show the key differences and commonalities of wants across the varied stakeholders. The process maps showed how the different groups would interact with the system and how we would help them through the process, streamline the process and reduce duplication of information. The prototype helped to show how automation and integration of data would decrease data entry burden and also capture information that could be used to aid their management and planning.
By presenting deliverables as user scenarios and showing the findings through use of personas and want maps, the directors were able to see the value in responding to the needs of the services as this would, in the long run, gain acceptance and quick wins for the system implementation. Walking this audience through use case after use case would have missed the mark with this group, as it would have been too detailed and technical and would not have given them the same feel for the concept of what the users wanted.
3. Understand your Audience. My presentation was aimed at the business users, and I needed to understand their needs so I could tailor my presentation to meet their needs. I needed to understand who the key players were? Who were the influencers and decision makers? What did they want from this system? What were the relationships between the different stakeholders? This was difficult as it was a short project (only 10 weeks) and I had little direct contact with some of the key players. Therefore, I worked closely with my business product owner to ensure he saw the deliverables in progress and had a chance to comment prior to their being presented to the directors and executives. I sought his guidance on how to handle the meeting; the dynamics of the stakeholders involved, and walked him through the key messages. This preparation meant that I could frame the deliverables in a way that would hit the mark for this audience.
4. Understand the Business Context. Presenting to an audience when you don't understand their business does not end well for the presenter. In conveying understanding of requirements for the business and users, I believe it is important to know the business context. I did my research and preparation before the meeting and asked myself:
- What are the key drivers for this change?
- What processes are involved?
- What are the internal or external environmental constraints or opportunities out there for this group?
Once you know the context, demonstrate that you understand the business needs and vision. Then demonstrate how your solution will meet that need.
5. No Surprises. In the past I have been reluctant to show my work in progress, as I wanted it near completion before sharing it (as the "Virgo" perfectionist in me wanted to make sure it was right!). In working on Agile projects in recent times, I have embraced this skinny solution concept and am now comfortable starting with a skinny version, and fleshing it out as the work progresses. When I had finished a piece of thinking about users, processes or design, I would share these artifacts with the core project team, the key business product owner and then refine. This iterative approach helped my target audience to get a feel for what the deliverable would look like and meant that, when it was being presented, it was not a new concept, just a more refined and validated version of what they had seen earlier. Remember that you are presenting your requirements design solution, not telling a joke, so sending material out beforehand as pre reading will not "spoil the punch line". If you feel people may miss the point of your deliverable without you there to narrate, then allow for their questions at the end rather than taking questions throughout the presentation.
Don't forget to leave your comments below
Maria Horrigan is an experienced business manager, IT strategic planner and information and communications specialist. She has over 10 years senior management experience within the pharmaceutical industry, not-for-profit and Government. As a principal consultant, Maria is an experienced information architect, senior business analyst and IT strategic analyst and provides advice on developing system requirements with a focus on information architecture and user-centred design, to ensure appropriate IT systems are intuitive and usable. She is a senior practitioner and a well-known Australian speaker on communication, user-centred design, and business analysis. She has experience managing large federal government contracts and project management of large scale business system implementation, systems planning, and analysis and change management. She has a reputation for innovation, managing change, driving strategy implementation and successfully delivering programs. Maria is a Board member and Vice President of Women in Information and Communication (WIC).
Subscribe to this comment's feed
written by Geoff, January 12, 2010
I liked your approach, as I am pushing our BA's here to start down a similar path.
-
- +2
-
-
written by Benito Agbulos, January 12, 2010
As a perfectionist myself, I prefer presenting my requirements when their complete. But your view on #5 is an eye opener. I'll try that on my next project. Thanks heaps!
-
- +1
-
-
written by Nima Evans, January 12, 2010
For some time I believed use case diagrams were useful, but again, they are entertaining for the business audience at best (funny stick figures doing important things for the business) ... and when they are so, they become meaningless for the techies!
I believe if a diagramming technique is not very intuitive (like mind maps, or activity diagrams) they should be discarded!
For some time I believed use case diagrams were useful, but again, they are entertaining for the business audience at best... and when they are so, they become meaningless for the techies!
I believe if a diagramming technique is not very intuitive (like mind maps, or activity diagrams) they should be discarded!
-
- -2
-
-
written by Paul Mulvey, January 13, 2010
(1) Diagrams that are correct but lose the audience are not effective. You need to provide a process diagram that users can understand - that is the most effective. When users (or SMEs) understand the diagram and can validate that it meets their needs, or they understand how the future TO BE implementation will work, is the most successful.
(2) Just like we used to do in math class, you need to show your work. Seeing a fellow BA or SME tear apart a diagram that you were proud of may hurt inside, but if it didn't correctly state the process, the changes are actually going to improve the final product (and I'm a Virgo too, so I understand the "perfectionist" thing).
Good ideas, thanks, Maria.
-
- +1
-
-
written by Santanu Ray, January 14, 2010
Thanks and regards,
Santanu.
-
- +2
-
-
written by Rob Verboom, January 14, 2010
(btw Eddie Obeng has writen a great liitle book on this "Perfect Projects")
-
- +0
-
-
written by Nupur, January 21, 2010
I'm practicing Business Analyst in Pharma and recently in a project where the Vendor is having tremendous hold due to his business partnership with the Company the project is getting shifted to yellow border, creating extended project lines and black-outs in terms of design and build for IT user
As a Business Analyst what are your thoughts and what a Business Analyst can do to make this situation better?
I'm also looking forward to learn more on tools and techniques which BA are using at different levels. Can you provide any site or links or insight to this?
Thanks and regards,
Nupur Banerjee
-
- +1
-
-
written by Pieter, January 28, 2010
This hits very close to home. I'm in the process of documenting reporting requirements for a web-based real time IVR solution. The best so far in ensuring we've captured all requirements, was the creating of the prototyping screens. Having a visual solution forces everyone to make sure they understand and confirm their requirements.
Regards,
Pieter
-
- +0
-
-
written by Karen Duke, January 28, 2010
Thanks!
-
- +1
-
-
written by Robert Kagel, February 02, 2010
-
- +0
-
-
written by Simon Robinson, February 04, 2010
-
- +0
-
-
written by Mohsin Dar, February 08, 2010
-
- +0
-
-
written by Erin Andrews, February 08, 2010
-
- -1
-
-
written by Landon Miller, March 10, 2010
http://magia3e.wordpress.com/2010/03/06/user-requirements-tools-want-maps/
Pleaase note that the article contains an embedded link, below the Persona example, to a dead Flickr page...
Hope this helps,
Landon
-
- +0
-
-
written by rozzmurri, April 28, 2010
--------------------------------
http://www.lindy.co.uk/cables/audio-video/hdmi/
http://www.lindy.co.uk/cables/usb/
-
- +1
-
-
written by Lettie Eshabarr, May 04, 2010
-
- +0
-
-
Click Here to login or create a free account.
Thanks for the tips. I am not familiar with a "want map." Do you have any examples or resources that I could use to learn more about this? Is it like a mind map?