I’d like to argue against that, from a very practical example that I found myself in a few months ago. As a 3rd year MEng Aerospace student, we all have to complete a group project in which we design and build an Unmanned Aerial Vehicle (UAV). It’s a fascinating project, and definitely the most enjoyable part of the course so far for me. More to the point, we have to justify any technical decisions made in various reports and presentations, which are then evaluated by a panel of aerospace professionals and academics. 
The first such presentation was done with all groups presenting to one another as well as the judges, and as such we could reflect on the work others had done as well as our own. We had the dubious honour of being the last group to present, and as the presentations went on we worried about the level of technical detail we were presenting. We knew that we had included a fairly extensive section on how we managed the team, and had therefore sacrificed some of the more in-depth sections on our engineering justifications. Nobody else had done this, and we worried that the panel would call us out on what we’d missed. Oddly enough, however, when it came to question time, the discussion focused extensively on the management section. They commended us on including it, and said that if they were in our position, presenting to their management, these would be the things their directors are looking for. They asked about our time plan, our budget, our goal-setting, and our division of labour. We had concrete answers to each, and none seemed particularly tricky to address. The group before us had also been questioned about a risk assessment, something no group (including us) had thought to carry out. We too were called out on this by one of the members of the panel, but before we could answer, one of the other panellists actually explained to the room that though we hadn’t included a formal risk assessment, there was
evidence of risk consideration in our management section. Our Gantt chart shows time for product testing as well as optimisation and design adjustment, as well as our budget showing that we had significant reserves. We also prioritised critical areas in our time-management, leaving more time and certainty for tasks such as component manufacturing or testing, which are harder to estimate for than things such as straightforward assembly or market research. Our goals also seemed to be clear and concise, and our progress indicated that we were in a good place for this stage of the assignment. The judge’s observation was that no other team had provided this kind of evidence, even if they may well have thought about it too. The whole experience has left me realising that the time we spent on setting targets, measuring progress, and illustrating how, why and when we’d reached a decision may have seemed a bit arduous at the time, but wasn’t “wasted” at all. When it came to justifying decisions, having a management context made it much easier for others to follow our conclusions, and gave a much bigger picture than anything we could even hope to describe in the 15 minutes allotted to us. Chances are that in engineering, when you talk about what you’ve achieved in a project, the final decision is fairly unimportant, so long as it works safely and effectively. What is important is that you show your path toward that decision, including all of the non-technical criteria that played a role.
SELA tries to highlight the importance of this in any future roles engineering students may have. All of the alumni and industry experts that come in to speak to us hardly ever talk about any specific inventions or designs that they’ve contributed to. They always talk about how their most successful projects are the ones where communication up and down a leadership hierarchy has been effective, and where decisions have been justified from a commercial or social point of view as well as the purely technical.
No comments:
Post a Comment