Not just students, but this is a common failure in large engineering projects. There are often FAR too few “glue” and “end-to-end” responsibilities tracked and assigned, so the people who care about the end result aren’t engineers actually doing stuff (many managers and execs are former engineers, but have somehow forgotten how things actually get built).
The most common solution is project managers. Companies hate to pay these “extra” employees not actually producing code/designs/output, and classes almost never acknowledge their existence, let alone the necessity. But good ones really pull their weight in coordination and identification of mismatches.
There is probably no way to “do better at coordination while dealing with normal peers and while only doing a fair amount of work.” Either do more work (of a different type than the class is based on), accept the pain and bad results, or find/force another student to do that coordination work. In the real world, in good companies, results get noticed and lead to better personal outcomes—not everyone is equal, and “fair” doesn’t matter much. In school, you’re kind of screwed.
Though there ARE some things you can do—extra work and coordinating/cajoling people, but often effective and feasible. Start with integration. Get the end-to-end WORKING MOCKUP going with hardcoded behaviors in each module, but working interfaces. This is often half or more of the work, and there’s no way to avoid it—doing it at the end is painful and often fails. Doing it up front is painful but actually leads to completion. You may learn some things in this phase that make you split up the work differently. Depending on size and duration of the project, that may be fixable with different division, or may just be “I’ll try to help once I’ve finished my part”.
I do believe that projects in general often fail due to lack of glue responsibilities, but didn’t want to generalize too much in what I wrote.
Start with integration. Get the end-to-end WORKING MOCKUP going with hardcoded behaviors in each module, but working interfaces. This is often half or more of the work, and there’s no way to avoid it—doing it at the end is painful and often fails. Doing it up front is painful but actually leads to completion.
Being able to convince everyone to put in the time to do this upfront is already a challenge :/ Sometimes I feel quite hopeless?/sad? in that I couldn’t realistically make some coordination techniques work because of everyone’s difference of goals and hidden motivations, or the large upfront cost in building a new consensus away from the Schelling point of normal university projects.
Not just students, but this is a common failure in large engineering projects. There are often FAR too few “glue” and “end-to-end” responsibilities tracked and assigned, so the people who care about the end result aren’t engineers actually doing stuff (many managers and execs are former engineers, but have somehow forgotten how things actually get built).
The most common solution is project managers. Companies hate to pay these “extra” employees not actually producing code/designs/output, and classes almost never acknowledge their existence, let alone the necessity. But good ones really pull their weight in coordination and identification of mismatches.
There is probably no way to “do better at coordination while dealing with normal peers and while only doing a fair amount of work.” Either do more work (of a different type than the class is based on), accept the pain and bad results, or find/force another student to do that coordination work. In the real world, in good companies, results get noticed and lead to better personal outcomes—not everyone is equal, and “fair” doesn’t matter much. In school, you’re kind of screwed.
Though there ARE some things you can do—extra work and coordinating/cajoling people, but often effective and feasible. Start with integration. Get the end-to-end WORKING MOCKUP going with hardcoded behaviors in each module, but working interfaces. This is often half or more of the work, and there’s no way to avoid it—doing it at the end is painful and often fails. Doing it up front is painful but actually leads to completion. You may learn some things in this phase that make you split up the work differently. Depending on size and duration of the project, that may be fixable with different division, or may just be “I’ll try to help once I’ve finished my part”.
I do believe that projects in general often fail due to lack of glue responsibilities, but didn’t want to generalize too much in what I wrote.
Being able to convince everyone to put in the time to do this upfront is already a challenge :/ Sometimes I feel quite hopeless?/sad? in that I couldn’t realistically make some coordination techniques work because of everyone’s difference of goals and hidden motivations, or the large upfront cost in building a new consensus away from the Schelling point of normal university projects.