1. HIMS Case July, 2001 Group Modeling of IT ‑ Based Innovations in the Public Sector Anthony Cresswell Theresa Pardo Center for Technology in Governement David Andersen Luis Luna Ignacio Martinez George Richardson Rockefeller College

2. 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).

3. 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).

4. 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).

5. 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/).

6. Project Context

7. 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.

8. 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.

9. Group Model Building Time Line Jan/2001 Modeling group starts talking with potential participants – Paper proposal Mar/13/2001First project scoping meeting Mar/20/2001 Second project scoping meeting with CTG’s team Mar/29/2001 Meeting with modeling group – HIMS project selected / session scheduled Apr/13/2001First modeling session May/08/2001Second modeling session

10. Effort Distribution of the Modeling Support Team TaskEffort (Man*hour) Managing Collaboration15 Concept Model20 Planning Meetings15 Facilitation32 Modeling45 Writing Reports20 Gatekeeping8 Total155

11. Effort Distribution of the Modeling Support Team

12. Effort Distribution of the CTG Team TaskEffort (Man*hour) First project scope meeting2 Second project scope meeting16 Meeting with modeling team10 First modeling session20 Second modeling session20 Total68

13. 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)

14. First Modeling Session

15. Pre-meeting Activities Create Script (Richardson and Andersen, 1995) –Roles in the GMB sessions FacilitatorAndersen Modeler/ReflectorRichardson Process Coach Richardson RecorderLuna/Martinez GatekeeperCresswell Get CTG approval Create Concept Model –Luna and Martinez Complete logistics

16. 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:20BREAK 10:30·Stock mapping ·Feedback loop mapping ·Modeler Feedback ·Next steps and future tasks

17. Modelling Group David AndersenRockefeller College Donna CanestraroCenter for Technology in Government Meghan CookCenter for Technology in Government Anthony CresswellCenter for Technology in Government Luis LunaRockefeller College Ignacio MartinezRockefeller College Theresa PardoCenter for Technology in Government George RichardsonRockefeller College Fiona ThompsonCenter for Technology in Government

18. 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

19. 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

20. Concept Model

29. Key Variables Elicitation

30. Reference Modes

31. Boundary Clarification (Original image redrawn in Word)

32. Structure Elicitation (Original image redrawn in Vensim)

37. Reflector Feedback

38. Inter-session Modeling Activities

39. Model Sectors

40. Multi-stage process

41. Single-stage process

42. Second Modeling Session

43. Agenda

44. Structure Elicitation

45. Reflector Feedback

46. Model

47. Team Experiments

48. Team Discussion

49. Reflector Feedback

55. 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)

56. Known problems No way to solve problems “Epidemic” nature of committed units (all or nothing) Satisfaction never takes off Parameter issues