Journey vs. Destination

How long will it take you to complete that task? You know, that task you don’t know any details about and is just a block on the diagram that says “USB”. When, precisely, will you be finished with it?

Engineers hate schedules. We like puzzles. Hurrying us while we complete a puzzle just leads to annoyance all around. It takes the time it takes. Maybe if you stopped interrupting with stupid questions about deadlines we could focus and create a good solution.

Putting on my manager hat (oh, yeah, I totally have a hat specifically for thinking about manager-y things), knowing when software is going to get done is critical. In an embedded system, the software needs to correspond with the hardware and the manufacturing tasks. Letting everyone work at their own pace without any guidance just leads to disaster.

If you’ve never put together a schedule before, it can seem like magic. I’ll tell you how I do it. I’m pretty good at getting the project to come out when I predict.

Let’s start from the engineer perspective and then I’ll move to the project management side.

When asked how long I think something will take, I check my gut, it gives me a number (“ahh, that will take about two hours, if only people would leave me alone to concentrate”). This number has no debugging or anticipation of uncovering lower level problems. It doesn’t take into account interruptions, feature creep, or high priority interrupts coming to clear off my desk so I have to restart the intended task. My gut doesn’t worry about documentation or code reviews, it considers the puzzle only.

So I take that number (two hours) and multiple by four, then add two days. Thus, I tell the project manager that the task should take about three days. This isn’t padding… this is planning. Everyone has a multiplier and an adder. Many managers work to figure out what multiplier they need to apply to the engineering estimates they are given. In fact, it looks like MS Project has this concept of Baselines that let the project manager figure out what the multiplier should be as time goes by.

That is just me providing one estimate of a small task. My multiplier and adder are my own. You can use them but you really need to figure out if it is an over or under estimate.

But, what about if you are stating a project and need to sort out ten or twenty tasks? You can use the same method if you know enough about the tasks but my gut reaction tends to get worse as I think about all this work. And my estimates get ever larger as my brain gets tired.

Instead, I take the list and try to break down all the tasks I can think of… USB breaks down into many parts: a driver, an interface layer, and an application layer on the device. I also need a PC program for testing. Breaking tasks down is a tough process, easier done with another person. At the end, you have sixty or a hundred tasks so it feels like anti-progress.

Don’t fear, the next step is to go through the list of tasks and decide if each is easy, medium or hard. As you go through the list, you may find you need more granularity; I usually end up with a very hard and trivially easy. Remember, if you don’t know much about it, it is going to be harder because you’ll have to figure out how to do the work before you start, bump those unknowns up a level.

Now you’ve got a long list of tasks and whether they are easy, medium, hard, very hard, etc. I’d put these in a spreadsheet. But it’s recently come to my attention that I may depend too heavily on spreadsheets. Still, go for it.

Now you need to define what easy, medium, and hard mean. Think of a few of the easy tasks… ask your gut how long they’ll take. Multiply by four and add two days (or whatever you choose). Same for medium and hard… Don’t worry about how long everything will take. Don’t worry about the goal dates or when the CEO wants you to ship. Listen to your gut. Then use your brain to correct it.

Now, go home and sleep on it. In the morning, without looking at your old values, re-do the gut check for easy, medium, etc. If the values are very different, spend some time thinking about why that would be. I am more optimistic in the morning but sometimes I’ll realize the difference in values is because I’ve marked some medium things as easy so my average was off.

Anyway, take your two values for each category and average them (or sort out the discrepancies properly). Now you can apply it all of the tasks. Is it exact? No, of course not. Is it a reasonable first pass? Yes, very much so.

Now all of your task have duration values, maybe in engineer hours, maybe in engineer days. Sum up the duration and convert to 40 hour work weeks. Now you can say “with 1 engineering resource, the whole project should be completed by X”. Someone will squawk loudly at this. It always seems like too much time. But you aren’t just pulling a number out of a hat. If they want to argue, now you can show your work, maybe get some advice on what isn’t as difficult as you currently expect.

When you add resources (aka minions, coworkers, or other people), you don’t get to divide the time perfectly in half, there is overhead with talking to a team. The larger the team, the more time will be spent communicating and making sure everyone is pulling in the same direction. I put as a multiplier on my task durations. For a 4-6 person project, I usually use 10% for integration. It isn’t an exact science… ask yourself, how many hours a week do you currently spend in meetings versus the hours spent getting things done? That is integration time.

So, there you have it. My secrets to creating a schedule.

Oh, wait there is a little more to it, isn’t there?

Priorities help… assign each project a priority (0 is low, 1000 is high…. I know 10-0 would be better but  if your data is ever going to land in MS project, 0-1000 is the way to go). Tasks that are risky get higher priorities. If you can get the high-risk tasks out of the way early, you can be more assured of the project’s success.

Precedence is separate from priority but they are linked together. For example, if I need my USB driver in order to write the application layer, the driver is a predecessor to the application. The application may be riskier and it may be highly desired by marketing so it has a higher priority. In short, you’ll really need both, priorities and predecessors. Also, some of your predecessors may not be in your task list (ahem, can’t finish the USB driver until I get some hardware to start working with).

At this point, the schedule starts shaping up…  mentally, you should have a pretty good idea of what needs to happen sooner and what can wait until later. But it doesn’t really count until you have a Gantt chart.

I hate Gantt charts.

I also hate MS Project.

But I recently did a trawl to see what I could use instead. There is a Google docs gadget but that is going away and doesn’t work in Chrome, only in Firefox (snicker). There were some Mac options but no iPad options that didn’t need the Mac support stuff. I didn’t try Open Office. And it is going to pain me to pay for MS Project when my 60-day eval period is up. And yet, the powers-that-be for this project really want a Gantt chart. And it was the only way I could show them a major flaw in the current plan.

I’m not going to teach you how to use MS Project. At this point, with tasks, duration, predecessors, and priorities, all you need to do is add resources and push level and it sorts out when things happen. (Also, swear a bit because I’m leaving a bit out.) Then you muck about trying to make sure all the people have work they are likely to enjoy (and complete) and keep pushing level until the charts look the way you want them to.

But wait, don’t stop there, now you need to go to your resources and get your easy/medium/hard initial estimates re-evaluated by the people actually doing the work. So, gone on, ask them, “How long will it take you to complete that task?”