SDs team/task force

[MOHD IZHAN MOHD YUSOF]

To SD Community,

Hello again. I hope that you are not becoming bored with my queries...

First of all I would like to say THANK YOU SO MUCH to those who answer
my queries; and I hope that (when I fully confident in/graduated from
this field, that is SD) I could do the same to those who in need of my
help.

When I read through your replies, I couldnt help but notice that some
of you have established a team/task force to solve problem(s) using SD.

My questions are:

1. How do you come about in setting up the team/task force?

2. Is there any particular criteria
ules/philosophy you have to follow
to set up a team/task force?

I hope you can share your experience since Im in the process of setting
up one. Thank you and hope to hear from you real soon.

Mohd Izhan Mohd Yusoff
(izhan@rnd.tm.com.my)

[Robert Glitz]

Greetings,

when we set up our teams, we looked mainly for subject matter experts
(SME), who were: highly experienced, well respected by peers for their
professional knowledge, good communicators, and had access to senior
leaders. The only SD training that we provided was "Just Right"
training (the appropriate level/section of SD training, just before we
used those tools.)

In addition, we had other roles assigned:
- Executive Sponsor: usually not fully involved in the project, but
kicked it off and received the interim and final reports.
- Gatekeeper/Project Manager: (thats me.) I chose SME team members,
arranged for meeting times/place, logistics, provided advocacy briefings
to "whoever", and gave high level guidance and direction to the project
(gentle nudges). I also managed the contractor team and the project
funding. All the stuff to start the team and keep it going. (Like
bugging the contractor constantly for documentation...)
- Expert SD modeler: We contracted this. This role built the model,
wrote the equations, handled the software (Powersim, in this case.), all
the SD hard stuff.
- Facilitator: An expert in group dynamics, meeting sequences, team
building, group facilitation, etc... all the human stuff.
- Technologist: We used electronic group decision systems, both
locally and over the Internet. Someone had to keep the servers up and
running. For us, this person also served as deputy SD modeler.
- Large Group Specialist(s): in our case, since we wanted to
communicate model findings/dynamics to a larger audience, we used people
skilled in large group facilitation models such as Future Search and
Real Time Strategic Change. (Optional for most.)
- Outside experts: to keep the team going with new ideas, we
occasionally brought in speakers from various disciplines. (also
Optional).

Id be interested to see if anyone has identified other roles. Any
ideas out there?

Good luck on your project.

Robert Glitz, LtCol, USAF
rglitz@erols.com

[Robert Glitz]

Jim Hines wrote:

> An effective team size might be six to eight. If more people are
> interested you might set up a couple of levels in the team: The Team
> includes everyone, the "core" includes the most interested six or eight
> people who meet most frequently. (Incidentally, one way to handle a
> manager from the unfortunate 10-20% who have trouble with SD, is to move
> him or her from the core team to the Team).
>
> The core team should meet if possible every week. The Team could meet
> once a month.

We have had teams of 6-8 in size and, recently, a team of 35, as well as
different sizes in between. With the 35 person group, we did alot of
work in sub-groups, by assigning portions of the modeling effort. The
subgroups then reconvened as a large group and critiqued each others
work. We built a Powersim model of about 800 elements using this larger
team. Over the course of three months, they met three times for three
days each time. In the interim, we used meeting/brainstorming software
over the WWW to continue feeding info/insights to the modeler. We also
used groupware during the physical meeting. It seems to help alot with
larger groups.

There are advantages and disadvantages to both size extremes. With the
smaller group, you can get some very deep insights, but you have to be
very careful about choosing team members and, Ive found, its harder for
the group to communicate their efforts to outsiders. The larger groups
tend to "cast a wider net" that maybe isnt as deep, but now you have a
small army of different viewpoints and skills to go out and sell the
model.

RJ Glitz, LtCol, USAF
rglitz@erols.com

[jimhines@interserv.com]

On Fri, 24 Jan 1997, Robert Glitz <rglitz@erols.com> wrote:

>We have had teams of 6-8 in size and, recently, a team of 35, as well as
>different sizes in between. With the 35 person group, we did alot of
>work in sub-groups, by assigning portions of the modeling effort.

Did each sub-group have its own modeler, or was there a single modeler/modeling
team for the entire effort? How large was each subgroup? Did you have to
divide the model up into sectors in order to assign a "portion" to each
subgroup?

>There are advantages and disadvantages [to different sized groups]. The larger
> groups tend to "cast a wider net" ... now you have a
>small army of different viewpoints and skills to go out and sell the
>model.

Sounds like a significant advantage.

Regards,
Jim Hines
jimhines@interserv.com

[Robert Glitz]

jimhines@interserv.com wrote:
> Did each sub-group have its own modeler, or was there a single modeler/modeling
> team for the entire effort? How large was each subgroup? Did you have to
> divide the model up into sectors in order to assign a "portion" to each
> subgroup?

Jim,

We divided the larger group up into three teams of around 10 or so. On
our contractor/support team we had one expert modeler, one "apprentice"
modeler, and several facilitators trained in system dynamics. We spread
out the talent between the groups as best we could, with the expert
assigning tasks and monitoring (as best he could) the different efforts.

