Embed Size (px)
Citation preview
HIMS CaseJuly, 2001
Group Modeling of IT‑Based Innovationsin the Public Sector
Anthony Cresswell
Theresa Pardo
Center for Technology in Governement
David Andersen
Luis Luna
Ignacio Martinez
George Richardson
Rockefeller College
Group Modeling at Albany
• The modeling group at the University at Albany has more than 15 years working with techniques for building computer models directly with groups (Mumpower et al, 1998; Richardson et al, 1992; Rohrbaugh, 1992; Schuman and Rohrbaugh, 1991).
Group Modeling at Albany
• These techniques have been used to construct system dynamic models (Richardson and Andersen, 1995 and 1997; Rohrbaugh, 2000).
• The work in group model building (GMB) at Albany links to other efforts in the field (Vennix, 1996).
Group Modeling at Albany
• Five different roles (Richardson and Andersen, 1995):– Facilitator, modeler/reflector, process coach,
recorder and gatekeeper.
• The modeling team has worked in a set of scripts (Andersen and Richardson, 1997).
Group Modeling at Albany
• This paper documents the procedures used and products created for a small scale GMB effort using the approaches developed at Albany.
• The paper reports on tasks completed over a four-month period in 2001.
• A web site provides complete documentation of all the products developed in the GMB sessions (http://www.albany.edu/cpr/sdgroup/HIMS/).
Homeless Information Management System (HIMS)
• HIMS purpose was to develop a new management information system that would assist the Bureau of Housing Services (State of New York) and state-funded homeless shelter providers better assess programs.
• The operation and regulation of homeless shelters is a multi-government, inter-organizational operation.
Homeless Information Management System (HIMS)
• The field research on this project was connected with the activities of the Center for Technology in Government (CTG) with the New York State Office of Temporary and Disability Assistance, Bureau of Housing Services (BHS).
• Over a 2+year period, the project participants were able to achieve the necessary collaboration and share highly detailed and complex operational knowledge. The result was the design and development of a successful prototype information system.
Group Model Building Time Line
Jan/2001Modeling group starts talking with potential participants – Paper proposal
Mar/13/2001 First project scoping meeting
Mar/20/2001Second project scoping meeting with CTG’s team
Mar/29/2001Meeting with modeling group – HIMS project selected / session scheduled
Apr/13/2001 First modeling session
May/08/2001 Second modeling session
Effort Distribution of the Modeling Support Team
Task Effort (Man*hour)
Managing Collaboration 15
Concept Model 20
Planning Meetings 15
Facilitation 32
Modeling 45
Writing Reports 20
Gatekeeping 8
Total 155
Effort Distribution of the Modeling Support Team
Managing Collaboration
10%
Concept Model13%
Planning Meetings10%
Facilitation21%
Modeling28%
Writing Reports13%
Gatekeeping5%
Effort Distribution of the CTG Team
Task Effort (Man*hour)
First project scope meeting 2
Second project scope meeting 16
Meeting with modeling team 10
First modeling session 20
Second modeling session 20
Total 68
Project Products
• Concept model
• Script for the modeling sessions
• Agenda for the modeling sessions
• Minutes for the sessions
• Preliminary model – Trust1
• Model – Trust2 (In process)
• Model Documentation (In process)
Pre-meeting Activities
• Create Script (Richardson and Andersen, 1995)– Roles in the GMB sessions
• Facilitator Andersen• Modeler/Reflector Richardson• Process Coach Richardson• Recorder Luna/Martinez• Gatekeeper Cresswell
• Get CTG approval• Create Concept Model
– Luna and Martinez
• Complete logistics
Agenda
8:30 · Review Agenda for the day· Purpose, discussion and clarification· Concept Model: a fast overview of final product· Boundary Clarification – stakeholders, actors, sectors in the model, key variable (especially stocks) elicitation, key variables and the reference mode
10:20 BREAK 10:30 · Stock mapping
· Feedback loop mapping· Modeler Feedback· Next steps and future tasks
Modelling Group
David Andersen Rockefeller College
Donna Canestraro Center for Technology in Government
Meghan Cook Center for Technology in Government
Anthony Cresswell Center for Technology in Government
Luis Luna Rockefeller College
Ignacio Martinez Rockefeller College
Theresa Pardo Center for Technology in Government
George Richardson Rockefeller College
Fiona Thompson Center for Technology in Government
Hopes• Product of value for both
teams• Make a model that works
Understand the key variables that made BHS a successful project
• This is useful to CTG• Understand how feedback
SD models work• To be able to use this
experience to think about our projects using different lens
• This is useful KDI• Hope that we can narrow
the variables to a manageable size, so that it is a somewhat straightforward model
• New insights into HIMS• There is humor in today• That it works so well that
we can use it to explore the other projects as well
Fears• Ability to talk in SD
terms• It won’t be applicable
to us, only to you• Too hard for us• That my own biases
will cloud its outcome• This is a waste of time• Too hard
• That I won’t get it• CTG do not have enough
detailed data about BHS• Talk, talk, talk and not get
anywhere• Have lunch• Too little time to get to the
good stuff• Not understanding or
being shown what happens behind the curtain
Concept Model
Tasks to doFinished
workProgress rate
People
People on project
Peopleproductivity
Fraction of peopleassigned to project
TrustTrust building
rateTrust erosion
Trust built per taskaccomplished
Time for trust tobreak down
Concept ModelProject and Trust Progress
600
450
300
150
0
0 10 20 30 40 50 60 70 80 90 100Time (Day)
Tasks to do : Final1 TaskFinished work : Final1 TaskTrust : Final1 Task
Concept Model
Tasks to doFinished
workProgress rate
People
People on project
Peopleproductivity
Fraction of peopleassigned to project
Projectdefinition
Fractionremaining
TrustTrust building
rateTrust erosion
Trust built per taskaccomplished
Time for trust tobreak down
Effect of trust overproductivity
R
B
Project and Trust Progress
600
450
300
150
0
0 18 36 53 71Time (Day)
Tasks to do : Trust Normal TaskFinished work : Trust Normal TaskTrust : Trust Normal Task
Concept Model
Tasks to doFinished
workProgress rate
People
People on project
Peopleproductivity
Fraction of peopleassigned to project
Projectdefinition
Fractionremaining
TrustTrust building
rateTrust erosion
Trust built per taskaccomplished
Time for trust tobreak down
Effect of trust overproductivity
R
Concept Model
Project and Trust Progress
600
450
300
150
0
0 10 20 30 40 50 60 70 80 90 100Time (Day)
Tasks to do : Normal TaskFinished work : Normal TaskTrust : Normal Task
Concept Model
Structure Elicitation(Original image redrawn in Vensim)
Feasibleprototype
components
Commonunderstanding ofwhat and how
componentgrowth
CTG involvement
Use of SMARTIT tools
Structure Elicitation(Original image redrawn in Vensim)
Feasibleprototype
components
Commonunderstanding ofwhat and how
Collaboration
Capacity tocollaborate
Willingness tocollaborate
Trust
LeadershipProvider
Engagement
componentgrowth
Responsibiliy forcollaboration
CTG involvement
Use of SMARTIT tools
Structure Elicitation(Original image redrawn in Vensim)
Feasibleprototype
components
Commonunderstanding ofwhat and how
ExpectationsDemonstrated
results
Collaboration
Capacity tocollaborate
Willingness tocollaborate
Trust
LeadershipProvider
Engagement
Personal priorexperience
componentgrowth
Responsibiliy forcollaboration
CTG involvement
Opportunity to act
Use of SMARTIT tools
Pressure to beaccountable
Welfare reformpressure
Bob activity
Structure Elicitation(Original image redrawn in Vensim)
Feasibleprototype
components
Commonunderstanding ofwhat and how
ExpectationsDemonstrated
results
Collaboration
Capacity tocollaborate
Willingness tocollaborate
Trust
LeadershipProvider
Engagement
Personal priorexperience
componentgrowth
Responsibiliy forcollaboration
CTG involvement
Bob usednegative
experience
Opportunity to act
Use of SMARTIT tools
BHS and QAengagement
Role ofcorporate
partner
Pressure to beaccountable
Welfare reformpressure
Bob activity
Structure Elicitation(Original image redrawn in Vensim)
Feasibleprototype
components
Commonunderstanding ofwhat and how
ExpectationsDemonstrated
results
Collaboration
Capacity tocollaborate
Willingness tocollaborate
Trust
LeadershipProvider
Engagement
Personal priorexperience
componentgrowth
Responsibiliy forcollaboration
CTG involvement
Bob usednegative
experience
Opportunity to act
Use of SMARTIT tools
BHS and QAengagement
Role ofcorporate
partner
Pressure to beaccountable
Welfare reformpressure
Bob activity
Multi-stage process
Prototypecomponents
Commonunderstanding ofwhat and how
Developingprototype
components
Systemdevelopment
Developingcomponents
Developingcommon
understanding
SystemimplementationImplementing
Single-stage process
FeasibleComponents
Unsolvedproblems
Unsolved problemgeneration
Progress rate
Productivity
Unsolved problemsper component
Projectdefinition
Perceived progressfraction
People on projectdevelopment
Average unsolvedproblems percomponent
Structure Elicitation
Feasibleprototype
components
Commonunderstanding ofwhat and how
ExpectationsDemonstrated
results
Collaboration
Capacity tocollaborate
Willingness tocollaborate
Trust
LeadershipProvider
Engagement
Personal priorexperience
componentgrowth
Responsibiliy forcollaboration
CTG involvement
Bob usednegative
experience
Opportunity to act
Use of SMARTIT tools
BHS and QAengagement
Role ofcorporate
partner
Pressure to beaccountable
Welfare reformpressure
Bob activity
Reflector Feedback
Uncommittedproviders
Committedproviders
Gainingcommitment
Loss ofcommitment
Involvement ofproviders
Involvement of theState (BHS, QA)
Involvement ofCTG
PerceivedPotential
Perceivedthreat
Level ofcommitment
of thecommittedBuilding Eroding
Positive word ofmouth
+
+
-
+
+
++
+ +
R1
Collaboration
FeasiblePrototype
Components
++
+
+
Perceivedvalidity of
the process
Satisfaction indemostrated results
Positive priorexpectations
(process)
Negativeexpectations
(process)
+
+-+
+
+
+
+R2
+/-
+/-
-
+ +
CommonUnderstanding
Vision
Opportunity/pressureto actInfeasible
PrototypeComponents- +
+
+
+
-+
+
+
+
Trust
Involvement ofCorporate Partner
+
ModelFeasible
Components
Unsolvedproblems
Unsolved problemgeneration
Progress rate
Satisfaction indemonstrated results
Productivity
Unsolved problemsper component
Projectdefinition
Perceived progressfraction
People on projectdevelopment
CommittedprovidersGaining
commitmentLossing
commitment
Provider totalpopulation
Engagement ofcommittedprovidersBuilding Eroding
Fraction of providerscommitted
Time for commitmentto break down
CollaborationBHS and QAengagement
Total CTG effort
CTG effort onCollaboration
Fraction of CTG efforton collaboration
Availableproviders effort
Indicated stateengagement
CTG Effort onproject tasks
Effect of collaboration onUnresolved Components
Effect of Collaborationon Productivity
Willingness to adjustworkforce
Average unsolvedproblems percomponent
Effect of averageproblems onsatisfaction
PerceivedPotential
Positive word ofmouth effect
Average commitmentper provider
Saturation effect
Contacts
Maximum effort perprovider
Indicatedengagement
Available people
Engaging
Time to perceivepotential
Effect of CTG efforton collaboration
CTG Effort onresponsibility of
collaboration
Effect of responsibility ofcollaboration on contacts
Weight onresponsibility
Effect of responsibility ofcollaboration on time to
commitment to break down
Available StateEffort
Potential StateEffort
Potential providereffort
Team Experiments
Project
800 People*Hour/Month2 Dmnl
100 People200 Component
4 Unsolved problem/Component
0 People*Hour/Month0 Dmnl0 People0 Component2 Unsolved problem/Component
5 5 5 55
44
44
4
3 3 3 33
2 2 2 2 2
2
11
1
1
1
1
0 4 8 12 16 20 24 28Time (Month)
Available State Effort : Base People*Hour/Month1 1 1 1Collaboration : Base Dmnl2 2 2 2 2 2 2Committed providers : Base People3 3 3 3 3 3Feasible Components : Base Component4 4 4 4 4 4Average unsolved problems per component : Base Unsolved problem/Component5 5
Project
800 People*Hour/Month0.04 Dmnl
1 People200 Component
4 Unsolved problem/Component
0 People*Hour/Month0 Dmnl0 People0 Component2 Unsolved problem/Component
5 5 5 5 5
4 44
4
4
3
33 3 3
22
2
2
2
2
11
1
1
1
1
0 7 14 21 28 35 42 49 56 63Time (Month)
Available State Effort : NoCTG People*Hour/Month1 1 1 1Collaboration : NoCTG Dmnl2 2 2 2 2 2 2Committed providers : NoCTG People3 3 3 3 3Feasible Components : NoCTG Component4 4 4 4 4 4Average unsolved problems per component : NoCTG Unsolved problem/Component5 5
Future Directions
• Fix known problems• Add to providers capacity to learn (2)• Explore how CTG allocates effort dynamically• Expand to multi-phase view• Elaborate inputs to effects of and from
collaboration (1)• Elaborate trust dynamics (1)• Capture feedback insights from the work (1)
Known problems
• No way to solve problems
• “Epidemic” nature of committed units (all or nothing)
• Satisfaction never takes off
• Parameter issues
