Using Visualization for More Accurate Time Estimations

Preface

I hate time estimations. Tracking time for contract work takes a close 2nd. Unfortunately, I’ve never seen a lot of combination of both; estimating a project’s time line, and comparing the expectations with the realities at the end… and then actually ACTING on that data. In fairness, “the end” is extremely hard to define sometimes.

The only advice I have for time tracking is to do it while you work; postmortem is a bitch, and even harder to remember details when a client body checks you on a particular item. If you’re not a slack bastard like me, more power to you.

Time estimations, on the other hand, I have found 2 good ways to do. The first is experience and the second is visualization.

Experience

This isn’t so much, “code for a few years, and then’ll you get good at time estimations”. Rather, you document how long you think something will take, do it, and document how long it took. You then compare the 2 times. Do this a few times. If the results are dead on, right on. If they aren’t, identify why. These risk factors are what you can watch out for next time. Therefore, why you can feel confident you can code a solid web service call in 8 hours, if the web service itself isn’t done, and it ends up taking you 12 total hours instead spread out over 4 days, you can then mark that next time you give a client a proposal with time estimations. Aka:

• Web Service Call = 8 hours, high risk
• Login Form based on comp = 2 hours, low risk

Then, you can mitigate risk in a number of ways. Clearly communicate to client the risks to hopefully remove them, hit those high risk items first, or merely charge fixed bid for the low risk tasks, and hourly for the high risk ones. That, or just pad those particular items in your time estimations with a number of hours based on your past experience. For W2 work, project managers can interpret high risk items, and add their own padding and formatting the official document they showcase those in charge of pricing. For contract work, you can merely pad the high risk items and leave off the low/high risk labels.

I’ve coded so many bloody login forms, I got that shiz down pat. Web services? Hit or miss. If the back end code is solid, I can knock out in a day a good, re-usable chunk of code depending on what it does. If the back-end code isn’t solid, it could go on for weeks. These weeks could actually only total 20 hours, but even though that’s only 20 billable, getting done today vs. getting done in 3 weeks is a major deal.

And yes, it IS that black and white to compare the estimated times vs. the reality. I’m making the assumption above that your task assessment skills are dead on. Just because you set out to code a web service that gets a list of people from the back end .NET server, and later found out you had to code 4 instead because your app grew in scope… that counts as the same task. You need to be able to easily quantify tasks into either milestones unto themselves, or a set of mini-goals that lead up to a larger milestone. Therefore, if you see in your time estimations that you grossly misjudged a growth of scope creep in a particular area, or across the board, this indicates both a problem with your time estimations as well as task assessment… that, or client management.

You cannot give effective time estimations on a project unless you understand the scope of the project. If scope is undetermined, and you’re getting paid hourly, the best you can do is the best you can do. Therefore, making time estimations based on already flawed task assessments will result in padding on high risk items. Those paddings, however, can be pretty accurate if you’ve seen the chaos enough times to quickly identify the risk areas and pad accordingly.

Visualization

Professional athletes who have a winning track record have often mentioned that they saw themselves winning before they did it. Some others have actually performed a type of meditation before a game where they close their eyes, relax, and visualize themselves winning. In the case of Hockey, they actually picture themselves in their imaginations deftly maneuvering the hockey puck to the goal. Resolute, they then go out and act out those visualizations.

Another analogy is the end of every Chuck Norris movie. Antagonist ticks Chuck Norris off. Camera does a close up head shot of a wounded, resolute, and generally pissed of Chuck Norris. The audience has just performed the same visualization that Chuck Norris has: He overcomes the pain and opens a can of whoop-ass on the bad guy. Chuck Norris’ character then acts out that visualization.

Visualization is also lauded by a lot of inner peace, motivational, and how to make money books. I prefer inner turmoil, I’m motivated, and already make money. I do find, however, visualization is good for body checking your time estimations. I play to win, so it seemed a good match to me.

There are 3 types of ways people learn which are audio, visual, and tactile. Choosing the one, or combination thereof that best represents you, allows you to do effective visualization of how your time estimations will work out. I’m an audio learner; I like to talk things out. I’m the type of guy who asks people questions, and then answers them myself, then thanking the person for their help. Said person is typically left with a strange expression, curious as to what just happened.

It’s a form of role playing to challenge the assumptions, typically talking it over with whoever the project manager is, like so:

“So, I’ve estimated 82 total hours here, QA included. Each set of tasks is based on either a coded component, visual design implementation, or back-end web service I need to get data from. Is that accurate? Feels accurate; I went with my gut, challenged it, and tried again, typically reaching the same amount of hours. Now, let’s visualize this out.”

“I have to sit down on Friday, and do 2 things… first, I have to do some quick re-factoring to organize client code into a specific package structure. That’ll probably take 3 hours. Second, I have to then get 2 other developers comfortable with the code setup. That’ll take another hour at most.”

:: looks at time sheet ::

“Do I have time allocated for 4 hours of ramp up time? It looks like just a list of components that I need to create and then wire up; I don’t see ramp up time on there.”

You don’t want to ever feel like your working on borrowed time when your coding. To me, it detracts from me doing good work vs. working work. Working in an environment where you feel like you are walking on egg shells is the same type of uncomfortable feeling. You want to feel confident in your guesstimate of work, and go forth with a positive attitude. If you start doubting yourself right out of the starting gate, that’s a horrible way to feel when just starting a project.

Using visualization helps you see just how you’ll start the project. If you act it out in your mind, you’ll see all those other tasks that you may not have quantified on your list of tasks. Modifying your ANT tasks, downloading and installing Flex Builder 3 beta, doing production art (break up) on the PSD to use in Flash or Flex… all are tasks that individually seem just part of the job, but collectively add up in sum time taken.

The reality is, it’s a ton easier to put these tasks on a time sheet if you’re W2. As a contractor or consultant, it’s really hard to justify why the client’s paying you $300 to “get organized”. If I were hiring someone, I wouldn’t pay for that either. The point here, though, is to identify the items you left out on your time estimations that DO have a direct impact on the deadline. If you’re a contractor between projects, you’ll need to keep in mind that un-paid ramp up time to ensure it doesn’t eat into your billable time. This is especially true on fixed bid projects (which I refuse to do, btw; I find a hybrid approach with some parts being fixed bid while other high risk items are hourly can possibly work… per talking to one of my bosses, haven’t tested the theory out yet).

Exposing Risk

Visualization also exposes risk factors.

“I need to hit this ‘getPeople’ web service, and get it working enough to ensure the data is good and will work in my customized List control. I got my VPN working this morning, and can use the web service tester app both while on VPN or on the external wireless network. The web service returned good looking XML every time I hit it.”

Good. Low risk there. Connection’s good, web service is good, and you’re ability to test from different networks is good.

Imagine if you did NOT yet have VPN access; do you have to go through a ton of company red tape to get a login? Do you need an account in the back-end system before you can get a user token to actually hit the ‘getPeople’ web service? Have you even tested the ‘login’ service that generates this user token? Are you positive the external wireless isn’t still hitting the internal network behind the firewall?

Once you start talking through this scenario, and the insane challenges associated with coding in this wild jungle, you’ve quickly identified a high risk item that requires appropriate padding. It also makes it easier to prioritize the more higher risk tasks first.

For some people, it’s hard to get out of the engineer mode and into the role playing mode. Therefore, visualization can be done a few minutes after you’ve done your time estimations, or even a day after once you’ve “slept on it”. You’ve taken the programmer’s view of what needs to be created. The next day, you then walk through the work flow scenario with a fresh set of eyes and a fresh cup of coffee.

For contractors/consultants, don’t do this in front of clients. They’ll get nervous when you start “magically” remembering new tasks you need to account time for. However, it can be useful when vocally visualizing someone ELSE’s time estimations that you don’t agree with; walking through each task brings a sense of reality to them and can add weight to your argument. Use your best judgment.

Conclusions

Being able to quantify software development into a set of tasks that fits nicely into an Excel spead sheet which is dropped into a Microsoft Project gant chart is just plain hard. Software development is an art. From the get-go, your setup to fail. However, it’s also a business and indicating cost is just a fact of life. It comes easier with experience, both correctly identifying all tasks in appropriate size as well as with the appropriate amount of time for those tasks, padding included on high risk items.

Visualization is just a 2nd pass, just like database normalization or 2-pass video encoding, that you can apply to your already created time estimations to double-check their accuracy. It comes at it from the qualitative angle; “Am I really going to work the way these tasks are laid out? Are these tasks valid and thorough?” Visualization helps answer those questions, identify missing tasks, and expose risk items.

Self actualized project timelines 4 t3h bling bling!