Lack of Motivation for Time Tracking

While waiting in the airport to head back to Seattle from SXSW (SXSWi was awesome BTW) I got to thinking about why it is so hard to get good data on how long it takes to perform tasks.

I ran across the following quote and it got me to thinking:

A typical problem, a few organizations in this industry face is collecting the required and accurate data. The performing teams needs to be oriented towards the importance of collecting data in an accurate manner. The team needs to be appraised on how the data collected is going to benefit their organization in future projects. Once the team is aware of how important the data collected is, how the data is going to be used etc., accurate data collection process will automatically be part of the project execution system.

- Size Based Estimation For Legacy Applications, G. Varghese and V. N. Iyer, 2005

Well now, that’s such wishful thinking I don’t really know where to start. Yup, just tell those developers why it is so important that they fill out the time card and I’m sure they’ll be happy to jump right on it. The key line in this is “how the data collected is going to benefit their organization” (emphasis mine). Few people really give a crap about how something will benefit their organization. They care about how things will benefit them personally. Now if you’re lucky these things are aligned. But in this case they are so not aligned that it would be funny if it weren’t so sad.

If it were that simple there would be no struggle to get folks to fill out timecards or use other time tracking software. They simply would because what’s good for the organization is good for them, right? Rising tide, all boats, blah blah blah. Right.

Let me put it this way. Developers (professional ones anyway) typically demand source code management software. Try telling your developers that you want to get rid of their SCM and use simple file shares because it has less bureaucracy and is faster. Go on, try it. I’ll wait…
.
.
.
Oh, you’re back already? How’d that work for you?

Not so good huh?

Well it’s not friggin’ surprising since the developers can see a clear group benefit as well as a personal benefit to using SCM. They can see an immediate impact upon their own lives and how happy they are from doing this even though for any one action it is clearly harder.

Now time tracking… what’s in it for me? This is one of those “the dog didn’t bark” things. See if it really were true that filling out a time card improved how everything worked then everyone would be doing it. You’d have to fight your developers to pry their time cards from their cold dead fingers. So I’m claiming that the fact that nobody much really likes to fill out time cards suggests that there’s really no personal benefit to doing so.

Until we can make it obviously beneficial to the individual to track their time, they either won’t, or will do it very poorly.

Breaking Down a Project: How Much Detail?

The Undocumented Features blog is exactly right that we should be aiming at a detail of tasks that are around 1 day in duration when beginning development. But there is a cost associated with having a person crank out those estimates. Often a project will need to “get the go-ahead” from the project sponsor before you can spend development team resources doing detailed estimates.

Those high level estimates are what often are so wrong. I think that one of the biggest reasons is that as project team members we’re giving estimates like “2 weeks”. “2 weeks” isn’t really an estimate, it’s a guess, a prediction.

An estimate is something like “1-4 weeks” or “3-5 days”. It really should be a range. One big downside of single-point guesses is that the guess is likely to be treated like a promise. On the other hand, giving a ranged estimate opens the discussion of what could happen (risks) that would push the effort towards the worst case end of the estimate or bring it in towards the best case end.

One of the primary problems is that project managers need a single number to plug into MS Project (or any number of similar tools). That coupled with the observation that these single-point guesses (especially at the high-level) are treated as promises pretty much make a person want to give up on high-level estimation altogether.

If you always give all of your estimates in ranges (e.g. 4-6 person weeks, 1-3 days, 6-9 staff months, etc) it is quite clear that it is an estimate, not a prediction or a promise. Giving a range opens the discussion of what could happen (risks) that would push the effort towards the worst case end of the estimate or bring it in towards the best case end.

Another nice thing about ranged estimates is that when you are asked to estimate something with poorly defined requirements you can give wide ranges to communicate the uncertainty. Well defined, believable requirements get estimates like 5-7 weeks whereas poorly defined, nebulous requirements get estimates like 4-20 weeks. This is especially true when giving high-level estimates.

There’s pretty much no way to get around doing high-level estimates. Your business needs some idea of the investment required to complete a project in order to make trade-offs. Hopefully this happens before your development team spends a bunch of time doing detailed estimates. Also folks in other departments (e.g. marketing, operations, manufacturing,…) need some idea of when they are likely to take delivery of the software. A team that can accurately (not precisely) give high-level estimates for these things gives their company a real competitive advantage.

So while it is frustrating, there are ways to do it and retain your sanity.

Multi-Tasking is Killing Your Business

I read a couple of articles recently and can now distill the vague feeling that I've always had that multi-tasking is not a good thing down to a simple statement that it is certainly a very bad thing.

And I can prove it.

Watch, nothing up my sleeve...

We all know there's thrash when switching, but let's assume that you've got some kind of dream team that can switch tasks perfectly. I do this because I don't want to get into a long discussion of "how good I am at multi-tasking".

Suppose we have 4 projects of 6 months duration each. Let's have the team multi-task and do all those things in parallel. They work one month on Project 1 , then move on to Project 2, and so on. Since there's no thrash it shouldn't hurt much right?


The average time to complete the projects is 22.5 months or just short of two years.

