user needs vs buisness needs v5a
Post on 14-Sep-2014
1.205 views
DESCRIPTION
TRANSCRIPT
User Requirements vs Business Needs
Mia Horrigan
Manager - IT Advisory Services
Twitter @miahorri #agile #UCD
BA World Aug 2010
My cultural experiences
Slide 2
http://centers.law.nyu.edu/jeanmonnet/images/TL_map-world.jpg
……. what if the culture of your users is different to your own?
Slide 3
http://images.google.com.au/imgres?imgurl=http://www.ourpatch.com.au/system/attachments/0002/1066/Multicultural_Children_Moms.jpg
Unique Culture of the Users
• We are a multicultural society • Cultural impacts may include: family, gender, peer group,
religion, political beliefs etc• I needed to be aware of my attitudes and how they may
impact on service delivery • Understand any cultural issues being experienced by the
users
• I found that if you are congruent and have established rapport, you are in a position to be culturally sensitive and hence to interact effectively with your users.
Slide 4
Situation
• System was required to develop a consolidated reporting tool that would bring together 6 different programs
• An existing system was in place so business proposed to enhance this system to capture the needs of the other 5 programs
• The business needed reports and quickly (hence opting for the existing system)
• The user priority was to deliver services so there was a disconnect.
• The users also had unique cultural issues
Slide 5
The answer to life the universe & everything
Slide 6
• The business had a product solution in mind• This was before the business had engaged with users and stakeholders
The business already had the answer…
The challenge for me was to find out the question
• Business need – web portal reporting tool, already had a solution, wanted me to validate this choice
vs
• User requirement – funding (if they provide reports they get ongoing funding), management tool for service delivery
• Analyse what the users need and want and then determine if the proposed solution aligns to these needs
Slide 7
Was the proposed solution the right one?
Up front analysis as business needed to know what option to go with and asked for our recommendation
• Enhance current reporting tool• GOTS/COTS• Proprietary tools integration• Do nothing – continue with current disparate systems
Slide 8
Business Needs vs User Requirements
• Is it enough to just understand what the business needs out of a project?
• What about system requirements?
• Where does this user fit into this picture of the business and IT landscape?
Slide 9
User engagement is difficult
Slide 10
this project would be great if I didn’t have to deal with users
• Users aren’t a nuance!• They are vitally important to your success• You must take time to understand what they need
• Modern Users are sophisticated (Web 2.0, Gov 2.0)• Have expectation of how applications should work• Don’t just dismiss user’s needs because it is difficult
Slide 11
Unique user issues
• Rural and remote access to community • Varying capability to deliver program reporting across
the services• Difficult to attract skilled personnel to remote areas• Reporting burden (focus was on service delivery)• Cultural and language barriers (English was a second
language)
Slide 12
Rural and remote challenges
Communication • Broadband • Satellite• Mobile network/3G
Slide 13
Photo: Glenn Campbell
The mobile analyst
Slide 14
www.abc.net.au/reslib/200703/r132606_442636.jpg
Geographical • Wet/dry season• Distance • Modes of transport
Our Users were culturally diverse
Slide 15
http://www.cairns.com.au/images/2007/12/06/aboriginal-culture.jpg
Language and terminology
Slide 16
Cultural sensitivities of our Users
• Be respectful of men’s and women’s business when it is occurring in a community
• Ensure that respect and distance is maintained when there is a death in a community
• That should a person die, their name is not to be spoken in front of any other indigenous people
• Minimal footprint approach to local consultation needs to occur
Slide 17
What this meant for our project
Needed to understand
• Mobility of some Indigenous peoples – follow them to new roles to assess the full impact of workforce development strategies
• Maintaining an informal stance to ‘on the ground’ data collection where discussions will be held without technical aids and without the usual formal tools and techniques of interviewing
• Having an understanding of the impact of the wet season and dry conditions on accessibility / travel and individual participation
Slide 18
Analysing users’ problems
• Talked to the community to find out what they wanted• We listened to their stories• Found out about the current process• Looked at reporting needs to provide feedback on funding
projects• Balance need for transparency and accountability with
users practical requirements• Identified where functions could be automated • Looked at options for system (enhance current, new
system, do nothing)
Slide 19
And we used new tools
• We utilised a User Centered design approach
• Up front analysis of requirements however incorporated Agile artefacts
• Used Information Architecture tools and techniques
• Focused on continuous improvement
• Iterated our prototype
• Validated the solution with users
Slide 20
User Centered Approach - Agile
Identify users’ needs
Develop
FeaturesFeatures
Understand context of use
Produce design
solution
Specify user andbusiness
requirements
Evaluate/validate
with users
Features
Prioritised feature
sets
Multidisciplinary team and Product
owner working together
Standards based
ISO13407
Consult Tech Solution Team
regarding options and desired functionality
Slide 21
“Watergile”
Slide 22
Project Management
Nextiteration
Finalise project methodology,
approach and plan
Analyse options and requirements
High Level Business and
System Requirements
IA and Design Workshops and Consultation
Develop Design Solution
Latest version
Refine
Validate solutionIterate prototype/screen concepts
Workshops and Consultation
Briefing and Confirmation of
scope
Technical Specification
Report
Business Process Mapping
Project Plan
Final Project Report
Revised Business Requirements
ReportStakeholder Engagement Plan
Del
iver
able
s
Review previous reports and consultations
Act
iviti
es
Stage 1 Project Plan Stage 2 Requirements Design Stage 3 Technical Specification
Mon 14 Sep 09 Wed 11 Nov 09 Fri 20 Nov 09Wed 30 Sep 09
Develop specification for web portal
Implementation planning
Analysis of data collection and
reporting options
Gap Analsysis
Consultation Briefing report
IA Design Requirements
Fri 30 Oct 09
Phase 1 - Initiate and Rreview Phase 2 - Analyse Phase 3 - Design Phase 4 - Specify Phase 5 -
Report
Consultation Implementation planning
Identify users’ needs
Develop
FeaturesFeatures
Understand context of use
Produce design
solution
Specify user andbusiness
requirements
Evaluate/validate
with users
Features
Agility and responsiveness to Users didn’t mean chaos and scope creep
Slide 23
Agile artefacts to display requirements
Our audience was very visual, so were our artefacts
• Personas - Archetypal users wanted and how they differ in what they require
• Want maps - Key difference and commonalities of wants across the varied stakeholders
• Process maps - Help users through the process, streamline the process and reduce duplication of information
• Prototypes – Look and feel of the system and get see if it is useable and meets needs
Slide 24
Understanding Users - Personas
• Started off with ‘skinny’ view of users gained thru workshops
• Conducted workshops and consultations with users in their community
• Built up personas as we went through our iterations, rather than all-at-once
• Added to personas as info uncovered
Slide 25
The result – ZenAgile Personas
Wants
Communication preferences
Context
Behaviour
Motivations
Slide 26
Personas used to communicate purpose
• Demonstrate understanding of key users
• Told their story through scenarios and explained why they wanted what they wanted from the system
Slide 27
I don’t have time to do reporting
I want a tool to help me manage my program
User Segmentation – What they want
Central office
Really effective tool and point at which we started to see buy in from business as they understood user needs Key
stakeholder want map
State /Territory office
Department
State Department
Slide 28
Want Maps to User Needs
Slide 29
Translator between Users and Business
Slide 30
Business Me User
The different wants
Slide 31
I want reports to assess if program and policy aims are being achieved
Business Me User
I want to deliver services on the ground to help who need them
We should build a web portal
We documented analysis as BPMs
• Focused on what data needed to be captured & when
• And then developed wireframes
ad Maj or / Minor Listing (incl relation to capabilitie s & ucs)
What type ofsubmissionis i t?
Acti vi tyIni ti al
Agree on new / amendedlisting conditions
Register Major / MinorSubmiss ion
PBPA Consideration
(from PBPA Considera tion)
Is there arestriction?
Pricing SecretariatConsideration
High Cost Drugsev aluation
«Sub Process»Finalise Data for
publication
(from Sub Processes)
Is i t a T ier 3subm ission
DUSC High Cost DrugRe-ev aluation
«Sub Process»Pricing section negotiateflow -on listing changes
(from Sub Processe s)
Process Minor Submissions
Submission is ev aluatedby RWG Pre PBAC meeting
Submission is ev aluatedby ESC
Submission is ev aluatedby DUSC
Prepare PBAC Agenda,conduct meeting and
finalise minutes
(from PBAC Consideratio n)
Submission is ev aluatedby RWG
Is Confirmed T ierstatus = T ier 1?
«Sub Process»Pricing QA
(from Sub Processes)
«Broadcast»Add to PBPA Age nda
Is i t a m inorsubm ission?
«Sub Process»High Cost Drugs QA
(from Sub Processes)
Is i t a HighCost Drug?
(from Release 1 Use Cases)
UC29 M anage Committee Agendas
«Broadcast»
Rev ise Prov isional Tier Status
(from Release 1 Use Cases)
UC03 M aintain Submission
«Send»Request PB11a from
client
«Receive»Receiv e PB11a from
clientHas PB11abeenreceived?
«Broadcast»Reference receipt of
PB11a in document list
(from Release 1 Use Cases)
UC19 M aintain Maj or submission document list
HCD section ne gotiateflow -on listing changes
2.10: Abi lity to manage flow-on product changes:
(from Business Requi rements)
2.11: Abili ty to record l isting submission status, (eg draft, ready for export, exported)
(from Business Requiremen ts)
2.12: Abili ty to manage effective dates to control when a change to the PBS i s exported for publ ication
(from Business Requiremen ts)
2.13: Abi lity to record receipt of essential docum entation
(from Business Requi rements)
2.14: Abil ity to record qua lity assurance approval status
(from Busin ess Requi rements)
2.1: Abi li ty to enter and edit submission and li sti ng detail s
(from Business Requi rements)
2.9: Abil ity to record or am end individ ual product prices and perform essential calculatio ns (eg Ex-m an to DPMQ) using correct pri cing mo del
(from Business Requiremen ts)
2.2: Abil i ty to record and amend commi ttee , m embership, meeting and agenda detail s
(from Business Requi rements)
2.3: Abil ity to record PBAC and PBPA recomm endations
(from Business Requi rements)
positive outcomefrom PBAC?
«Broadca st»Reject submission
«Broadcast»Update submission state to Proposed PBPA Secretariat
Acti vi tyFinal
«Broadcast»Update submission state
to Proposed PBAC Secreta riat
«Broadcast»Update s ubmission state to
Finalised
[M inor]
[Yes]
[Yes]
[Yes]
[Yes]
[Yes]
[No]
«reali ze»
[M ajor]
[No]
«reali ze»
«reali ze»
«reali ze»
«real ize»
«reali ze»
«real ize»
«reali ze»
«real ize»
«reali ze»
«reali ze»
«reali ze»
«real ize»
«reali ze»
«reali ze»
«reali ze»
[No]
«reali ze»
«reali ze»
[No]
«reali ze»
«reali ze»
«reali ze»
[No]
[No]
[No]
[Yes]
«reali ze»
[Ye s]
«reali ze»
«reali ze»
Requirements Mgmt System
Slide 32
Wireframes as concepts reflecting understanding of the Requirements
It’s not just about building stuff, its about building stuff better• Requirements and analysis was done up-front
• However…. Our wireframes were driven by the “as is” process.
• This process driven approach didn’t translate into a useable interface - it wasn’t intuitive!
• Need to think about the future state (technology, process and people needs)
Slide 33
Some initial problems…. Using the report form didn’t really relate well to the
user want maps to simplify and streamline
Our scenarios built on the form data capture process
resulted in screens that did not flow well, and lots of
clicks from end to end
Secondary navigation
originally proposed to be hardcoded into each screen
Screen reflected an electronic copy of the previous report form –
little value add
Sequencing was not in line with how the users would work
through providing the information Screens developed
as separate screen concepts without view
of bigger picture usage scenario
Slide 34
What we should have considered
Not just about the process
….or the technology
Its about Users and how they work
..and the context of their work
Slide 35
User scenarios – Story Cards
• Describe usage at a high-level summarising overall usage functionality that actors will have with the system
• The usage scenarios highlight the user requirements as they as expressed as a feature set or story card- As a [USER/PERSONA] - I want to [ACTIVITY] - in order to [OUTCOME]
• These feature sets will then be prioritised by the users during the iterations of development
Slide 36
Feature Sets
Slide 37
As a [User/Persona] I want to [Activity] In order to [Outcome]
CEO
View succinct and meaningful High Level Overviews of Organisational and Business
Understand how my service is tracking on key issues
CEO
Make decisions based on the report information (both quantitative and qualitative information)
Proactively manage my service as a business and respond to issues in my community
Program Manager
Measure and Track Financial Performance of the Departmental Budget and Administered Expenses
Understand the variance in Performance from Budget vs. Forecast vs. Actual and monitor how my agency is tracking against the PBS
Branch Manager
Timely updates of information
(Real time information as information is of no use if it is old or out of date)
Be able to understand trends and track progress and achievements against organisational and business KPIs.
Timing and frequency of information should be based on need for that information
User Needs
Slide 38
User Need
Responsibility Description of User Need
UN-1 System + Business
To produce report on key outcomes, outputs and critical business activity. Information must be relevant and able to be acted upon by the Executive.
UN-2 Business Decreased duplication across reports. It was stated that there are a lot of reports that overlap. Users want rationalisation of reports as it was expressed that the group does not want the executive dashboard to be another report on top of current reporting workload.
UN-3 Business + System
Confidence in the Quality of the data. Data cleansing exercise may be required and business needs to be accountable and take ownership of the data in their area.
UN-4 Business Corporate (Financial and HR) and Business (Program and Payments) information. Situation Report is focused on Programs and based on Ministers’ need - not a comprehensive report for the business. May need more comprehensive Program and Payments level data for Branch and Section Managers. Financial data tracks administered funds but also want to track committed funds.
UN-5 System + Business
Decreased burden of reporting (takes a long time to pull all the information together and there are a number of reports to be complied on a weekly, monthly, quarterly and annual basis. It was stated that at times they struggle with the amount of reporting required. Need to look at how frequently the information needs to be reported on (as sometimes does not change from week to week or month or month).
Tying Features to the Business Benefit
Slide 39
Feature No. Business Benefit (BB) Addresses User Need
Snapshot view of top priorities/issues for FaHCSIA
BB-1
Clarity - Will give clarity of how the organisation is tracking against key outcomes and initiatives that are the current focus. Definable dashboards can show leading/lagging, progress against goals, deviations, exceptions, trending, part-to-whole, geographic/spatial performance, rankings, time series, correlations, distributions etc. (The content of what to include in the top level view can be changed and updated).
UN-1, UN-10, UN-16, UN-20
Uniform presentation format
BB-2
Consistency - Consistent look and feel to reports will aid understanding of how the report works, where data is sourced and when and what it is trying to portray. May aid analysis and interpretation of reports and enable comparison across groups and highlight linkages and correlations across areas and different reports.
UN-9, UN-15
Quality of data input
BB-3
Data Quality and Assurance – business area responsible for the data input and ensuring the information is correct. Accountability and ownership of the data by the appropriate data custodian will increase confidence that the data is correct. (Data Dictionary will help to have a common understanding of data definitions across the organisation).
UN-3, UN-5, UN-17
Information Architecture journey
Slide 40
From wireframes to user interaction
• We knew that wireframes combined with scenarios would be a good way to test concepts and see how the system will work for Users
• Our Wireframes needed to reflect the user needs and how they wanted to interact with the system
• Part of our success was having BAs and IAs working together
• Eventually our Wireframes were not developed in isolation to design principals
Slide 41
We adopted IA Design Principals
Slide 42
Organise information by type of information• Category - Similarity or relatedness. Used when users will
naturally look for information by category • Time - Chronological sequence• Location- Geographic or spatial reference. Used when
info is meaningfully related to geography of a place • Alphabet - Alphabetical sequence • Continuum - Most to least relevant, largest to smallest,
best to worst, etc)
IA Design Principals cont…
• Hierarchy - Simplest way to visualise and understand complexity. Maximise clarity by selectively reveal/conceal
• Progressive disclosure - Only necessary or requested information is displayed at any given time. Prevents information overload and reduces information complexity
• 80/20 rule - A high percentage of a system's use comes from a low percentage of its features and content. Focus on most important features & information and bring to a high level
Slide 43
People think about info in different ways
• Consistency - Comprehensibility is improved when similar parts of the system are expressed in a similar way – ability to learn • Redundancy - Provide multiple ways to reach same information or features• Entry Point - Points of prospect should facilitate rapid orientation. Progressive lures to attract and pull users beyond top level (e.g. news about program and link to full info
Slide 44
Many ways to get to the same info
Slide 45
Reporting system
Screen Concepts to Prototypes
Utilising the story cards and usage scenarios we were able to convert the screen concepts into a prototype reflecting the way users would interact with the system
Branding
Branding
Branding
This is where the business owner and the users really got excited and understood what the system would look and feel like
Slide 46
Prototype helped Business acceptance of requirements
• Easier for business to relate to and understand the user needs
• Able to see the value in responding to the needs - would help gain acceptance and create quick wins
• Presenting Use Case after Use Case, would have missed the mark with this group - too detailed and technical and does not give the same feel for what the users wanted
• Story telling and visual cues very appropriate for this user audience
Slide 47
Compared options
Slide 48
• The User requirements were identified and prioritised
• Business Needs and constraints for system noted
• System options compared to user and business needs
Win/WIN or WIIFM?
Slide 49
http://www.salestrainingconsultants.com/images/upload_images/image/winwin2.jpg
Reporting vs management tool
•x% and variance of health checks
•Comparison to state and national
•Trend over past 12 months
• PIRS data capture & upload
Slide 50
Example only
Visual Display
Slide 51
Appropriate context
Slide 52
Win WinFor the User:
• Reports that I understand. I see value in providing data
• Useful reports that help me decide what to do
• Compare me to communities like me
• I am still the data custodian and can provide context
For Business:
• I have the information to give to executive
• Report provided in one system in the same format
• Quality of data improved
• Extra features for users but meet my needs
Slide 53
Slide 54
What we learnt
• Engage Users to uncover needs - develop feature sets and user scenarios
• Use IA tools and techniques to effectively communicate user needs and benefits
• Concentrate on what users need to efficiently interact with the system to get their work done
• Involve users in validation to increase adoption and buy-in • Understanding Users, their needs and behaviour is critical• It’s not just about the business, It’s about being
responsive to needs of all the Users
Incorporating business & users needs
Understood user needs and wants
Mapped business process
Workshop processes and
user requirements
As a User (Persona)
I want to [Activity] User Need
In order to [Outcome] Bus Benefit
EMG View succinct and meaningful High Level Overviews of Organisational and Business
UN1, UN10
Understand how FaHCSIA is tracking on key issues
BB-1, BB-2
Developed usage scenarios – feature set (story cards)
Iterated improvements to user interface in
prototypes
Feature No. Business Benefit (BB) Addresses User Need
Snapshot view of top priorities/issues for FaHCSIA
BB-1
Clarity - Will give clarity of how the organisation is tracking against key outcomes and initiatives that are the current focus. Definable dashboards can show leading/lagging, progress against goals, deviations, exceptions, trending, part-to-whole, geographic/spatial performance, rankings, time series, correlations, distributions etc. (The content of what to include in the top level view can be changed and updated).
UN-1, UN-10, UN-16, UN-20
Uniform presentation format
BB-2
Consistency - Consistent look and feel to reports will aid understanding of how the report works, where data is sourced and when and what it is trying to portray. May aid analysis and interpretation of reports and enable comparison across groups and highlight linkages and correlations across areas and different reports.
UN-9, UN-15
Quality of data input
BB-3
Data Quality and Assurance – business area responsible for the data input and ensuring the information is correct. Accountability and ownership of the data by the appropriate data custodian will increase confidence that the data is correct. (Data Dictionary will help to have a common understanding of data definitions across the organisation).
UN-3, UN-5, UN-17
Validated prototype with usersTranslated
user needs into features and benefits
Slide 55
Why was this approach successful?
• Business was taken through the requirements development process
• Visual clues showed them what the user experience would be like
• Personas helped them relate to the users and took on a life of their own
• Could see how the design and system would work
• Brought along on the journey
• Story told through the eyes of the users
Slide 56
Thank YouMia Horrigan
Twitter @miahorri
#UCD #user requirements
Blog zenagile.wordpress.com
Email [email protected]
Slide 57
© 2010 PricewaterhouseCoopers. All rights reserved. “PricewaterhouseCoopers” refers to the network of member firms of PricewaterhouseCoopers International Limited, each of which is a separate and independent legal entity. *connectedthinking is a trademark of PricewaterhouseCoopers LLP (US).