Each and every one of us estimates poorly in our own unique way. Some of us over-estimate, some of us under-estimate, and some of us couldn’t hit the broad side of a barn. However, we usually follow a pattern of some kind. The degree to which our estimates are off generally conforms to roughly the same proportions. If we were to examine a particular worker’s estimated task completion time to the actual completion time over the course of many tasks, we can determine the approximate factor to apply to his estimates to find the actual completion time.

The root cause of this predictability is the simple fact that humans are better at being precise than we are at being accurate when it comes to estimates. In other words, we’re quite good at approximating the relative size of a task, but we fail at determining the appropriate scale.

Take the chart below. Here we see an intentionally simplistic view of a worker’s estimated completion time versus their actual completion time.

At a glance, our worker appears to be a poor estimator, as he has underestimated each task. However, if we look at the data a little closer, we can see that on average, he was of by a factor of approximately 1.8. If we were to apply this factor to his estimates in advance we’d see a slightly different picture.

As you can see, by applying his average estimation scale factor to the figures we can calculate a much more accurate set of estimates. Of course, in practice, five data points will not provide a very accurate estimation scale factor, but by collecting this data over the course of several projects we can get a pretty good sense of this worker’s estimating characteristics.

Tracking this data manually would be cumbersome to say the least, but it’s something that a computer does very well. Given the proper tool, this data could be collected behind the scenes with little to no impact on workflow.

It just so happens that I am in the midst of building such a tool. For now, let me say that this will be a web-based, hosted, project management tool. I will be applying my many rants on the subject to creating not only a better tool, but a better process for project management. This will not be another to-do list manager, I promise you that.

Now that the cat is out of the bag, I will be posting regularly throughout the development of this tool and I will be craving your feedback. Many, many more details to come. Stay tuned.

For example, take a simple task, which can likely be found on many of your to-do lists, such as “Take out the garbage”. At face value, this seems like a very obvious request. But let’s assume someone is visiting, sees your list on the fridge and wants to lend a hand. Suddenly this seemingly simple task becomes more difficult to execute. Where is the garbage can? Is there more than one? Where does it need to be taken? What day is the garbage collected? What if the bag isn’t full? What about the raccoons?!

The difficulty with most items on to-do lists is that they’re really only meaningful to the person who wrote them. This is because they can fill in the gaps by looking at the task from their perspective, with their experience, and their past knowledge of the situation. As you’ve no doubt experienced, this causes problems when to-do lists are shared within a team, when revisiting an old list of your own, or worse of all, when a list is generated by an outside body, such as a client.This is not to say to-lists can’t serve a purpose — they just need a little help.

Firstly, you must look at a task as a step to completing a grander objective rather than being an objective itself. Secondly, you need to realize that to fully understand and satisfy an objective you both the steps to completion (tasks) and the context surrounding the objective. The task list provides one component of the objective — the What. The context provides additional components, such as the When, Where, Why and Who. Given the five W’s, the How can often have many answers and can be decided upon by whoever is working on the objective.

In a future post, I’ll discuss an all-inclusive way to specify objectives for easy interpretation and execution with a greatly diminished need for prior knowledge of the situation.

At some point in human history, estimates evolved into something more than what they’re intended to be. Perhaps we have shady contractors, auto garages, and wedding planners to thank for the modern perception that billing a client more than the estimated value means someone has been mislead, or taken advantage of. Or, perhaps it’s the fact that generating an accurate estimate is genuinely, extremely difficult — especially given that many estimates are expected to be delivered while there are still many unsolved variables on the slate. Somewhere along the way, we’ve lost sight of the fact that an estimate is really just your best guess, based on a combination of the information available at the time and your experience.

Setting expectations is a crucial aspect of delivering your estimate. Your client must be reminded that an estimate is your best guess and not a draft copy of the final invoice.

Now, setting expectations makes the discrepencies between the estimate and the final invoice easier to swallow, but it doesn’t make you a better estimator. Traditional estimates often focus on deliverables. Deliverable A will be X dollars, and Deliverable B will be Y dollars. This is a format is easily understood by the client, but makes the poor soul creating the estimate sweat. Deciding on a time or dollar value based on a mental image of a loosely defined deliverable is asking for trouble.

To become a better estimator you need to keep in mind that even the most complex projects can be broken down into a series of small tasks. It’s practically impossible to accurately estimate how long it will take to complete a complex project. It’s far more reasonable to guess how quickly you can perform individual tasks.

My process of task generation follows a few basic guidelines:

1. Tasks should be small. The smaller the task, the more accurate the estimate will be. Additionally, smaller tasks give a psychological edge as they’re are inherently better defined, and less daunting than large tasks.
2. Tasks should all be approximately the same size. It’s human nature to put off doing larger, less defined tasks. This is rarely a good thing and can easily be circumvented by making all tasks the same size.
3. Tasks should be detailed. Within reason, tasks should include as much detail as possible.  If you’re working on a team, you may not be the person executing the task, so provide detail that others would understand so the task need not be outlined twice. If you find yourself writing paragraphs here, you probably need to split the task into a series of smaller ones.

