I’ve already said my piece on estimating software projects, so now I’d like to offer a word on the flip side of estimating – scheduling a project. Estimating and scheduling are not the same. Estimating is the practice of figuring out how many man-hours of labor something will take. Scheduling is deciding when those man-hours of labor will take place.
For purposes of this article, suppose we’re planning a project for a 3-person team. We’ve estimated the project at about 3000 hours, which is roughly the equivalent of 6 work-months for a 3-person team.
Many folks would say “Great! Today is February 23, so 6 months means we’ll be ready to implement around August 23! Let’s get started!” and then be bitterly disappointed when August 23 rolls around and they find themselves with a late project and an angry client.
The problem is in the way most people schedule projects. They give dates that haven’t been thought out very well in order to avoid upsetting the client, but the client ends up upset anyway because the project goes off track. I prefer to make my clients upset at the START of the project, that way I know exactly how much time I have to win them back over – the length of the project (that was a joke). Also, upset clients tend to think of really creative reasons to not make their delivery payment, and that’s bad for cash flow. We’re supposed to solve problems, not create more of them for ourselves and our clients.
If you’re a lead developer who’s been asked to take on some project management duties, you probably already have good estimating abilities. You just need to keep a few things in mind when you schedule the project, things that will keep you out of trouble.
1) People are supposed to take two weeks of vacation each year – that’s 10 business days.
So, if you’re planning a 6-month project, plan for each developer to be out for a week during that period.
“But, nobody ever takes vacations at my company” you protest. Do you know why nobody ever takes vacations at your company? Because nobody schedules projects correctly, and when Joe Developer wants to take a vacation, his boss says “No, we can’t afford to have you out right now, you can take your vacation when the project is over”. But then there’s another screwed-up, mis-scheduled project going on that really needs Joe’s help, so he gets assigned to that project with the promise that he’ll be allowed to take a vacation when it’s over. Lather, rinse, repeat.
Going by our example above, we’re now looking at a delivery date of August 30.
2) People are supposed to take an average of 7 sick days per year.
If you’re planning a 6-month project, plan for each developer to be out sick 3.5 days during that period. We’ll round up and call it 4.
I can hear you already – “But, people always work sick at my company”. Do you know why people work sick at your company? Because nobody schedule projects correctly, and when Joe Developer takes a sick day, upon his return he finds there’s hell to pay in the form of piles of backlogged work.
Why didn’t the work get done by someone else while Joe was out sick? Because nobody schedules projects correctly, so every developer in the company is running late and doesn’t have time to pick up the slack for an absent team member. So between the huge backlogs of work and the roundabout brow-beatings by his boss, Joe Developer soon learns that taking a sick day is more trouble than it is worth, and start coming in to work while he’s sick. Then he gets 2 other developers sick, who in turn each get 1 other developer sick. Mayhem ensues.
If you schedule things correctly, losing a guy to the flu every so often isn’t that big of a deal.
Going by our example above, we’re now looking at a due date of September 5.
3) There are 10 federal holidays per year.
If you’re planning a 6-month project, plan for each developer to be out 5 days for holidays.
I know that not everyone gets all the designated federal holidays as paid holidays, but plan for it anyway. “But we work the holidays at my company” you say. Do you know why you work holidays? Because nobody schedules projects correctly. Are you detecting a theme yet?
New due date: September 12.
4) How many personal days are employees given each year at your company?
Most places I’ve worked only give you 5, so let’s call it 2.5, rounded up to 3 per developer to cover the 6 months of work. “But my boss never OKs requests to use personal days” you say. Do you know why your boss never allows you to use your sick days? Because nobody schedules – oh, never mind; you already know what I’m going to say.
Now we’re looking at September 15.
5) Plan for disaster.
On a long project (long for me is 3 months or more, your mileage may vary) I usually build 5 buffer days into the schedule on top of everything else, to account for miscellaneous minor disasters such as jury duty, car trouble, dentist appointments, etc. If you’ve done your estimating correctly you probably won’t ever need to dip into this time, but it’s good to have it there.
This gives us a revised due date of September 22.
6) Nobody is productive for 8 hours a day. Not you, not me, not anybody.
Over the course of 6 months, you’re going to lose a lot of time to eMail, company meetings, phone calls, paperwork, and all the other non-billable, non-work-producing things that go into a typical day at the office. It’s hard to quantify exactly how much you’re losing. But for 3 people over a 6-month project, I think 2 weeks is realistic. That’s about 2 hours a day, which means your team is getting 6 productive hours out of every 8-hour work day. Believe it or not, that’s pretty good, and might even be optimistic.
With the non-productive work time factor added to our schedule, we are now looking at a realistic delivery date of October 6, which is a Friday. This presents a problem in and of itself, however.
You see, Friday deliveries are only for the stupid and desperate. Friday deliveries invite weekend phone calls and – even worse – working over the weekend to do tech support. Never deliver software on a Friday. Let’s look forward at the next business day, which is October 9. Obviously, October 9 is a Monday.
That presents another problem, though. While Friday deliveries are only for the stupid and desperate, Monday deliveries are the domain of a very special kind of cluelessness. There are a few reasons for this. Mondays are the #1 day for people to come in late or not at all, so if you have problem on-site and need to call the office to get help from a co-worker, you might be in for a rude surprise. If you have to travel any significant distance in order to be at your client’s office to do the implementation, a Monday delivery means you’re on a plane Sunday night – and flying on the weekend stinks. You should be with your family and friends on the weekends, not waiting in line at the airport, flying in a crowded coach-class seat and then checking into the No-Tell Motel (because your boss is too cheap to let you stay at Holliday Inn) in a futile attempt to catch some shuteye in a stange bed with freeway noise coming in your window, all in the hopes of being well-rested and sharp come Monday morning when you have to do the install.
No, thanks!
Plus, I personally guarantee that if you schedule a Monday delivery, someone on your team will sneak in “just one little change” to the code on Friday afternoon, which will break the application in some subtle way that doesn’t get detected before you burn the CD.
Pop quiz: when will the broken code be discovered? a) before you get to the client site, or b) after you get to the client site, when the VP (who also happens to be the guy who authorizes the delivery payment) is looking over your shoulder as you fire up the application for the first time and are confronted with a error message that is as cryptic as it is terrifying?
Again, no thanks.
We’ll deliver on Tuesday instead, so the implementation team can spend Monday travelling or doing test installations juuuuust to be sure everything works.
So, our extra-special, well-thought-out, ultra-realistic, do-or-die delivery date for this project is…October 10!
October 10 is more than a month past August 23. In fact, it’s about 6 weeks past August 23. I know what you’re thinking: “There’s no way people are routinely mis-scheduling projects to the tune of a full 6 weeks!”
Isn’t there?
But let’s be honest here – how many of you have been on a project where an unrealistic schedule was handed down from management, and the actual completion date ended up being over a month later, if not more? I’ve been there. Several times. Every developer I know has been there at least once. Hell, I know developers who worked 16 hour days from the start and STILL didn’t make the original delivery date (although I suspect that the 16-hour days were as much to blame for the missed delivery as the schedule was, I’ll let that go for now. Another day, another article, I promise).
Now, those of you who are both bold and cynical might be tempted to point out that in a competitive bidding situation, if you say you can deliver on October 10 and the other dev shop says they can deliver on August 23, the other shop is going to get the business because the client wants their delivery date to be met. This is not necessarily so. You need to understand 2 things:
1) The other shop can’t deliver on August 23 either.
2) The client knows this.
If the other dev shop gets the business anyway, you don’t want that client. In fact, the client should not want that dev shop, either. There is an interesting game that goes on when negotiating a project, an almost unspoken agreement to not talk about real dates or real numbers, but rather to figure out which dev shop is willing to say “yes” more easily. I submit that clients who willingly play this game should be fired, and that developers who willingly play this game are unprofessional.
How many times have you been asked “so how much would that cost?” or “so how long would that take?” by a client or prospective client, only to be pressured when you reply that you need some time to figure it out? By and large, when you are asked such questions, the questioner is not looking for a real number, he’s looking for a palatable number. He’s gauging your willingness to play ball, your eagerness to please. It’s a spine check. Sadly, passing the spine check often means not getting the project. The business world is filled to overflowing with business owners, managers and purchasers who prefer a yes man to a thoughtful, competent professional. That’s a hard thing to accept, but it is often true.
As the saying goes, don’t be that guy! Yes, you should be eager to please your client. Yes, you should make yourself manageable. Yes, you should be looking for ways to make things work. But you are the expert in what you do, not your client. When you knowingly agree to do things that will not work, or (even worse) that have the potential to damage the client’s business plans, you are not behaving like a professional. In these cases, you have an obligation to say no, even if it means losing the work.
As I have said in the past, I’m not suggesting anything you don’t already know. But I am suggesting things that you don’t already do. I hear from people every day who complain of issues that boil down to scheduling for political reasons rather than for engineering needs. I’ve lost projects because I wasn’t able to tell the client that “yes, the cancer-curing software you asked for can be ready in three weeks, from concept to completion”. But you know what? I also missed my son’s first words and first steps because I was at the office, working late in a desperate attempt to make my managers B.S. schedule work somehow.
Now that I run a company, I don’t have this problem because I’m the one being a stickler for good scheduling. But thinking back, I’d prefer to have been reprimanded or reassigned instead of working myself ragged over that garbage schedule.
Life happens fast. Don’t miss out on it by trying to make magic from idiocy. Schedule your projects correctly, and your career will thank you in the long run.
P.S. Yes, I’m aware that there’s an off-by-one issue with my example. That’s because it’s only an example, not an actual schedule.