“Before you speak, listen. Before you write, think. Before you spend, earn. Before you invest, investigate. Before you criticize, wait. Before you pray, forgive. Before you quit, try. Before you retire, save. Before you die, give.”

Sunday, January 17, 2010

Project management .. or how do you get 1 baby in a month using 9 women

Since I started doing some kind of mini-project management I worked I realized something shocking. We (the developers) are just resources .. like a car engine or robot. The thing is that we are very expensive resources and we need to deliver code to actually ensure the company has profit.
The way management views us is that simple. And recently I have started to do it myself when using tools such as GanttProject. As you can see below this tool actually runs on Linux which makes it a great tool for new non-corporate project managers.















Ever since I started as a developer I had my conflicts with project managers. They would keep insisting that the task should take 2d because the project would not be on critical path otherwise .. and I would just say : It will not happen I think it takes 4 days (at least).
Now I get to do the estimations and the only way we could do the estimations right in my opinion is by using something called : Evidence Based Scheduling
I do not think you could ever estimate a new task without having it done before. This is not picking apples activity this is a complex endeavour. It is quite hard to say whether I can split a task between 4 people and parallelize it.
So as a team leader I am expected to make the right choice when doing the Gantt Diagram and sending it to management but I always tend to err on the safe side because I happen to know how it feels to be stuck before an error you could not possibly understand or to need something from a fellow developer and that guy is not available. Or to have some other priority taking away one or 2 members off your team.
The result is that I always finish on time and even before that but that is not always good because that time is always too long.
As far as I am concerned I feel obliged to honor my own estimation and that is that.
There are 2 ways of doing task estimating and only one is right in my view
1) We have a project deadline (already specified in contracts and signed for) let's split it between the developers and see how we can deliver it. The developers just have to do it in the specified time (or we will fire them).
2) We need to implement a project. We get together the team. Each developer chooses the features he needs to implement and gives an estimate. The team leader( me ) comes up with a sum of all estimates + some slack and the deadline is specified to the client (upper management might add some more slack).

Fortunately people understand that they need to do it using the 2nd method (at least where I work) but there are still shops doing the first method (been there done that) and these shops do not stay in business for long.
I like to be organized and I did my best to study time management techniques or to be effective in my work so I like to actually create a schedule and respect it (as a true professional) but I just don't like the idea that everything is already planned for you and you the developer don't get to actually say how much a task will take even if it is assigned to you. Developers that can't be trusted with estimates should not be trusted with code .. but (some) project managers seem to miss this point so they do the estimates for the poor guys and ask them to come during Weekends to get the work done.
LE: could not help it 9 women give you 1 baby /month :)