1. Practices for Involving Stakeholders
PLEASE SIT IN TEAMS
September 2009
Arlene W. Williams
Marshall School of Business
University of Southern California
Intro: doing ongoing research on improving ISD productivity.
Introduce the clients – ask them to raise their hand. . .
Warn: the following team-projects should stay in OHE 122:
Team 1 – project 19
3-21, 5-7, 8-2, 9-18, 11-1, 12-5, 14-13, 15-4, 16-20, 17-22
These team-projects should go to GFS106:
2-9, 4-8, 6-17, 7-6, 10-15, 13-16, 18

2. Purpose
To inform you of practices for involving stakeholders (clients & developers) in a “collaborative learning process” to achieve innovative business-IT solutions
Define what “clients” and “developers” are.

3. What is “Collaborative Learning”?
This is Collaborative
Learning
This is Knowledge Transfer
or Individual Learning:
Business
Side IT
Side
Business
Side IT
Side
Emphasize “between clients and developers.”
increases the odds that they will trust each other’s suggestions; come up with new ideas for solving business problems e.g. electric utility dividing billing cycle into thirty days, rather than print all – and thereby tax printers, system -- in one day. See which aspects of problem are best solved by an information system (vs. non IS solutions) Implement the prototype (or system), because critical issues and stakeholders' needs were addressed
Together, learning new ways of
structuring IT and business
processes
Involving Stakeholders

4. Why Worry about Collaborative Learning?
Lost Opportunities in:
Business
Innovation
(new services,
products)
Business
Effectiveness
(better)
Business
Efficiencies
(faster,cheaper)
Involving Stakeholders

5. Findings from Local SW development firms
High Learning Stakeholders
Low Learning Stakeholders
Average use of Collaborative Learning Techniques
4.5
1.2
Involving Stakeholders

6. Practices for Encouraging Collaborative Learning
I. Creating Shared Responsibility
II. Importance of Creative Friction
III. Elaboration to Help Resolve Creative Friction
Emphasize “between client and developers.” Three critical factors: coord norms, effective meeting management, and reconciling and managing differences
Involving Stakeholders

7. I. Shared Responsibility
What is it? It is the psychological attitude that “we’re all on the same team”; “we’re in this together”
In treatment, go fast on these slides…

8. Practices for Encouraging Shared Responsibility:
When Managing Stakeholder Relationships
Help to make ALL stakeholders part of development team:
Put on distribution list
Include in teleconferences
Frequent interactions, even if brief
Identify tasks that developer and client can work on together
Use “we” not “I” during discussions
Identify team-based rewards (such as lunches)
Define project success metric as system use, not just system development
Involving Stakeholders

9. Practices for Encouraging Shared Responsibility
when Project Starts
1) Identify a learning facilitator
2) Identify learning objectives for each stakeholder:
- Client organization’s work process?
- IS development process?
- Technology developments?
- Use of IS in business?
3) Identify & Assign development tasks related to each learning objective
4) End each meeting with assessment of learning
PRACTICE NOW

10. Practices for Encouraging Collaborative Learning
I. Creating Shared Responsibility
II. Optimize creative friction to achieve learning
III. Elaboration
Emphasize “between client and developers.” Three critical factors: coord norms, effective meeting management, and reconciling and managing differences
Involving Stakeholders

11. Problems with Many Teams
Participants’ creativity not engaged
Look for solution that creates quick consensus
Unwilling to confront others with different ideas
Politeness takes precedence
INSTEAD:
Sources: Facts (from miscommunication or from your backgrounds – users are not typically very technical and developers are not very well versed in business) – cure with deeper probing, clarification. Objectives (explicit and hidden) – sometimes true objectives are hidden, e.g. get an A for the course. Commitment (non-compliance) – some parties are just more committed than others. Because of differences in power (acquiesence, non-assertiveness, passive acceptance), differences hard to be surfaced. You can’t tell a boss you disagree too often: ain’t good for your health. But you have a difference. Culture – always blamed for breakdowns. Stereotypes like “Asians are shy” etc. Beliefs, which are often irreconcilable. Differences of opinion WILL occur. At least know there is a difference, and start from that point. Work around the difference.
An example difference is: clients might be more concerned with getting a simple prototype that can easily be implemented into a final system while developers might be interested in creating a technically elegant solution.
Elicit from the class on how differences might be manifest.
Then…the presentation forks from the placebo in the “recognize they exist” point.
Recognizing that differences of opinions exist; understanding why the differences relate back to goals (is it the goals were not as well-understood). This is harder than you might think. You'll need Cognitive Elaboration tools to explore this.
Differences of opinion WILL occur.
An example difference is: clients might be more concerned with getting a simple prototype that can easily be implemented into a final system while developers might be interested in creating a technically elegant solution. If you are lucky, differences will emerge as disagreements, If you are not so lucky, they may appear in the guise of miscommunication, conflict over some other issue, failure to comply with agreements, silent treatment, sarcasm, acquiescence. Once differences are identified, we need to understand them (using the techniques already identified in the previous section) Some differences can be managed just with better communication techniques. Other differences are more fundamental. If the communication techniques already identified don't eliminate client/developer differences, then it is necessary to negotiate a mutually acceptable solution.
Let's give an example of a possible area of disagreement: Every time Dvlprs talk about the interface between the database and the prototype application being designed, client shows a lack of interest (but doesn't say anything) and then asks them about alternative user interfaces. Dvlprs feel the UI is simple and irrelevant to the key problem, which they believe to be the DB design. So, this shows a disagreement over where to spend limited time: Team feels need to resolve how to make the DB interface work; Client wants to see more alternatives for user interface. So what do you do? First, you acknowledge that there is a disagreement: "every time we talk about DB design, you show a lack of interest; are you more interested in the UI design?" If based on this public acknowledgement, client confirms that there is a disagreement, move to next step (which is to figure out how to resolve it)
Don’t assume that an initial no-diff between client-dvlpr will hold. Search for underlying or less apparent diffs.
Innovation
Creative Friction
Involving Stakeholders