Now, we have a big list, of managable, equally-sized tasks. Since the tasks are small, it’s easy to take three or four of them and make fairly accurate estimates on them. Since the tasks are all approximately the same size, the average estimate for those three or four tasks multiplied by the number of tasks will leave you with a reasonably accurate overall estimate, saving you having to estimate each step of the project directly. We can also group tasks back into our deliverables and provide more accurate deliverable by deliverable estimates for easy client consumption.

Aside from generating more accurate estimates, we’re also left with a valuable outline of the project, which can be used to execute the development of the project. Additionally, going through this process will often bring issues and questions to the surface, which will improve your perception of the project, ultimately making your estimates all the more precise.

In a future post, I will go into how this method of generating estimates fits into the new project management framework I’ve been hinting at.

Let’s first assume we’re dealing with a client who is open to stepping outside their comfort zone and adopting a new engagement framework with you. Let’s assume they’re willing to make themselves available for regular planning sessions and demo/review periods. Let us also assume that they’re willing to be held accountable for their role in the project’s completion. Let’s assume our client meets all these requirements, what do you do when the cost of educating the client on the methodologies, the processes, and the language of Agile is greater than the reward of putting those tools to work?

To make matters worse, I have found that the majority of the organizations I’ve dealt with in my career were not willing, or in some cases even capable, of meeting the afore mentioned requirements, nor did their projects posses what I deem to be the characteristics of a project, which would benefit from Agile.

I am by no means an expert on Agile, in fact my working experience with Agile is minimal — largely due to these substaintial stumbling blocks. Agile gurus, here’s your cue to jump in and tell me why I’m wrong. Please demonstrate how Agile addresses the issues I’ve raised. I’d love to be way off base on this, it’d sure make my life a lot easier.

In the meantime, enough about why Agile doesn’t work in these scenarios. Let’s get to the fun part: What does work?

Setting out to design a better way of managing small to mid-sized projects, I believe there are several criteria which must be met, on top of several of Agile’s parameters:

1. It must be easily, and quickly adoptable. When I say quickly, I mean pick up and go with no prior knowledge.
2. It must utilize familiar language. Part of easy adoptability means we must avoid new terms wherever possible. Terms, processes and tools must totally self-explanatory because no one wants to go back to school for the pleasure of working with you.
3. It must cater to different levels of client involvement. No company is the same and trying to force a client to do something that is dramatically different than what they do routinely does not work in the course of short term engagements. We can’t always have dream clients who can provide continuous, and timely feedback so we need a system that minimized the expense of less than timely interactions.
4. It must come with a tool. I truly admire the spirit of Agile’s “individuals and interactions over tools” notion, but let’s face it, even the most skilled carpenter isn’t very useful without his tools. The tool must be flexible and capable of adapting to meet the needs of variable of usage, but the tool must exist.

In my next post, I will begin to isolate the bottlenecks I see in the Agile process, discuss how they adversely affect small projects and start to explore alternatives. Until then, aside from the four criteria I mentioned here today, which characteristics must a process posses to work for your business?

The Agile movement has some dedicated supporters. Hell, they even have a manifesto. So, I’m likely to get some opposition over this next statement: Agile doesn’t work for small creative agencies.

It’s not Agile’s fault either. Agile is a great concept. There are some fundamental principles, which I love. However, my perception is that it’s best suited for a select set of working environments, chiefly software development. I’m generalizing, but in software companies, release dates tend to be several months apart, team members often have the benefit of focusing on one project at a time, and the role of the client is often played by an internal body. Agile is a perfect fit for that scenario.

Life in a web development studio is a little different — it is in ours anyway.

• We do lots of small projects, we do some medium-sized projects and every once in a while we land a big project. Size is relative of course, so let’s say anywhere from a couple weeks for a little project, all the way up to several months for a big project.
• A smaller project typically means a short term client engagement.
• The varying sizes of these projects means that we’re prone to overlap to some degree, which means at any given time our team has several projects in motion.
• Our clients live all around the world. We’re often separated by geography, culture, time zones and expectations.
• We work predominantly with small businesses, often directly with the owner. People who are involved in most, if not all aspects of their business. They tend to be working over capacity and have little room for additional concerns outside of executing their day-to-day business activities.

Agile really struggles in this environment. It simply isn’t designed for it.

At The Blog Studio, we have found that Agile introduces a non-trivial degree of process overhead to each project. This overhead is most easily recognized as client education and meetings, meetings, meetings.  On large projects, this overhead is amortized over a long period of time. However, on short term projects it’s very hard to justify the upfront process costs. I’ll go into more detail on this overhead in a future post.

So, we need something new. We need to borrow several of the key benefits of Agile, such as transparency, client participation and the capacity for rapid course correction, and we need to minimize the perceived stumbling points it introduces in our small agency scenario.

