Monthly Archives: February 2012
The guys in the agile community have been writing, talking and moaning about estimates for ages. “Accurate estimates are impossible! What’s the point? Let’s stop estimating, it’s just guessing anyway!“
Let me try to explain.
We all agree that we’re basically guessing, right? That may be the case, but if you live in the real world, you actually sell stuff for a living. In order to sell stuff, you need to have customers. And what’s the problem with customers? They usually demand to know what something costs before it’s produced. Go figure. Anyway, that means we need to estimate wether we like it or not.
A rough estimate from a developer or architect is usually the basis for a fixed price offer. If the estimate is good, you’ll make money. Sometimes it’s not, and then you’re up shit creek. If bad luck and an inexperienced developer team up, rough estimates can be several hundred percent off the mark. So why do we keep working like this?
The big problem with this transaction is trust. The customer rarely trust the software company enough to pay for a project by the hour. The history books are full of dishonest companies who have destroyed the trust in the IT industry. Now we all have to work hard in order to regain that trust. You need to convince each and every customer that you actually want to add value to their business by creating great software. That’s what we’re all about. Right?
If you gain enough trust within your market, I strongly suggest that you attempt to operate with budget limits instead of a fixed price. Agree on a minimum scope, and explain to the customer that you will do your best to include as much functionality as possible within the budget you have agreed upon. This way you reduce the risk on your end, and the customer doesn’t have to pay for the built-in risk premium of a fixed price. A better deal for everyone.
Great stuff, happy campers all around! Now we can stop estimating and focus on real work.. But wait a minute. How can you (or the customer) know wether the project will be worthwhile? How do you establish a reasonable budget? When presented with the required time to market, how can you tell if you will be able to deliver on time? You guessed it, by estimating. Seems like there’s no way to win this game.
To make matters worse, the game changes as you go along. As your company grows, your development process will change. You add quality assurance, you add a project manager. Your team grows, and suddenly lots of time is spent talking about how to do stuff instead of actually doing it. Challenging SLAs means more time spent on release management and server maintenance. The environment surrounding your team changes all the time, and the correct answer to “how long will it take to..” changes with it.
At the end of the day, an estimate can never be more than an educated guess. But fear not, all is not lost: If you manage to build a team with focus on quality, keep the turnover low and maintain a stable, honest environment with room for making mistakes – you might just end up with a bunch of guys that are amazingly good at guessing.
I’ve got a list of what I try to focus on as a CTO and project manager. On my list I’ve got 7 items. Project management is number 5.
Project management. Some dork in a tie running around while he’s pointing at his gant chart and yelling at people to work faster. A gant chart that stopped resembling reality before it’s even printed. He has never delivered a project on time. Ever. Everyone knows projects are always late. There’s always some delay or scope creep or useless third party vendor with a product that doesn’t work. So why even bother?
But wait.. Does another breed of management exist? Living in a touchy feely world, where projects actually deliver value, on time? And if they had a list, would it look anything like this?
#1: Be there for your project team:
Care about their problems, and help them resolve them. Your role is to remove any obstacle, and for the love of God, make sure you’re not an obstacle yourself. When they’re working, stay out of their way.
#2: Quality assurance:
Most project managers (myself included) spend too little time focusing on what is actually being done. Are your project output in tune with what your customer expects, and does it create actual value? Cost. Scope. Time. There are always someone trying to make you do more for less. Tell them to stick their project triangle where the sun doesn’t shine, and replace it with Quality, Quality, Quality.
Effective projects depend on good processes. Strive to be better. Lock into a lean mindset where you continously attempt to improve the way you and your team work, and eliminate waste.
#4: Customer service (and zero tolerance for incidents that negatively impact the customer):
You must always be available to your customer. You need make sure they know what to expect, and when they can expect it. Oh, and the last part of this rule I stole from my previous boss:
Me: “We’ve got a bug in production!” My boss: “Does it affect our customers? Forget what you’re doing and fix it!” Me: “Now?” My boss: “Are you still here?”
#5: Project management:
Is everyone and everything on track? Has important milestones been met? Do all stakeholders have the information they need? You know the drill.
#6: Sales and marketing support:
Don’t forget tomorrow. Another day, another project. Your support to the marketing division will help them make the right decisions based on your input. This ensures that the next project they’ve got cooking gets a reality check, and thereby is granted at least a moderate chance of success.
A gant chart is a great visual aid to help the customer understand when you will deliver project output. As a management aid it is more or less useless. Plan 1-2 weeks in moderate detail (not in gant chart!), 2-3 months as a rough draft to know how many resources are booked and how many (if any) will be available for additional projects. That’s it.
So, there you have it. Is this a perfect list? Far from it. Do I even follow it? Not always.
But no matter how busy my day gets, I try to keep at least #1 and #3 on my forehead. And the rest in my back pocket, for safe keeping.
How about you?