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