Monthly Archives: July 2014
There are a lot of simple “life lessons” out there. When you hear one for the first time you may feel like you knew it already, you just never really thought about it.
I’ve decided to try to write short posts whenever I get some small revelation about something or other. Here is the first one.
I recently watched an interview with Larry Page and Sergey Brin, and something Larry said created one of those “Aha” moments. They were discussing wether he and Sergey had any fundamental disagreements during their time as founders of Google. Since they know each other well and have great respect for each other, Larry commented that
“(..)if we are disagreeing about something, it is probably because it isn’t obvious what to do”
When you think about it, that’s actually quite profound. During the heat of an argument, most people are quite convinced they are right. But if an argument is heated, someone else are equally convinced that you are wrong. So any time an argument escalates, it could be a useful red flag indicating that the answer probably isn’t that clear cut.
If someone you know and trust thinks you are wrong, chances are you’re at least not 100% right. So instead of butting heads (for too long), give them space to explain and elaborate their point of view. Acknowledge that whatever you’re discussing probably doesn’t have an obvious right or wrong answer, and you may need time and input from other people to come to a conclusion.
It’s time to let you in on The Secret. Don’t tell anyone, but “How long does it take” is the wrong question.
I planned for this post to be about statistics and how to calculate probabilites. Instead it turned into a rant, of sorts. You see, there’s another Secret buried here: If you really take the time to learn how to estimate risk correctly, this will help you learn the following fact about the outcome of your project: It is very uncertain. I guess that’s helpful. Sort of.
“That’s just baloney,” I can hear some of you say. “My projects are consistently on time and on budget,” you continue. Maybe so. Let’s examine the famous “project triangle” for a moment.
Ever wondered why it isn’t a square? Because quality is a result of the other three, some might say. “That’s just baloney,” you can hear me say. I think it’s because cost, scope and time is easy to measure and easy to adjust. Quality? We always deliver perfect quality! We are professionals! Let’s just put that in the middle, and hope no one pays too much attention.
You, the guy who screamed “We always deliver on time and on budget!” a moment ago. How about scope? “Hah! We delivered all the functionality as well! All the developers bitched about them having too much to do in too little time, but my project plan showed them wrong!”
That’s impressive. But even when we go to the painstaking length of figuring out the risk and uncertainty of a project PROPERLY – You know, with Statistics and stuff, not just, God forbid, guessing or anything – it still comes out as being very uncertain. So how come you can consistently deliver your projects on time, scope and budget? Your team don’t have much choice, do they? They have to reduce quality. Luckily for you, no one will notice until the project is over. And they couldn’t really measure it if they did. What IS quality anyway? Sounds like a made up word to me.
So what did I mean by “how long does it take” being the wrong question?
There are a couple of problems. First of all, what is this “it” that we are doing? When you start the project, odds are neither you or the customer knows what the end result is supposed to look like. You may think that you do, but you don’t.
If it is a waterfall project, the customer will say “This is what I want” while dropping the dreaded Complete Requirement Specification on your desk. Then you go away for three months with a team of developers to create whatever is in the specification. “Here is your product!” you exclaim with great enthusiasm when you come back. After the customer has tested it, she goes “Nope, that’s not it.”
If it’s an agile project, your team of developers only go away for maybe a couple of weeks at the time. Each time you come back and show a little bit of the product, the customer tests it and goes “Nope, that’s not it either. And where’s the rest?”
However you go about it, both you and the customer learn a lot DURING the project. Mostly what they don’t want. Needless to say, this process takes quite a bit longer than just doing stuff once. No one knows what done looks like until, well, you’re done. And please remember, we’re not BUILDING a product, we’re CREATING it. The first of its kind. Your developers aren’t packing meat in boxes along a conveyer belt, they’re freaking SCIENTISTS! So stop pretending you are a production facility. The product you’re creating has never been built before. If it has, please go and buy that instead.
And that’s not even half of it. What did you say were doing again? A project, right? Well, most of the time we’re not really creating projects, we’re creating PRODUCTS. The funny thing about products is that they don’t end when the project ends. That’s kind of when they start. In terms of cost, that means roughly 90% of the total cost of a product comes AFTER the initial release. Maintenance, bug fixing, additional development, paying back technical debt, people spending most of their day swearing over how horrible it is, and so on.
Here’s the Third Secret: The less time you spend on quality during the “project” phase, the higher the total cost of the product.
So whenever you pat yourself on the back for delivering “on time” (usually a random point in time decided by anything except the actual amount of work that needs to be done before that date), that probably means you have reduced the overall quality of the project, and increased the total cost of the product you delivered. That doesn’t really sound like back patting performance, if you ask me.
Did you think this series of posts would culiminate in How To Estimate Accurately In 3 Easy Steps? Well, it sort of didn’t. If you’re still looking for that guide, you should probably read “The Flaw of Averages: Why We Underestimate in the Face of Uncertainty” by Sam L. Savage.
I’m not sure it will make your estimates more accurate, but at least you’ll understand why.
On an intellectual level, everyone understands that communication is important.
And everyone in a company is working together with someone else, unless it is a one man company. So without communication, nothing much would get done. Stating the obvious, right?
A recent NTNU (Norwegian University of Science and Technology) Master Thesis concluded that (paraphrased):
“Allthough all organizations think that good communication is vital in order to run projects in the direction of their organizational strategy, most do not have the desired communication systems, culture or skills(..)”
Surely that doesn’t apply to your company. You guys spend lots of time making sure everyone understands what to communicate when, and to who. You naturally share all relevant information to as many people as possible, in a way that makes sure the original message is preserved.
I’m sure that you always make sure that “what is relevant” isn’t defined to tightly, and terms as “on a need to know basis” are generally frowned upon. Informal communication is always encouraged in order to build an environment where anyone will continously voice their intent, their understanding, their worries and their questions without fear of repercussions. Right?
And your managers always make sure everyone involved knows where the team is going and why. When someone does something that is not aligned with the overall goal of the company, they do not blame the individual. They ask “What piece of information did this person not have, and why?” or “What has this person not understood, and how can we help this person understand it better in the future?”
Did I just describe how the concept of information flow works in your company?