12. Exercise: Identify potential areas of creative tension
Let Client describe his/her idea
Students start questioning client’s assumptions
Client should start questioning students’ assumptions
Identify one area of creative tension
Involving Stakeholders

13. Practices for Encouraging Collaborative Learning
I. Creating Shared Responsibility
II. Identify potential areas of Creative Friction
III. Elaboration
Emphasize “between client and developers.” Three critical factors: coord norms, effective meeting management, and reconciling and managing differences
Involving Stakeholders

14. Keep Creative Ideas Flowing
Quickly create & discard lo-tech prototypes to explore concepts (not as status assessments)
Role play use of prototype in alternative to-be work processes
Stimulate creative discussions with:
“What would happen if…?”
“Had you thought about …?”
“If we did X, what would happen?”
“What are strengths & weaknesses of…?”
9/13/2004
Involving Stakeholders

15. Involving Stakeholders
Active Listening
Ask about unstated reactions to idea
Switch roles
Avoid talking too much
Restate what you heard
Build on the client’s examples & ideas
9/13/2004
Involving Stakeholders

16. Elaboration Process TRY IT NOW Focus on Actual Work Processes
Not looking for hypothetical ideal (Don’t say: “users “USUALLY” do X”)
Immediately co-create prototype of how work done now or in future.
Observe how client WALKS THROUGH using prototype to make DECISIONS
Note client’s decisions, work arounds, process
Give client opportunity to explain actions
Student now role plays prototype
9/13/2004
TRY IT NOW

17. Ex Difference in Practices: Individual vs Collaborative
Use prototypes for single solution
Enforce single representation of knowledge (“ERD”)
Explain own knowledge
Talk
Stay in role
Use prototypes to explore different concepts
Represent knowledge in different ways
Have others explain your knowledge
Draw, listen, ask questions
Reverse roles
Involving Stakeholders

18. Checklist during meetings
Did you?
Use prototypes to explore concepts?
Let clients develop prototypes
Create “test-drivable” prototypes?
Make sure client asked as many questions as you did?
Stimulate creativity through questioning?
Restate dialogue to improve understanding?
Use examples from more than one work context?
Avoid using IT-language?
Involving Stakeholders

19. Checklist during meetings (Cont)
Did you:
Use visual examples to explain concepts?
Reversed roles?
Tried more than one way to represent how work is done?
Elaborated on client’s idea?
Grounded ideas in client’s physical world with a role play by sharing stories of how work is done?
Asked about client’s unstated reactions to an idea?
Did you show any IS’s that client might want to emulate?
Involving Stakeholders

20. Involving Stakeholders
Summary
Every client-developer encounter is an opportunity for learning
Every client and developer learns differently
Controlling the learning process is better than leaving it uncontrolled
Control it by:
Building and maintaining a sense of shared responsibility for outcomes
Use elaboration techniques
Manage conflict for learning
by “surfacing” assumed (implicit but often misunderstood) norms, agendas (hidden or otherwise), and differences (ranging from pure misconceptions/misinformation to true irreconcilable differences), we set a positive tone for problem-solving and moving forward.
In addition to surfacing, clients and developers must share some responsibility and make an effort to learn from each other. Such sharing and mutual learning helps generate creative alternatives, which in turn leads to successful outcomes.
Involving Stakeholders

21. Thank you!