I’m constantly experiencing life without rules: I’m disastrous at organizing myself and everyone knows that. Chances are lots of people are like me, or, heavens forbid, even worse than me, but this is not a thing I take pride in. Honestly, I don’t see any reasons to look on the other side and try to see how green is their grass, since that does not help at all with solving one’s problems. What I do need is some rules. Yes, I need regulations.

I also think work is important, because it brings money. Therefore it needs to be efficient. From here, the paradox: work it’s not pleasant, but you always want more (money). So, naturally, I want to start by making some rules for my work.

#1: always take on new projects

I noticed, for instance, that projects that I get to start are significantly more rewarding that projects I’m hired to continue. This means I win more on new projects. In practice, I discovered that rewarding means more than just money: a new project offers me an important role in decision-making, I can consider it mine as well as theirs, and it can weigh significantly more in my portfolio.

#2: 20% of work time means initial/final setup (but no less than 4 hours)

My second empirically determined rule concerns project timing: I discovered I almost never time initial setup and final deployment. Initial setup involves gathering materials for the job, organizing a project folder, reviewing the documentation/discussions and organizing tasks. Final deployment is tricky as well: a final review of the deliverables, emails, acknowledgements etc. In the case of a software project, this might involve on-site configuration, deployment of the website on the client’s server etc. I think these should get 10% to 20% of the total developing time, but no less than 4 hours. Your values might vary.

#3: know thy client

I can’t really comment on this one, since I screwed up so many times. But a careful analysis of our clients lead to discovering traits: this one’s not good at specing, that one talks too much. And these are things that influence estimates.

#4: spec! spec! spec!

I will never start work until I have a clear understanding of everything that I must do, down to every single detail. The level of detail must be proportional with the size and scope of the project. This is why I will carefully sketch, diagram, explain and talk over every single thing in a large project. Apologies for the serious tone, but I got it hard in the past.

#5: create a well-thought timeline

Discussing timelines and project planning can be a drag. For now, I do it my own way: task division with associated time frame. I then apply the percentages, multiplying the total amount of hours with: 1.2 for initial/final setup (#2), 1.4 for discussions, 1.1 for reporting, 1.2 for testing, 1.1 for unpredicted problems. These numbers might change over time. Right now, they double the initial time, which I think is good practice (for me).

But no matter the numbers, this is just another thing I will never get too good at. And that’s because of: 1. over-confidence, 2. clients (see rule #3). I thought I am not over-confident until last April. (Boy, did 2007 suck after that!). But it turned out that I am, and now I think my timeline in a much more detailed fashion. But no matter how well-thought, problems arise, and mostly, they come from the other half. Clients have their way and, for the most part, it’s not debatable, not to mention unchangeable. A client that likes to talk a lot will likely shake your well-crafted timeline (learned that the hard way!). So, this is the explanation for rule #3.

#6: ensure legal safeties

I’m still working on this one. I have no idea how to legally bind clients with an effective contract. And even if I will, I’ll find myself with another problem: they are in another country. And there is another point to make here: try to avoid complications in case you can’t deliver. Usually, clients don’t understand. So, I’ll have to amount for that as well. I don’t think a client should be paid large amounts of money if you failed to deliver the project. It can happen so that you can only deliver parts of the project, the client benefits from them, but you still pay for the unfinished parts. This must not happen.

My first two rules come rather empirically, from what I gathered about my work, which is an important point to make. Different domains generate different rules. But, as a rule of thumb, every domain has its specifics, oddities and quirks. I think working these to my advantage is a decent starting point. As for my next rules, they concern either the client, or my organizing myself, and they basically come with a more general tone.

I will hopefully update this as I find more rules. Note to self: find more rules, because constraints lead to good stuff happening.

Posted in personal, work on Friday, March 14th, 2008 1:55 pm