Usually we would give different tasks on differing model portions to the
different subgroups. However, on particularly complex or emotional
issues we would have the three subgroups work on the same problem and
then converge the viewpoints/learnings in the large group session. The
groupware helped here.

Our process involved working the group(s) to harvest their knowledge as
much as possible, performing the actual modeling off line, presenting
results back to the group, and then reiterating the process. This works
pretty well, because we can work on picking up and shaping much of the
"soft" info while the expert modeler grinds away, turning it into a
"hard" model. (of course, after a three day - and evening - session, he
needs a vacation! This particular contractor, GDSS, Inc., is picking up
so much SD business, that I think theyre hiring some more modelers....)

regards,

rj glitz, ltcol, usaf
rglitz@erols.com

[Jim Hines]

In reply to the question regarding teams, here are my thoughts -- Id
like to hear other peoples.

For a company team for a system dynamics project, I think its wise to
look for

1) People who have a hands on knowledge of the issue area under
consideration. You need people who know what the physics of the system
is (e.g. who ships to whom) and who know how decisions are made. For
example if you are focussed on pricing, have people who actually set
prices on the team. Staff people, unless they come from a relevant line
position, do not in general have the required knowledge. Sometimes,
very senior people also lack the required knowledge, because they are
too far removed from the day to day operations to know how things are
actually done.

2) People who have decision making authority concering the issue being
addressed. If people on the team can make the decision (or have
significant influence over the decision), the team will need to do less
selling of the solution. It can be frustrating for the team if they
come to a conclusion, but cannot do anything about it.

3) People who can take a top-down approach to problems. In my
experience, about 10-20% of managers have difficulty getting benefit out
of participating in a system dynamics effort. These managers can
considerably slow the process. It would be nice if you could just say
these managers are neanderthals or idiots. But, thats not the case.
They can be effective managers, well respected in the organization, and
very nice folks. One characteristic that I think some of these managers
share is that they are focussed on the detail and have trouble
aggregating. For example, you might ask what is the average life of
plant equipment and they will say, that thats a complicated question.
A spanner pump will last up to two years, though they sometimes fail
after 8 months. A jefferson valve, on the other hand; if its installed
correctly, can last for five years.

4) People with an interest in system dynamics. This is not necessary;
but it sure makes the project more fun if the people are interested in
the approach as well as in the "answer".

An effective team size might be six to eight. If more people are
interested you might set up a couple of levels in the team: The Team
includes everyone, the "core" includes the most interested six or eight
people who meet most frequently. (Incidentally, one way to handle a
manager from the unfortunate 10-20% who have trouble with SD, is to move
him or her from the core team to the Team).

The core team should meet if possible every week. The Team could meet
once a month.

Regards,
Jim Hines
jimhines@interserv.com

[PKucera@aol.com]

As SD practitioner interest grows in bringing the benefits of SD to
organizations, some have chosen to involve increasingly large groups of
people in the modeling process. In these instances, then perhaps the
process (and associated large number of roles and responsibilities) suggested
by Bob Glitz et. al. may be appropriate. Contractor management, on this
scale, certainly adds a layer of complexity.

But lest some subscribers to this forum fear that such massive
infrastructures are required in most cases, I feel its important to
recognize that the value of ST within organizations can be realized with far
less overhead.

I have been associated with successful "large" projects (both within HPS and
elsewhere) that have involved only three to eight content experts or process
owners and one to two experienced facilitators/ modelers. We used the ST
language to surface/ challenge/ understand/ change assumptions about "the
system." Then, effective use of interface functionality within the ithinkr
software (and runtime versions of the application) enabled the team to
communicate and disseminate across the organization, the insights gained by
the team. In at least one case, the reach was to over one thousand employees
located around the globe.

While it is true that "buy in" *can* be secured by involving lots and lots of
people in the model building, its not automatic just by virtue of the
involvement. A "too many cooks in the THIS IS SPAM" dynamic may get rolling to
defeat the sought-after buy in, if not kept in check by a large process and
roles infrastructure.

Managing expectations is a real challenge with large groups. For example,
just by virtue of asking for input, you run the risk of creating an
expectation that the solicited input will find its way into the model being
built. I have seen this lead to excessively large models that dont really
uncover dynamic complexity, but rather are mired in detail complexity. The
difficulty of filtering what should be in/out of the model, relative to the
stated purpose of the modeling effort, grows dramatically as the size of the
modeling team expands.

If the model and associated interface are developed to create deeper
understanding of: 1) a compelling need for change; 2) what is achievable
in a future state, and; 3) how to orchestrate decisions over time to get
there, then the odds of successfully changing the way an organization thinks
about an issue (or itself) goes up. I have seen this done with a small cast
of characters and effective use of the ithink software to engender dialogue
and enable broad communication.

We all know that this stuff is not cookbook and that there is no one "right"
way to do it. I just wanted to surface an alternative to the one currently
being discussed.

Cheers,

Paul Kucera
High Performance Systems, Inc.
PKucera@aol.com