Trustev currently has two fantastic guys working with us as part of their college placement programmes. Michael Linehan and David Devane. While they refer to themselves as ‘interns’ they’ve been given full time, paying roles as a Junior Project Manager and Junior Developer, with all the responsibilities and training those roles demand.
To prove that we’re not just keeping them chained in the basement, every week they’ve been encouraged to write a blog post about any topic they want.
One of the hardest parts of any college course is when you reach the point where you're expected to take everything you've learned and apply it in the form of a large scale team project. For most students this is the first college experience that comes close to what real life work environments will be like. Being an intern of just less than 3 months experience, I don’t exactly have a wealth of experience in managing large projects but what I can offer thus far is some rather useful advice for any First and Second Year BIS students who have yet to face the horrible eventuality that is the Third Year Cross Modular Project. If you are a First or Second year BIS student, you will have heard many horror stories about the project and unfortunately most of them are true. But here is the good news, you will emerge from the project alive (hopefully), stronger, better equipped to handle future projects and with the right to boast about what you went through in the same sort of nostalgic way that a hardened war veteran would describe what it was like “back in Nam”.
The following is not just a survival guide but a way to ensure that you and your team gain a competitive advantage and save yourself from the common pitfalls which are often learned the hard way. It can be applied to other projects also as it is what I believe is a general best-practice approach to managing a college group-project.
Choose your team early – It’s a well-known fact that if you fail to plan, you plan to fail. Planning who you will be teamed up with is a must. From first and second year projects you should by now know who to team up with and more importantly who not to team up with. I cannot stress the importance of making the right choice of team members, it is absolutely imperative to your success. Forget friendships and go with the people who you know will give the project they're all.
Don’t get me wrong it is important that you get along and can communicate with each other effectively, because you will spend the whole lot of Year 3 semester 2 with each other all day every day and will need to have the kind of professional relationship that stops you from murdering them in a stress / caffeine induced rage when stuff goes wrong, which it will… a lot. My project team was formed before third year had even started as a strategic conversation in Havana’s smoking room over a few Jaeger-bombs with a classmate who I worked well with on a former project and it turned out to be a strangely sensible move.
Start Early – Stating the obvious, I know but you would be surprised by how hard it is to force yourself to dive into something where you have absolutely no idea how you’re going to do it. We met up for the first official meeting, one week into the January break and continued this for the rest of the month on a weekly basis. In January I would recommend getting all the design and analysis documents done. It will probably only be a first draft but have them done so that you can ask for feedback as soon as you go back in February and get them complete and out of the way. Remember that analysis and design diagrams are used in real organizations as high-level maps of the system that can be understood by people who don’t have a technical background, so keep them simple and don’t try to perfect them because chances are when you go back in February you will more than likely be told by your lecturer that there are mistakes.
Trial and Error - The thing you will have to accept is that you will make mistakes, lots and lots of mistakes, so treat the project as an iterative process. Whether it be your database design, coding or project management documents, aim to get a good version of the particular milestone done as quickly as possible so that you can get feedback from your lecturer. Trust me there will be a huge cue waiting to ask them questions so it is in your own interest to be able to say that all you need help with is for them to tell you whether or not that you are headed in the right direction. Just like anything else the key to mastering these milestones is repetition, repetition, repetition; then repeat this step again. You just have to accept the fact that if you want to do well you will constantly be redrafting documents and hunting bugs in your code. Treat each milestone like a sprint in which you attempt to get it working as quickly as possible with the view of coming back to it once completed to fine tune it for submission.
Document Control – As mentioned above, if you are aiming to do well you will never be handing up a first draft. I will never forget the shock of getting half marks in one of our database design hand-ups after we had been fully convinced that it was at least 1H worthy. Turns out we had handed up a version that was weeks old and had undergone a complete re-vamp since. Set up a file-sharing facility for you and your project team. We used Dropbox because it is free and easy to use but other ones are also good like Google Drive. Just be careful because the danger with cloud based file sharing is that you could be working on a document at the same time as someone else on the team and this is when mistakes happen. Since working at Trustev, I have learned two handy tips to avoid this:
1. Design a set folder structure. For example in your e-business folder you might have a Coding sub folder and separate sub folders for each design document. Also create a sub folder called Drafts. Any document which is not ready to be submitted should be saved in this draft folder and in the name of the document include the word draft, what it relates to and the date it was last updated. When the final draft is approved for submission, move it into the relevant folder and rename it without the word draft. This will avoid you handing up incomplete work.
2. Assign Work. Make sure that before you head away from college at the end of the day to work from home that you have a brief meeting describing what work each person will do for the evening. This will avoid duplication and over-lapping work on the same item.
Commit yourself – By mid-March the project will be done and trust me the time flies once the January break is over so don’t fall into the trap of procrastination. Make a commitment to give it your all over the 7 or 8 weeks between coming back and presenting the project. It might mean a few 12 hour days in college but it will all be worth it when you know that you guaranteed yourself the best grade possible in the toughest year of the course.
Work Together – Particularly in this project where there is a mix of technical and written based work to be done, the temptation is often to let the people who are good at coding to do all the coding and then let the people who can’t code to do all of the Project Management and design documents. Firstly, it is a requirement that each member must contribute equally to each part of the project. If you don’t, you will get caught out on the day of the presentation by a question about coding. Secondly, it is much easier to identify solutions if you are all working together as a team. When we got to the hard-coding of the system, we were often all huddled together around one computer trying to figure out how we would make write the database queries and build each page. It is a lot easier and quicker to overcome problems with four different peoples’ input on the problem. Once you start to successfully build some of the first pages, you can then use them as a template for others and begin delegating the coding among different people in the project group.
It was only after completing the project that I realised how valuable the whole process had been. You are forced to work proactively and also communicate with your fellow group members to ensure that they work in a similar fashion. You really are thrown into the deep end with this project but hopefully these steps will be a helpful guideline to any student who isn’t sure how they are even going to go about starting the Cross Modular Project. While this advice is the result of one specific project, these pitfalls and solutions become are relevant to all BIS students in all colleges who will experience similar situations when it comes to managing group projects.
Michael Lenihan is a 3rd year BIS student working his placement at Trustev. He thinks this means no exams - we've already started writing the exam papers. He's screwed.