My First Project: A Reflection
May 8, 2008
Know your time lines and stick to them
This is pretty straightforward people. Know when you need to deliver things by (milestones, project builds, documents, etc) and make sure they’re delivered by that date/time. When things start slipping from the timeline, then it just compounds as one section runs into another. Believe me when I say that there is only so much overlap you can orchestrate before something breaks. Think Jenga.
On that same note, make sure that your time requirements are accurate. I cannot stress that enough. If you think something should only take you an hour, give yourself 2. If you end up ahead of schedule, great! You’ve just created buffer time for when something goes wrong. I’m not advocating giving yourself a week to do a day-long job, but be realistic with your time lines, not optimistic.
Don’t bother getting mad, you’ll only give yourself a hernia
I learned this about half way through the project, which is depressing because had I learned sooner I wouldn’t be as sick as I have been. Stressing out and getting upset by every mishap isn’t worth the energy expended to do so. The phrase “No use crying over spilled milk” has never wrung so true as it has for me during this time.
I realized that getting upset doesn’t do anyone any good, and only serves to fray already shot nerves. Realize that thing’s aren’t going according to plan, and plot out a logical course of action. I’m not saying that you shouldn’t care that your project is 1 hour before a presentation to 100 important people and not working. Far from, actually. What I’m saying is that muttering your last rights in the corner as you rock back and forth in a fetal position isn’t going to do anyone any good.
Don’t play the blame game, but don’t let things slide either
This was a big one for me. Throughout the entire project, my mantra has been (and probably will always be for projects): “I don’t care why it was broken, so long as it’s fixed now.” What This means is that I don’t care who’s fault it may or may not be. I care that the project is continuing to move toward its goal now that the problem has been overcome.
If someone’s not pulling their weight, fix it. If someone made a mistake, tell them. People are responsible for their action or lack there of. That doesn’t mean you should go pinning the blame on people when something goes haywire. Explain the problem like an adult, and approach it like an adult. Saying “You didn’t do X so fix it now” isn’t going to get you the warm reception you’re expecting. People get defensive when you attack them head on, and this is how arguments over stupid topics start.
Think before you open your damned mouth
This one was/is hard for me. I have a habit of shooting my mouth off when I shouldn’t and I know it. This translates directly into how I work with others, and I have to make a conscious effort to think about what I’m saying and how I’m saying it. I’ve noted a couple times during this project that I’ve sounded like a complete dick. I don’t mean to, but because I worded things badly it makes me look like a jerkhole.
Before you click the send button, open your mouth, or pick up the pen, think. Figure out what you want to say and how you want to say it. Try and make sure you’re not being out-right offensive (unless that’s your goal) and be concise. Taking the extra five seconds can make the resulting exchange that much easier.
Write it down
There were so many times when steps in installation, documentation, development, and God knows where else were overlooked, ignored, or outright forgotten. If you happen to have the goldfish memory that I do, you will benefit from this. Writing things down at least gives you a paper-trail to work with. If you find yourself taking a lot of notes, give them a time stamp. Use different colours of pens and/r highlighters to signify different sections or notation types.
I’ve found that by the time I’ve taken to write down what I want to remember, it’s already locked in my head. The simple act of writing it down seems to solidify the memory so that the note I just took is now no longer required, as my brain has done its job.
Writing things down has the added bonus of allowing others to know what you know. If you’re not going to be around for a while, at least others have your notes to work from. Sure they could be utterly insane to anyone that isn’t you, but at least it’s something.
P.S. The same goes for commenting code.
Pay attention
Try and keep tabs on where everyone is in their time lines. If you need something from someone, make sure that when you need it, they haven’t swanned off to a meeting or vacation. There’s nothing worse then being ahead of the game, only to be brought back down or even pulled behind on your deliverables because Adam McMoron has decided to try and get Finance Girls number.
If you’re in charge of people, make sure that they aren’t playing minesweeper or Facebooking their best friend thrice-removed. I know it sounds stupid, but if you give people a week to do something, they’ll find a way to make it last a week. I’m not saying you need to have armed guards holding their families hostage to make sure they’re working efficiently, but make sure you know what’s going on. Schedule end-of-day meetings, or set up mandatory emails stating what they’ve been doing. If you want to get really stingy, find a time-logging program that you and your underlings can use.
Despite popular belief, assuming only makes an ass of you
It’s not their fault when you assumed something. Assumptions are guesses based on half-information and the ethers. If you have to assume something, there hasn’t been enough communication. If you find yourself saying things like “He’s supposed to be doing it” or “It should be here monday” you are assuming. Words like ’should’ and ’supposed’ are bad news.
You can avoid assuming by simply confirming what you think. If you think the package will be here on Monday, call the postal service. If you think that someone is supposed to be doing a job, ask them. The bottom line here is that assuming will end up biting you in the ass. Sometimes you assume right, but I assure you that most of the time you will assume very wrong.
Learn from your mistakes, lest you repeat them
During this project, there was a night that I was at work for 40 hours. Why? simply put: the shit got fucked up. I cannot and will not go into the details as to what happened or why, but suffice it to say that bad time-management, assumptions and flat out bad luck found most of the team working well into the next day. It sucked but we managed.
One month later, it happened again.
What the hell happened? Different problems, but many of the same root causes. Assumptions were made, time was mis-managed, and we weren’t paying attention where we should have. As a result the work that was scheduled for 9 AM didn’t begin until 9 PM. There’s no excuse for this, and I won’t make one. I know where the flaws are now, and I’ll be Goddamned if I’m going to let it happen again.
That’s all for now. I’m sure when the project is totally finished, I’ll do a postmortem and regale you with even more fun tidbits that you can use (or ignore, though that would be silly.)
Photo credit: Stock.xchng – Jonathan Natiuk
Categories: Design Self-Improvement
Tagged under: business, Design, development, lessons, project, project management, teaching, tips, work
