Avoiding Disaster: Project Planning

It’s been wild here because of the 200th Anniversary of our Independence! That’s why there was no happy post yesterday. For all you mexican fellows out there, congratulations! We’ve been cool for 200 years! Or so it seems.

Anyways, back to today’s post.

I’ve been wanting to talk about project planning for a while, and today I was reading some articles about stuff to avoid, things to consider, and so on, so it is a great time to give you my take on the subject.

  1. Always make sure you know what your client’s talking about – And, while you’re at it, make sure HE knows what he’s asking of you. Don’t take anything for granted and don’t assume anything.IT’S DANGEROUS!

    As an example and personal experience, I once worked for a government branch that was managing funds given as donations for the less fortunate people. They needed a system that could help them do so on the computer (I was 100% computer systems engineer at the time, but the experience is valid in this case). Our main contact was a very understanding woman but we assumed she was giving some of the stuff she was telling us as just examples. One of those mentions was a Messenger application, but we ASSUMED she was referring to some means of sending invoices. WRONG! She was expecting us to actually DEVELOP a Messenger-like embeded application for the system, and since we “agreed” to it, we had a lot of trouble later.

    In short, keep it clear. Crystal water clear.

  2. If you’re redesigning, ask for previous documentation – This is specially important if you have to work on the actual development of a website, for example. Trying to break through code that someone else wrote without any documentation is HELL. Believe me, I know, I’ve been there…
  3. Plan out your timeline – Don’t choose delivery dates at random! You WILL have to answer to them, you better have some previous ground rules for choosing them or you’ll be in trouble when you’re not able to meet them. After all, a commitment of this kind is very important to the user, and not meeting a previously specified date will make your image as a professional decay.
  4. Make meetings count – Don’t waste the time you reserve for meetings. You can always invest them in making premise number 1 a little stronger. Don’t be afraid to ask your user, it’ll benefit both of you.

    You might also want to plan out your meetings, as to not get there and just improvise. You can also look bad if you don’t really know what to say or do.

  5. Consider on-the-go changes – Will you charge extra if the user decides to change stuff you had previously agreed on and you are already working on? Will you give him some tolerance on the subject? What’ll happen to your previously established timeline if this occurs? You might want to ask yourselves those questions.
  6. Make sure the project is well established - If the client doesn’t really know what he wants, then you don’t really have anything to start with. Accepting a project you don’t fully understand is never a good idea. You can end up in the middle of something you can’t really do.
  7. Consider having a pricing table - Charging for a project has always been a problem for me when I’m not really sure how to charge, but there are ways to help ourselves with the issue. A pricing table is convenient because you can break your work down into deliverables and put a price to each one of them individually, for a later sum up. You could also charge by hour, varying the prices if there is some kind of time rush, with the need to work during weekends or nights.
  8. Listen to your teammates – For example, the timeline establishment issue. If you are not a programmer, you probably don’t know how much time it takes to develop something, so why not consult your programmers?

I also found some interesting related articles I wanted to share (I know I do this a lot, but it helps!):

Any comments or doubts on the subject? I’d be glad to hear you out!