Wiki contents

Journals

2019 Learning journals
2018 Learning journals
2015 Learning journals
2014 Learning journals
2013 Learning journals

Smartsims Support Centre

Blog updates

Recently Updated

Recent updates

Recently Updated

All updates

Skip to end of metadata
Go to start of metadata

In a quest for greater transparency, this page explains some of the decisions that were made in designing this course. If there are other areas that you think would benefit from some explication, please suggest them.

You may not agree with some of the rationales presented here, but over time and for most students, they have been found to be efficacious. 

Due dates

When you look at the Due dates and at the To Do checklist, you will notice that most (if not all) of the deliverables are due during normal 'business hours'. Many of us, myself included, tend to work up to deadlines. If an assignment is due at midnight, many people–perhaps even most–will work on the assignment until the last moment; i.e., they will work until midnight. So, to try and foster some better sense of work/life balance, due dates have been set to help you set good boundaries and patterns of work.

Of course, if you prefer to work late into the night on assignments, then you can ... but you will need to do that at least one evening before before the deliverable is due.

Nevertheless, you need to take responsibility for your own time management. The deadlines between deliverables tend to make it impractical or meaningless to accept deliverables after their due date. You need to allow enough 'wiggle room' in your planning to handle things going wrong or not working. 

Ambiguity

As in life, there is a degree of ambiguity present in this course.  As highlighted by the BCom Graduate profile you are expected to be able to cope with a reasonable amount of ambiguity. There is a fine line that we try and walk between giving you the answers and helping you work out (and learn how to work our) reasonable (and even good) solutions to the challenges that you will face during the course. 

Yet, some people will chafe at the ambiguity present in the course. 

One source of ambiguity is down to the creativity (or even unpredictability) of students. Sometimes, we are faced with situations that we never thought would happen and we have to find a sensible way through which can seem like an arbitrary decision on our part, and be taken by some as evidence of ambiguity. For example, collusion. I remember the first time we encountered teams colluding to 'divide and share' markets (e.g., "If you let us do racers we won't do kids bikes"). Because we did not specifically say anywhere that collusion was not allowed, some students thought it should be okay. But we decided to transfer the principle from the real world that the Commerce Commission would not allow anti-competitive behaviour and would (and could) inflict penalities. Therefore, we enpaneled a 'Commerce Commission' comprising of some of the CEOs and a commercial lawyer to adjudicate on the situation (and, as it happened, to award penalties on those firms that colluded together). Just as in the real world, ignorance of the law is not a defense, the principle in our world of MikesBikes was that the laws of the land would also apply there too. There have been other instances .... theft, industrial sabotage, and so on are perhaps extreme examples of 'ambiguity' arising in MikesBikes.

The instructor's role

In many ways the instructor's role is similar to that of any reasonable manager working in a knowledge intensive business. They cannot micro-manage everyone. They can give general guidance and respond to requests for help. They will usually manage 'by exception', when things seem to be not working the way they should. They provide a moderate level of feedback.

MikesBikes

The simulation was chosen for many reasons; yes, it was developed by a former faculty member out of his research at Yale, but that was not the prime reason for its selection. The main reason is that the simulation is sufficiently complex that it requires a team of people with effective 'division of labour' (aka team work) to effectively run a MikesBikes company. Some of the staff at SmartSims (whom number a few alumni of this course) have–over many years–developed deep understandings of the simulation and can effectively compete when running a company by themselves. But for most folk, to do well they need to find ways to work well together. The second reason is the complexity of the simulation goes a long way towards mirroring a real firm; more so than many business simulations. As a consequence, many of the business lessons (on top of the team lessons) are transferable to the workplace.

Peer feedback

 You will notice that peer feedback is used extensively throughout the course. For example, it is used with the Learning journals. Some students question the value of such feedback. Surely an 'expert' will give better feedback? There are three reasons why peer feedback is used here. First, when you give peer feedback, it sets you up to think critically about the work of others–it is a great opportunity for you to learn from your colleagues. How often do you  get the chance to see and think about other peoples' work? Secondly, it helps you develop skills in evaluating your own work ... how can you get better if you always need someone else to tell you how good a job you have done. Finally, all the research says that it works. Yes, sometimes a student will 'blow off' the task (and there are consequences for that), and yes, sometimes they might be wrong. But that happens far less frequently than you might think, and in practice it rarely a problem. Overall, the benefits of peer feedback far outweigh the occasional problems.

  • No labels