-- used for in-class instruction. created and taught by Garrett Collins --
Projects may last an afternoon or may be ongoing over several semesters or even years. You might be the only member of the project team or you might be managing several of your fellow students. You may be responsible for the whole project or you may have to work with other project leaders to complete a larger project.
Projects vary; so, I'm going to speak generally about the qualities of managers and those they manage. The object of this lecture is to prepare you to manage a project team by: giving you an idea of what is expected by computing, providing suggestions on how to effectively lead your fellow students.
You're a student; so, your manager expects certain reports from you, as the project leader. Here are some possible reports you may be asked to generate and some idea of how to do that:
Milestones/timeline: This may be given to you by your supervisor; but,
if you have to do this yourself: Look over the (Un)common Sense section of this document
and create a plan that details what gets done when, to keep your project on time. Your
supervisor will most likely look over the document you draft and make changes.
Reporting (detailing problems, insights, performance): Along the way, as
your project progresses, you'll want to note areas/tasks where your team had difficulties
and how these difficulties were met. This will allow you (and your supervisor) to reassess
your project and revise your milestones/timeline to take new developments into
consideration.
Request assistance: One of the most important things a worker, any
worker, can do is to realize and ask when they need help. Failure to ask for help may
result in injury to yourself or to your fellows; or, it might mean that the project is set
back till someone else recognizes that additional help is required.
Write up (detailing problems, insights, performance): Upon completion,
your supervisor may ask for a (detailed) write up of your project. This document will
provide future team leaders with a blueprint of how your project went so they may learn
from your insights and your difficulties. It will also provide clues, later, if some
aspect of your project fails or needs to be reworked. Both this report and that kept
during the progress of the project are only as good as the information you keep in them;
details and clear explanation are essential to the worth of these document.
You're leading your fellows; so, work with them and they will follow you. The mechanics of leading a group (especially when there may be no clear hierarchic structure) is a complex thing. Let us consider a model that is more in the vein of Thomas Hobbes than that of Friedrich Nietzsche*:
Guiding vs. Ordering: The way to say it makes a lot/all the difference. I don't know anyone who likes being told what to do; so, ask your fellow team members to do things.
Working with vs. Overseeing: The project leader has to keep the bigger picture in mind; but, that does not mean that they merely oversee their fellows. It provides a positive work dynamic if you work with your fellow team members (as opposed to making them do the work while you do the thinking).
The bottom line: Consider the way you'd like to be treated if you were a member of this project team and then consider your fellows' individual situations.*Being feared is all well and good; but, in this hostile world, it seems more circumspect (to me) to work together for the common good.
Work smart. I know it's cliché; but, a lot of time and effort may be saved if you think things out before you start working with your team.