What Performance Are You Needing to Simulate? And What Enables or Distracts From That?

And does that need to involve a computer? What role does a computer – other than in development of – play in the Simulation? And can I avoid using Computers in Simulations in Learning? Or is that what Simulations means in the Training/ Learning/ Knowledge Management worlds today?

The 1987 Desktop/Tabletop Gameboard and “Breaks Cards” in the above graphic – as in “those are the Breaks” – where both good (1/3) and bad (2/3) – were used in an extensive 5-part (note the 5-sided game board) exercise where 5 teams of 2 kept switching team roles after each meeting – including their own as Product Managers for one of 5 products – in Product Team Meeting simulations that they 1st prepared for, then ran, and then documented the meeting results, in updates to their PRODUCT PLAN Presentation template.

They ran through 5 Phases of our made-up Product Management life cycle: 1- Concept, 2- Justification, 3- Realization, 4- Growth & Maturity, and 5-Decline & Discontinuance.

They ran through those 5 Phases, dealing with tasks and issues typical of each phase 5 times, for 5 products: 1- Camera, 2- Recorder, 3- Editing Deck, 4- Cables & Connectors, and 5- Video Tape. Near the end they decided that they weren’t just 5 product families, that they were a system – and interdependent and in need of cross-product coordination and Planning.

They played their assigned roles, sitting and talking “from the shoes of the PM (Product Management organization) or from the shoes of some other typical team members,” bringing their typical needs and issues to the table, as for each Product they played the same role 5 times, of: 1- Product Management team leader, 2- Engineering team member, 3- Manufacturing Engineering/Management team member, 4- Sales Management team member, 5- Service Management team member.

Each of those team represented more than the title implied/indicated, for there are many more team involved such as: HR, Training, Finance, Distribution (Shipping & Warehousing), Materials, Purchasing, Contracting, Marketing, etc., etc., etc.

Back to how the computer might have been used back in 1987 or today in a Simulation Exercise designed to do what this one was designed to do.

Back in the day – this ran 31 times between the fall of 1987 and the Pilot-Test, to 1994, including 5 times in The Netherlands – the Simulation teams prepared for their roles for the next meeting, meeting by meeting, by reading the appropriate tab in DATA PAKs that were handed out for their preparation to play their assigned role in this next meeting.

So they could read that on their computers – before going in to the next Product Team Meeting for the designated Product and in their designated role. That would save a lot of paper and labor. And the computer could also deliver “The Breaks Cards” that the PM drew after landing on those spots (Uncle Wiggly style if you know what I mean) and then handed that Breaks Card off to whomever it affected – and then the Meeting started – as the team member (or PM) dealt at the last minute with Breaks – changes in the data that they just reviewed!  Talk about authenticity!

Again, one third were good breaks such as Sales Support lowers their support costs forecasts by 15% per unit to-be sold. A bad Break might be: Manufacturing Accounting raises the Cost-of-Goods 25% due to current activity in the precious metals markets globally. There were 48 Cards in each Deck – and one deck for each Phase of the Life Cycle. Think Monopoly and Community Chest cards.

But I wouldn’t want to use the computers for delivery of this data.

The focus wasn’t on one’s computer prowess, although using Excel for financial planning is where I would incorporate using laptops in the classroom. The focus was on running Product Team Meetings dealing with certain typical/standard tasks – and also dealing with the “Monkey Wrenches” thrown into the typical process via the DATA PACKs and/or The Breaks Cards.

I wanted the DATA PAKS as a place to highlight wheat from chaff – as the data provided was sometimes not informative to the task at hand. It was just relevant seeming data. Trainees either really hated that or really liked the authenticity of that aspect of our training event’s Simulation Exercise.

DATA PAKS were structured the same way for each player:

1- Letter from the PM about the next meeting’s agenda, goals, etc. – This “set up everyone” and was the same for everyone.

2- Memo from My Boss – unique to each of the 5 roles. This set up agreements with the plan or differences and rationale for differences. Politics comes in through this door too.

3- Memo from some group that I represent. Points of view, again in agreement or in disagreement (with rationale) with the general flow of this product in this part of the life cycle. Politics rears its head here too.

4- Memo from some group I represent – or from my own team members. More of the same as done in #3.

5- Notes to Myself – is where we provided final guidance to each team member (pair of 2) as to which side they should take, which tact they should take in the flow of issues and agreements/disagreements and how hard to push back…such as fight and never agree, or fight and then capitulate if such-and-such happens or is agreed to. This is where we reinforced several of the key learning interwoven throughout the 8 days (yes 8 days) if this ILT.

More about the key learning planned and designed into this series of lessons that included INFOs, DEMOs and APPOs: Most of the APPOs (Application Exercises in PACT-Speak) were centered on these 25 Product Team meetings – where one led 5 of them and then participated in 20 others (whew!).

One of the key learning s was to learn how to run these meetings with representatives of other parts of the organization – and not get snowed or buffaloed as one might put it politely – by others in their typical fashion. And another objective was to learn how one change to one thing then bounced around these functions changing their numbers – necessitating a need to take another data snapshot and produce an update plan with updated financials and team member plans – what was Sales and Sales Support now going to do with the extra funding to make sure that they make their new Sales Goal numbers?

