Nov 082011
 
TAMPA, FL - OCTOBER 24:  (R-L) Florida Gov. Ch...

Image by Getty Images via @daylife

Mere minutes ago, a Tweet showed up in my stream that asked for freelance .NET developers saying they had a 160 hour project spread out over six weeks that needed doing.

Really?

That’s pretty amazing how they knew the project would take 160 hours / six weeks. Does CNN know about this? Just think of all the good this company could do predicting earthquakes and volcanic eruptions and so forth. It’s awesome how they know with such precision how long their project will be.

I think from here on out, I’m going to deal with everyone as if I know how long it will take them to do the work I want.

“Any painters out there? I’ve got 12 hours of painting that needs to be done.”

“Any attorneys out there? I’ve got 4 hours of lawyering I need someone to take care of.”

“My tooth hurts. I need an hour and a half worth of dentistry, please.”

It sounds ridiculous when you apply this to other fields, so why is it so commonplace in software development projects?

A far more realistic Tweet would have been something like:

“I don’t know how long this project will take you, but I’ll pay you for 160 hours, and I have a hard stop at six weeks, so you’ll have to do whatever you need to do to finish by that date.”

This also kind of sounds silly, but at least it portrays the reality, and it’s the reality of how most software development projects are planned.

I don’t care how much acumen or experience you have as either a developer or a project manager, you cannot dictate how long a software development project will take. You can’t. No, you can’t.  “But…” No, but nothing. You cannot. Can. Not.

You can dictate how long you wish it would take. You can dictate how much you’re willing to spend. You can define whatever factors raise hard deadlines you can’t work around. You can’t declare in advance how long development will take. Heck, this guy didn’t even know who the developer would be. Does he seriously think that every single developer out there will take 160 hours to do his project?

This is why a metrics-based approach provides the best projections. Do a little of the work, measure it, and use that to project the rest. Do a little more of the work. Measure it. Refine projections. Rinse and repeat.

You can budget and plan based on reality, or you can do it based on what you wish reality was.

Next time you go looking for a developer, don’t tell them how long the project is. You don’t know. Define the parameters you’re willing to live with for budget and timelines and see if the real projections sustain those parameters. Anything else is just guessing.

Nov 032011
 
Weight Loss Progress

Image by Lexinatrix via Flickr

Did you know that people who weigh themselves every day are much more successful losing weight than people who don’t? That’s because the numbers don’t lie.

People who go off of more circumstantial indicators like how they look to themselves, how they feel, or how their clothes fit can often have an incorrect notion of whether or not they’re actually losing weight, but you know what always tells you whether or not you’re losing weight? Your weight.

Looking at your true weight on a daily basis, however, can be unpleasant. You’ll see days when it goes up. You’ll feel the pressure of having to be disciplined, or that number will show it. In addition, the very first time you see that number, you might be in for a nasty shock compared to what you believe you weigh.

Organizations go through a similar range of emotions when they begin to transition to a metrics-based way of looking at their workflow.

Managers have an idea in their heads of how long things take, how fast people are, how much effort certain tasks require, etc. Just like a person basing their idea of their weight on how their clothes fit or how they look in the mirror, this idea isn’t completely unfounded, but it is extremely likely to be inaccurate and skewed by all kinds of things that interfere with perceptions.

When the metrics are first laid out in front of them, it’s like stepping on the scale for the first time. You see how long things actually take, how fast your teams actually move, and how much effort various tasks require. This is often alarming and, more importantly, it often doesn’t match up well with management wishes.

What happens next is mystifying.

If you think you weigh 175, and the scale says 200, then this is where you go, “Holy mackerel, I’d better start losing some weight.” In other words, you adjust your plans based on the actual metrics you receive.

Time and time again, I see organizations get -angry- at the actual metrics and insist that the figures themselves change. Having seen in cold, hard numbers that their estimates are unrealistic, rather than change their estimates, processes, etc., they get angry and insist that the unrealistic estimates get met, anyway, which is akin to yelling at your scale to go back to 175.

Folks, it’s true that reality has a strong subjective component to it. It’s also true that it has a strong objective component to it. It doesn’t matter how fast you wish things got done; it only matters how fast things actually get done. You can get mad about it. You can shut your eyes and pretend it isn’t there. The one thing you can’t do is magically declare the reality to be different than what it is.

At the beginning, I said that people who weighed themselves regularly were more successful at losing weight than people who didn’t. The road to success involves embracing reality and dealing with it. Look at those numbers. Let them shock you – and make your plans and decisions based on that reality, not what you wish reality was.