Time Tracking: Converting the Masses

I remember way back in 1999, when I was filling out my first time sheets as a web programmer. We filled them out on on excel and sent them to our boss at the end of each week. I didn't really see the full value of tracking time, and jokingly asked my coworkers if I should be recording time that I am in the bathroom, etc. Since then not only have I had an opportunity to use a few different time tracking systems, I've gotten a real appreciation for the whole idea of tracking time and understand how critical it is for an agency and it's clients.

And I've also had an opportunity to work with many people who don't like tracking their time, who feel like it's a waste of energy or forget to do it until weeks or a month has passed, or just don't know how to do it properly. It pains me to see people who just don't get it, and it's even more painful when it comes time to report on a project and the data is either not there or not reliable, then what is an honest project manager to do?

Well, rather then let things get that far, I wanted to talk about some of the anti-time-tracking personalities and what we can do to help them.

The Forgetful One: The person who just can't seem to get it into his routine that time needs to be logged regularly. This person is not necessarily opposed to tracking time, just gets caught up in other things and never remembers to do it. When it comes time to catch up on all the days that time hasn't been tracked, numbers or guessed or fudged and inevitably inaccurate.
How we can help:

• Setup a daily calendar event to help remind him to track time. Send a reminder email each morning asking him if he logged his time from the day before.
  
• Make sure the system is as easy to use and as accessible as possible (I love the LiquidPlanner task timer system, so easy!). Make sure logging to specific tasks is intuitive and can be done quickly and painlessly (better to get more detail on a task than just time logged as "programming").
  
• Put a huge and really annoying alarm clock at his desk, set to go off at 5:30 every day to remind him to log time!

The "Ashamed" One: The person who puts in decent chunks of overtime, but is afraid to log his time for fear that it will look like he is too slow and it takes him too long to finish tasks. He knows what the target budget is, and doesn't want to make the project 'look bad' by adding more of his overtime hours to it.
How we can help:
Oh, how these people put gray hairs on my head...

• Explain to him that he should never be embarrassed or afraid to report time worked on a task. The only way we can ever learn from a project and improve our estimates is to see actual time spent on each task and compare that with the original estimates made.
• Yes, the budget might go over, but this is a fact of life and not only should he not be afraid or feel responsible, he should be comfortable (and proud) to show the rest of the team that he is committed enough to put in the extra time when needed to get the work done.

The Close-Minded One: This is the person who just doesn't see the point in logging time, she thinks it's a huge burden and can not find any benefit in doing it. Who cares how long she spent programming a little feature or sitting in an internal meeting? She's already wasting her time in the meeting, why lose more time recording it in her time sheet? She'll leave her time sheet empty for as long as possible and then just make rough guesses when time comes to fill in the blanks, sometimes many weeks later.
How we can help:

• If you work at a client services agency and bill based on hours worked then explain the direct correlation between the hours she records, and the dollars we will be charging that client (which will then eventually get to her paycheck)
• Show her the reports from the last few projects, and show her actual hours logged vs initial estimates made. If there is a striking difference between any of those totals (which, I'm sure there can be) then maybe she will see the importance of seeing how long things actually took and then using this information to make a better budget next time. If we can justify bigger budgets, than maybe she'll get a bigger bonus next time around!
  
• Losing too much time in unnecessary meetings? The only way we'll be able to figure that out is by looking at people's time sheets and reporting on billable vs non-billable time. Not that all meetings are unnecessary of course, but we all know that some of them can run a little long at times...

What types of personalities have you encountered, and what have you done to show them the light?

The story of my (never ending) love affair with LiquidPlanner

Don't worry, this post is appropriate for children...

It all began about a year and a half ago, when I got slammed by the boss for a web project that was about to enter the development phase and was being projected by the programmers to take about double the amount of time that it was originally estimated. I kept my head up and went back to look more closely at the original estimate and what we knew about scope at that time. Well, we knew very little, practically nothing. And, I remembered that the estimate was made months earlier and my client said to me "just give me a rough ballpark, we'll figure the rest out later". So, that's what I did. Well, I won't get into the details of how that drama continued, but what I will say is that the experience led me to start doing my own research on estimates and how to make them more accurate. I was stunned by the experience, by the idea that I was being held to a number that was calculated before any of us had any idea of what the project was really going to be. It was an estimate, a guess... a really rough guess.

My reading and research just backed up my position even more, that estimates made at the very beginning are subject to a high degree of error (anywhere from .25x lower to 4x higher). I got this and much more great information from a book by Steve McConnell, titled "Software Estimation: Demystifying the Black Art (2006)". I wrote about this idea, and the importance of presenting estimates in ranges on my company's blog. You can find the same post copied here, where I compare the uncertainty of software project tasks with the challenges of herding toddlers around in the morning.

From that point on I was on a crusade to make sure that all estimates my team produced were in ranges. It took a little while to get the programmers into that mode, after the Director of Technology read the same estimation book, he also helped me get the programmers to think of their estimates in terms of best case and worst case. Nobody wants to think that way at first, you always want to think that everything will go smoothly and nothing will be confusing or unclear, but the reality is that things are not always what they seem and we need to allow the extra room to figure things out sometimes.

So, by this point you're probably getting impatient and wondering where the juicy details about the love story with LiquidPlanner starts. It's coming very soon...I promise.

I don't remember the exact order of things, but I know I was pretty frustrated with Microsoft Project. I was a true believer in ranged estimates and I couldn't figure out any good way to get those worked into my MS project schedules. I experimented with new fields and was really unhappy with the lack of flexibility. I wanted to have a tool that showed my schedule in terms of best and worst case so that project stakeholders would have a range to work with and not expect a commitment to an exact date and exact number of hours of work (especially so early on).

Then, that one magical day, I was contacted by Liz Pearce from LiquidPlanner. She had read my blog post about including uncertainty in project estimates and wanted to tell me more about their web based project management tool. It was love at first sight, I was sold pretty quickly just based upon the fact that I could make my task estimates in ranges. Then, as I did more research I saw how LiquidPlanner was going to solve more of my problems. Our office was not using MS Project server so there was no central workspace for project plans, we all worked isolated on our own files and one project manager never knew when the other one needed her resource (yes, all project managers were women at that company at that time...go us!). By having the entire production team on Liquid Planner (for a much lower price than Project Server of course), we could easily see when a resource was overbooked. I also was thrilled to see a project management system that had such great collaboration tools, I was not going to have to rely on saving important emails to folders or logging the information in a shared file, we could all go to LiquidPlanner to see all important discussions and files related to our project. As I researched more about the company, I saw that Steve McConnell was on the advisory board. He is the author of the book I referenced above and many other great software project books that I have read since. One more reason I know LP was for me.

I've been using LiquidPlanner for about a year now, and have never thought of turning back. I recently moved to a new company and have brought LiquidPlanner with me. I've found that the scheduling system has proven an invaluable tool for my resource management challenges in my new workplace. And all this time, I've kept up the relationship with the good people at LiquidPlanner. I like them and believe in their mission so much, that I found myself bragging about their product on project management blogs and twitter posts, LinkedIn and other social media outlets.

After a few months of this, LiquidPlanner and I decided to make it official. I am now a part-time "Social Media Evangelist" (that's the best title I've heard so far, hope I live up to it!) for LiquidPlanner. So....if you see me out there listing off all the advantages to using LiquidPlanner to manage your projects, now you know why. I hope our relationship continues to thrive, and if you haven't checked them out....well, what are you waiting for?!