This will be a learning process. I don’t believe there is a universal solution. But I do think we can do better, and I’ll be sharing more of my thoughts on the subject over the next few weeks.

In the meantime, I leave you with a question: What hurts most about your process?

I’m sure I’m forgetting a bunch, but I think these are the main ones. That was tough ? it’s crazy how some of thes trips are starting to blend together in my mind, and I can’t remember if they were last year, or the year before…getting old.

Update: Oops…umm…forgot our honeymoon…NYC.

However, this year I did find it hard to resist some of the online bargains that were available. For a few weeks now, I’ve been meaning to upgrade the RAM in my MacBook (especially since upgrading to Adobe CS4), and BestBuy had 2GB chips on sale for $29.99.

I’m sold. I add 2 of the chips to my cart, and click checkout. I’m then prompted to login. Now I face the perplexing question, which I face on a near daily basis: “Have I already registered here?”. I’m fairly certain I have, so I begin to work my way through attempting to login with one of my 5 email accounts, and 4-5 standard passwords I use. If your finite math isn’t so hot, that’s a lot of permutations. So far, this poor experience is all my fault, and an issue I really need to figure out how to deal with.

When I finally login it starts to get interesting. I’m notified that for my privacy and security my order history has been temporarily deleted. Ok, I find this a little odd, but I don’t really care about my order history, I just want to order new RAM, so once again I click on my cart, and then checkout. I’m now returned to the security notice. When they said they had temporarily deleted my order history, what they really meant was they had disabled the whole account. My options are 1) enter a past order number to recover my history (if I had a record of my past orders why would I care about being able to recover it here?), or 2) create a new account. Create a new account?! I just signed into my account. For my “privacy” they want me to re-enter all my account, billing, and shipping information?

Wanting to avoid option two, I open up gmail and search for a past order. Astonishingly, I find a thread of emails from Best Buy detailing my last experience with ordering through their website. I had forgotten about this. In short, the last experience, I had ordered an item on sale and opted to use the Pick Up option, instead of having it shipped. Despite selecting a pick up location where they supposedly had ample supply, I received another email several days later saying they couldn’t honour the order, and that I could no longer get the sale price.

At this point, fuming over the past incident, I’m starting to think this is less and less a great deal. But sadly, my distaste for standing in line prevails, I enter the order number, recover my account, and order the RAM. Let’s hope it shows up this time.

Have you ever given your business to a company begrudgingly? Seems like it’s happening to me a lot lately…Rogers comes to mind.

In my opinion, this emphasizes the need for an online place for all of us to network and collaborate. The fact that all these people live and work within a few kilometres of me, and that I, someone who tries to put a lot of effort into staying tuned in, didn’t know anything about them, is a pretty strong indication that we all need to start communicating.

If you’re on Twitter, start paying attention to #tsTO, I think this may be the beginning of something great.

For the sake of this article, let’s say our tables look like this:

posts
---------------
id INT
title VARCHAR
body TEXT

comments
---------------
id INT
post_id INT
comment TEXT

The obvious answer is to query the posts table for the post data, join the comments table and count the comments where the post_id matches. Well, that will get you your answer…eventually. Aggregate functions in MySQL, especially COUNT(*) work very well when you’re only returning the COUNT(*) value, and when you’re only querying one MyISAM table. If you’re querying multiple tables, or using InnoDB tables then you will run into some pretty nasty performance issues. So, in this case, it’s not the best approach.

“Well then,” you say, “why don’t we just query for post data, then run our results through a loop to query for the comment counts?” Well, you could do that, but it’s not a solution that scales well. Let’s pretend for the moment that we’re not using caching in anyway, and let’s assume there are ten posts per page. That means in order to get the comment count for each post we would have to run one query to get our post data, and 10 subsequent COUNT(*) queries on the comments table to get the comment counts for each post. That’s 11 queries in total, which is hardly an efficient use of our resources. It means that each time the page loads we’re making 11 queries just for our post results ? on a high traffic site that’s a huge drain on our MySQL server.

In an ideal world, we’d like to make one query, on one table, and get our results. No complicated joins, aggregate functions, or excessive querying. This can be achieved very simply by setting up our data in a way that makes sense for us to retrieve it. What if our posts table looked like this:

posts
---------------
id INT
title VARCHAR
body TEXT
comment_count INT

Well, if the comment count was part of the posts table then a simple query to the posts table would get us all the information we need wouldn’t it? How can this be achieved? When comments are stored to the database all we need to do, in addition to inserting our comment data is to simply increment the value in the comment_count column in the posts table. This means an extra query is involved in adding a comment, but MySQL handles SET column_name = column_name + 1 very quickly and efficiently, and we make this additional query just once when the comment is written, but we reap the savings on every page load.

So, yes, we are storing a little extra data, and making an extra query, but storage space is cheap, and the savings on the reads are greater than the costs on the writes.

Next time you’re faced with a similar scenario, look at how you can structure your tables to make your reads easier because in the real world while writing the a the fanciest query conceivable may be gratifying, but it just doesn’t scale.