Now let's have our same team concentrate on one project at a time and see what happens.


This time the average time to complete is 15 months. That's 2/3 of the average for the multi-tasking schedule. But wait... it gets worse. What if those four projects are not of equal value.

We know that all projects are not created equal. Some are more valuable to your business than others. It is quite possible that your highest value project is a factor of ten more valuable than your least valuable project (or more). Let's model this by saying that each project on our stack-ranked list is twice as valuable as the one below it. Remember, I'm talking value not effort here.

Let's look 30 months out and see what each method has delivered in value to the business. Here's what the plots look like when the vertical scale is business value per month. The light green shaded area is the total value the projects have generated 30 months after project initiation.


So the multi-tasking project management method has delivered 124 units of value (8*9 + 4*8 + 2*7 + 1*6 = 124). But the single-tasking project... whoa... look out!


That's a whopping 294 units of value (8*24 + 4*18 + 2*12 + 1*6). More than DOUBLE.

In other words, if I worked for Single-Tasking Enterprises and you worked for Multi-Tasking Incorporated we'd be kicking your ass. (And no, you wouldn't be an acquisition target since we don't want your crappy multi-tasking IP.)

Okay, so multi-tasking sucks. What can you do about it?

I think the most important thing is to work off of a single prioritized list. You need one single list stacked top to bottom by priority for your people to use. The list must be public within your company. That way everyone is on the same page as to which project gets worked on first.

But I can hear you saying, "Hey, we work on many things at once because we're so busy and need to get all this stuff done yesterday!"

Yeah, and you can keep doing that. And as I've shown it will keep killing your business.

As leaders (and I mean anyone who has people under them) we must set hard priorities and stick to them. Constant switching of a person's "top priority" is a sure sign of weakness as a leader. If you are doing this STOP.

But what if you made a mistake in the priority order?

Look, even if we reverse the business value order and deliver the lowest value projects first we still come out ahead single-tasking. We get 156 units of value at the 30 month mark (1*24 + 2*18 + 4*12 + 8*6). That's still 25% more than the multi-tasking result with the "proper order".


The lesson is that it is less important that you pick exactly the optimal order in which to do projects. It is critically important that you build teams that focus on delivering one project at a time. Your teams must be empowered to protect their time and their schedule by telling all distractions to "piss directly off". Your leads must understand this and be rewarded for protecting their folks from distractions.

I find this stuff fascinating. How could I have run projects for all these years and never noticed how bad this is before?

Last Work Day of Summer

The end of summer always makes me feel a little down. When I was a kid it always seemed like summer would go on forever. They get shorter and shorter (and I seem to do less and less) the older I get.

Working at a startup again (requisite plug: http://liquidplanner.com) has been really interesting. This team has gone into it with a very specific product in mind. The last startup that I was involved with could never really figure out what it was building. This is very different. For one thing, we drink a lot more coffee!

Building project management software is kinda entertaining and kinda frustrating all at the same time. So much of the software out there is so friggen bad that it feels like, "Hey, this should be easy!" And that's also where a lot of the frustration comes from as well.

My office upstairs at home has cooled off from the heat of the day. Soon the Seattle rains will start again. That'll be nice because I'll feel much less guilty about spending my life thinking about statistics, software, human interaction and project management.

See, everyone thinks that this should be an easy problem to solve. How hard can it be to figure out when a project will be done?

Well let me tell you that it is pretty goddamned hard.

Even the simplest little thing like figuring out how much time it will take to do a simple, simple task is nearly hopeless. And it isn't just because we're concentrating on solving this problem for project management of software projects. You hear all this crap about how building software is not like building houses because the houses have a plan and defined methods and blah blah blah.

Bullshit.

If you think that building a house is all cut and dried and that all of that is a "solved problem" and that there is little uncertainty in home construction then you've obviously never built a house. As someone who has personally done a major remodel (as in, I swung the damned hammer and cut the damned two-by-fours) let me tell you that you make a lotta shit up as you go along.

So what's the difference? Well, I think that like a lot of things it is the people. When you work construction you show up at 8am and work through 5pm (provided you're on schedule). It is not that construction workers are predictable robots, it's that software workers are unpredictable flakes. And I'm fine with that.

In fact, if I had to punch a clock again I'd quit. Period.

We want those people to be allowed to work however makes them the happiest. Even if it would be easier to schedule zombies to do the work would we really want to encourage that? What I want is to liberate the knowledge workers from the tyranny of their schedules. Free them to work however and whenever they want and still have their projects succeed. Hell, not just succeed, friggen ROCK. Exceed all expectations for function, cost, schedule.

The tricky thing is that we're trying to build software that predicts a schedule from the most vague information. And we're trying to do it while not interfering with the poor bastard who has his head full of Amazon Web Service APIs while rewriting the chunk of code that is going to actually get his company paid but is already looking kinda sketchy because it's a rewrite of Jimmy Foobraugh's port from Fortran-77 of the linear regression algorithm and Jimmy got fired for never commenting anything.

Yeah.

I should have drunk more rum this summer. That is my conclusion.