Seeing that from many angles of the perspectives of their team members gave new insights to veterans and rookies alike. They learned to do less fighting about the numbers they were given routinely and dug to understand the numbers and to help that team member, a representative of another part of the organization with different goals and metrics, understand the implications of their numbers to the overall team’s plan, the Product Plan.

This gave new Product Planners (in the Product Management organization) an advanced organizer for each phase of the life cycle that their product went thorough, was in, or was going to be in at some point.

Life cycles time spans varied tremendously – and that itself was a lesson for some. For others it was that components and sub-assemblies themselves was where the real flux was. The camera evolved through the life cycle incrementally – and then at the end was being displaced by a totally new model – which was really not true, as there were shared parts from the old Camera – and that was a lesson as well. Ramping down part of your operations while ramping up new operations was tricky, and changed the Cost-of-Goods-Sold up and down, causing their “forecasted” MOI (their particular target name – which varies enterprise by enterprise enough to be watchful for it) to also go up and down.

MOI was the ultimate measure. Both after the fact (The Actuals) and before, during the forecasting (of The Plan) to make the decision at each “Gate Review Meeting” to continue with the Product, or not.

Or more realistically, which numbers were of issue in missing MOI, and what needed to be focused on and addressed. Lower costs and thus lower prices and/or increased profits (MOI)? Increased Sales forecasts to make it up in volume? Improved marketing and training of the Sales Force? Additional Features in the next cycle?


And again, the role of computers in a Simulation Exercise such as this, are secondary, and could be distracting from the key learning goals. Let them crunch their numbers on their laptops.

But I’d keep the DATA PAKs and The Breaks Cards off of their computers (unless we were doing this via conference calls which would be more authentic) as I don’t want future attendees to be able to read up and get so tight with memorizing THOSE facts and data presented in the current delivery vehicles. Those are just fodder to learn how to deal with issues and people (playing roles with authenticity) in a Product Team meeting.

They were then – and they would be now.

Too many computers and too much time spent on them would force too much attention away from dealing with people and their issues and dealing with all of that team interconnectivity, communications and coordination needed.

There was no right answer for each Product at each Phase in the life cycle. The Breaks Cards made sure of that. That variability was introduced because a couple of members of the Project Steering Team guiding this effort for my client, thought that there should be.

They wanted the focus on the end Product. The Financials (Plan and Actual). My immediate client and I agreed that the focus was on learning as much as possible, formally via the content introduced in our DATA PAKs and the INFOs and DEMOs of the ILT, and whatever the other 9 people in the Product Team Meeting might introduce as they played their roles and brought both fact and fiction into the Simulation Product Team Meetings. That helped me address their Adult Learner need to contribute and build on what they already know – and in this case would incorporate into the fictitious Product Line of VIDCOM, the case company.

Oh – and we did show everyone the Voting Form at the very beginning of the SIMULATION EXERCISE they would use as this ILT wound down – to encourage them to role play as actors asked to bring some of their personal experience to their character. Most did. When we asked someone in the DATA PAK to be hostile for example – and to run off a list of complaints that their organization has, and then they really did that in the meeting and were out of character from what everyone saw of them before that portion of the ILT class began – we knew we had some actors in our group. Especially as we had experienced PMs in each class, besides the rookies, and they could really bring their own frustrations with the “noise” that they typically hear from Engineering, Manufacturing, Sales and Services into this – so well in fact, so real that sometimes we had to ask them to “tone down the realism man. It’s scaring some of the rookies. ”

The Simulation I designed for this and built (I wrote all of the DATA PAKs – all 25) was “authentic enough.”

It was not real work – where we would get distracted by the work and less by the learning that has happening. It wasn’t real products and the real world details of the number of pages of advertising to be bought over the next planning period and at what average cost?

It was about dealing with issues and facts at a high level – meaning less details, more broad categories and numbers. To help recognize how feature additions throughout the life cycle cost and pay back, how training and development for introduction is one thing and feature upgrades another. How the more features the more sales thinks it can get per unit, but selling less units as price elasticity hits some not-so-sweet-spot.

And the focus was on how to get your team on board with the decisions and their implications, and then revisiting that by changing some variables…well at this lower price how many units are you willing to commit to sell? And at that many units what will our unit Cost be, Manufacturing.

Stuff like that. Less on how to use the Intranet and Internet as a resource, and more on how to collaborate with your Product Team members and both anticipate and deal with issues typical of each Phase of the life cycle. Dealing with people and numbers.

So I think you could run this without computers except for the financial data crunching. Although their is something to be said, I think, for forcing them to “do the math” – keep it simple – but have them “do the math” to internalize it better.

# # #

One comment on “What Performance Are You Needing to Simulate? And What Enables or Distracts From That?

  1. Pingback: Performance Models Should Drive Simulation Exercises « EPPIC – Pursuing Performance

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.